[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
On 04/07/2011 07:05 AM, Amit Shah wrote:
We restrict the commands that a guest can send us after a cdrom change
event. The current list includes REQUEST_SENSE and INQUIRY commands.
Guests can also issue TEST_UNIT_READY to inquire for the status, so
allow this command as well.
Signed-off-by: Amit Shah
---
hw/ide/core.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 007a4ee..d55d804 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1105,10 +1105,11 @@ static void ide_atapi_cmd(IDEState *s)
/* If there's a UNIT_ATTENTION condition pending, only
REQUEST_SENSE and INQUIRY commands are allowed to complete. */
if (s->sense_key == SENSE_UNIT_ATTENTION&&
- s->io_buffer[0] != GPCMD_REQUEST_SENSE&&
- s->io_buffer[0] != GPCMD_INQUIRY) {
- ide_atapi_cmd_check_status(s);
- return;
+s->io_buffer[0] != GPCMD_REQUEST_SENSE&&
+s->io_buffer[0] != GPCMD_INQUIRY&&
+s->io_buffer[0] != GPCMD_TEST_UNIT_READY) {
+ide_atapi_cmd_check_status(s);
+return;
}
switch(s->io_buffer[0]) {
case GPCMD_TEST_UNIT_READY:
ACK
Paolo
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 2011-04-06 21:34, Anthony Liguori wrote: > On 04/06/2011 02:27 PM, Peter Maydell wrote: >>> Right, but honestly speaking, I don't know how this works for other arches. >>> >>> So, the best thing to do is to have a general design that can be used >>> by any architecture. Of course that we can also add a new command later >>> if needed. >> Well, I'm not sure "send a random interrupt to the core" makes >> much sense for ARM... So what are we actually trying to model here? >> Some sort of way to do "press a front panel switch" via remote monitor >> protocol? I guess you could have an API for boards to register any >> switches they had... > > http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > > If an OS is totally hosed (spinning with interrupts disabled), and NMI > can be used to generate a crash dump. > > It's a debug feature and modelling it exactly the way we are probably > makes sense for other architectures too. The real semantics are > basically force guest crash dump. Right, it's a debugging tool. And that does not necessarily means it has to match real hardware. I could imagine scenarios where it could be helpful to direct the NMI to a specific core, e.g. in AMP setups if only one OS ran wild. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH] configure: add --version flag
On 04/07/2011 07:12 AM, Mike Frysinger wrote: Standard autoconf scripts include a --version flag so people can easily query things. Add this to qemu's configure so it too can integrate with build systems that have standard autotool helpers. Signed-off-by: Mike Frysinger ACK Paolo
[Qemu-devel] Re: [PATCH v2 2/2] cdrom: Make disc change event visible to guests
On 04/07/2011 07:05 AM, Amit Shah wrote:
Commit 93c8cfd9e67a62711b86f4c93747566885eb7928 tried to send a 'no
disc' event after a cdrom change so that guests notice a cd change event
between two 'cd present' states. However, we don't go from
'cd present' -> 'no cd' -> 'cd present'
as the SENSE_UNIT_ATTENTION sense_key is written over by the
ide_atapi_cmd_error() function.
So for the disc change event, let us ensure the error() function doesn't
trample over that value so we do get to report it the next time around.
Also, ensure we go from 'no cd' to 'cd present' state.
With this, older Linux guests (< 2.6.38) notice cd changes just fine.
For newer Linux guests (2.6.38+) cd change events break again and that
will be fixed by implementing the GET_EVENT_STATUS_NOTIFICATION command.
Signed-off-by: Amit Shah
---
hw/ide/core.c | 42 +++---
hw/ide/internal.h |1 +
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index d55d804..abb577c 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1113,10 +1113,42 @@ static void ide_atapi_cmd(IDEState *s)
}
switch(s->io_buffer[0]) {
case GPCMD_TEST_UNIT_READY:
-if (bdrv_is_inserted(s->bs)&& !s->cdrom_changed) {
-ide_atapi_cmd_ok(s);
+if (bdrv_is_inserted(s->bs)) {
+int sense, asc;
+
+sense = s->sense_key;
+asc = s->asc;
+
+ /*
+* First, check if there's any pending media change
+* notification to be given.
+*
+* We want the guest to notice an empty tray between a cd
+* change, so send one MEDIUM_NOT_PRESENT message after a
+* cd change.
+*
+* After we've sent that message, the guest will poke at
+* us again and send the UNIT_ATTENTION message then.
+* Once this is done, reset the UNIT_ATTENTION message to
+* ensure we don't keep repeating it.
+*/
+if (!s->media_change_notified) {
+ide_atapi_cmd_error(s, SENSE_NOT_READY,
+ASC_MEDIUM_NOT_PRESENT);
+s->media_change_notified = 1;
+} else if (s->cdrom_changed) {
+s->sense_key = SENSE_UNIT_ATTENTION;
+s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
+ide_atapi_cmd_ok(s);
+
+s->cdrom_changed = 0;
+ sense = SENSE_NONE;
+} else {
+ide_atapi_cmd_ok(s);
+}
+s->sense_key = sense;
+s->asc = asc;
} else {
-s->cdrom_changed = 0;
ide_atapi_cmd_error(s, SENSE_NOT_READY,
ASC_MEDIUM_NOT_PRESENT);
}
@@ -1613,6 +1645,7 @@ static void cdrom_change_cb(void *opaque, int reason)
s->sense_key = SENSE_UNIT_ATTENTION;
s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
s->cdrom_changed = 1;
+s->media_change_notified = 0;
ide_set_irq(s->bus);
}
@@ -2474,6 +2507,7 @@ static void ide_reset(IDEState *s)
s->sense_key = 0;
s->asc = 0;
s->cdrom_changed = 0;
+s->media_change_notified = 0;
s->packet_transfer_size = 0;
s->elementary_transfer_size = 0;
s->io_buffer_index = 0;
@@ -2713,6 +2747,8 @@ static int ide_drive_post_load(void *opaque, int
version_id)
if (s->sense_key == SENSE_UNIT_ATTENTION&&
s->asc == ASC_MEDIUM_MAY_HAVE_CHANGED) {
s->cdrom_changed = 1;
+} else {
This is within a version_id < 3 condition, so media_change_notified is
never set to 1 when loading from a current QEMU.
Integrating the new flag into cdrom_changed (0 = ok, 1 = cdrom changed
and NOT_PRESENT sent, 2 = cdrom changed and NOT_PRESENT not sent) should
also work for older guests. They just treat 2 the same as 1.
Paolo
[Qemu-devel] Re: [PATCH v2 2/2] cdrom: Make disc change event visible to guests
On (Thu) 07 Apr 2011 [09:31:05], Paolo Bonzini wrote:
> On 04/07/2011 07:05 AM, Amit Shah wrote:
> >Commit 93c8cfd9e67a62711b86f4c93747566885eb7928 tried to send a 'no
> >disc' event after a cdrom change so that guests notice a cd change event
> >between two 'cd present' states. However, we don't go from
> >
> > 'cd present' -> 'no cd' -> 'cd present'
> >
> >as the SENSE_UNIT_ATTENTION sense_key is written over by the
> >ide_atapi_cmd_error() function.
> >
> >So for the disc change event, let us ensure the error() function doesn't
> >trample over that value so we do get to report it the next time around.
> >Also, ensure we go from 'no cd' to 'cd present' state.
> >
> >With this, older Linux guests (< 2.6.38) notice cd changes just fine.
> >For newer Linux guests (2.6.38+) cd change events break again and that
> >will be fixed by implementing the GET_EVENT_STATUS_NOTIFICATION command.
> >
> >Signed-off-by: Amit Shah
> >---
> > hw/ide/core.c | 42 +++---
> > hw/ide/internal.h |1 +
> > 2 files changed, 40 insertions(+), 3 deletions(-)
> >
> >diff --git a/hw/ide/core.c b/hw/ide/core.c
> >index d55d804..abb577c 100644
> >--- a/hw/ide/core.c
> >+++ b/hw/ide/core.c
> >@@ -1113,10 +1113,42 @@ static void ide_atapi_cmd(IDEState *s)
> > }
> > switch(s->io_buffer[0]) {
> > case GPCMD_TEST_UNIT_READY:
> >-if (bdrv_is_inserted(s->bs)&& !s->cdrom_changed) {
> >-ide_atapi_cmd_ok(s);
> >+if (bdrv_is_inserted(s->bs)) {
> >+int sense, asc;
> >+
> >+sense = s->sense_key;
> >+asc = s->asc;
> >+
> >+/*
> >+ * First, check if there's any pending media change
> >+ * notification to be given.
> >+ *
> >+ * We want the guest to notice an empty tray between a cd
> >+ * change, so send one MEDIUM_NOT_PRESENT message after a
> >+ * cd change.
> >+ *
> >+ * After we've sent that message, the guest will poke at
> >+ * us again and send the UNIT_ATTENTION message then.
> >+ * Once this is done, reset the UNIT_ATTENTION message to
> >+ * ensure we don't keep repeating it.
> >+ */
> >+if (!s->media_change_notified) {
> >+ide_atapi_cmd_error(s, SENSE_NOT_READY,
> >+ASC_MEDIUM_NOT_PRESENT);
> >+s->media_change_notified = 1;
> >+} else if (s->cdrom_changed) {
> >+s->sense_key = SENSE_UNIT_ATTENTION;
> >+s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
> >+ide_atapi_cmd_ok(s);
> >+
> >+s->cdrom_changed = 0;
> >+sense = SENSE_NONE;
> >+} else {
> >+ide_atapi_cmd_ok(s);
> >+}
> >+s->sense_key = sense;
> >+s->asc = asc;
> > } else {
> >-s->cdrom_changed = 0;
> > ide_atapi_cmd_error(s, SENSE_NOT_READY,
> > ASC_MEDIUM_NOT_PRESENT);
> > }
> >@@ -1613,6 +1645,7 @@ static void cdrom_change_cb(void *opaque, int reason)
> > s->sense_key = SENSE_UNIT_ATTENTION;
> > s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
> > s->cdrom_changed = 1;
> >+s->media_change_notified = 0;
> > ide_set_irq(s->bus);
> > }
> >
> >@@ -2474,6 +2507,7 @@ static void ide_reset(IDEState *s)
> > s->sense_key = 0;
> > s->asc = 0;
> > s->cdrom_changed = 0;
> >+s->media_change_notified = 0;
> > s->packet_transfer_size = 0;
> > s->elementary_transfer_size = 0;
> > s->io_buffer_index = 0;
> >@@ -2713,6 +2747,8 @@ static int ide_drive_post_load(void *opaque, int
> >version_id)
> > if (s->sense_key == SENSE_UNIT_ATTENTION&&
> > s->asc == ASC_MEDIUM_MAY_HAVE_CHANGED) {
> > s->cdrom_changed = 1;
> >+} else {
>
> This is within a version_id < 3 condition, so media_change_notified
> is never set to 1 when loading from a current QEMU.
Right.
> Integrating the new flag into cdrom_changed (0 = ok, 1 = cdrom
> changed and NOT_PRESENT sent, 2 = cdrom changed and NOT_PRESENT not
> sent) should also work for older guests. They just treat 2 the same
> as 1.
Yes, thanks -- I was thinking the same.
v3 coming up.
Amit
[Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
Hi, I have some questions about the qemu's bios. How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Which function or code file need I to pay more attention to? For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into the same funciton rom_add_file() in hw/loader.c. Is it the right function, which loads the bioses? And then another question, how qemu give the control to bios when the bios file is loaded? Maybe this question is not in the scope of qemu, however, can you give me some cue point. Any reply are appreciated. Thanks. Gavin
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On 07.04.2011, at 07:56, Ralf Ramsauer wrote:
> Here the version with the correct coding style.
Phew - please keep the commit message intact. What we do to apply patches is
that we simply directly take your patch into git using "git am". With a patch
description like this, if anyone looks at "git blame" or "git log" later, will
wonder what the rationale was behind the patch, as the description is basically
missing.
Also, you need to put a line like this there:
Signed-off-by: Ralf Humppa
I would actually simply resend a patch with proper patch description and fixed
braces (see next comment), but I can't, because the first patch you sent was
already missing your name after the Signed-off-by, basically making the patch a
legal grey zone. So please, resend it again with proper patch description,
proper Signed-off-by line and the brace thing fixed.
Alternatively, I could rewrite the patch myself. But that would obviously rob
you off your name in the commit log (due to the missing Signed-off-by), which I
bet you wouldn't want :). The fame is all yours after all.
> diff --git a/hw/multiboot.c b/hw/multiboot.c
> index 0d2bfb4..2380d5e 100644
> --- a/hw/multiboot.c
> +++ b/hw/multiboot.c
> @@ -267,6 +267,11 @@ int load_multiboot(void *fw_cfg,
> /* if a space comes after the module filename, treat everything
>after that as parameters */
> target_phys_addr_t c = mb_add_cmdline(&mbs, initrd_filename);
> +/* Kill spaces at the beginning of the filename */
Please move your code before the comment above. This way, it's
a) confusing to read
b) the $0 argument passed to the guest is wrong, as the virtual command line
that shows up in the guest multiboot descriptor tables doesn't get the spaces
removed.
> +while (*initrd_filename == ' ')
> +{
Please do the brace in the same line as the while. This way it's not following
CODING_STYLE.
Also, I just realized that you did miss another small part that needs change. A
few lines above, there is code to interpret the modules right before that as
well:
if (initrd_filename) {
const char *r = initrd_filename;
mbs.mb_buf_size += strlen(r) + 1;
mbs.mb_mods_avail = 1;
while ((r = strchr(r, ','))) {
mbs.mb_mods_avail++;
r++;
}
mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
}
This code would need some change as well, as now the mb_buf_size field is
incorrect. It doesn't really hurt, but is bad style to not use the exact amount
of memory we need to.
> + initrd_filename++;
> +}
> if ((next_space = strchr(initrd_filename, ' ')))
> *next_space = '\0';
> mb_debug("multiboot loading module: %s\n", initrd_filename);
I've also CC'ed Adam. He's been the most active person contributing to
multiboot recently.
Alex
[Qemu-devel] Re: [PATCH v2 2/2] cdrom: Make disc change event visible to guests
On Thu, Apr 07, 2011 at 10:35:19AM +0530, Amit Shah wrote:
> + /*
> + * First, check if there's any pending media change
> + * notification to be given.
> + *
> + * We want the guest to notice an empty tray between a cd
> + * change, so send one MEDIUM_NOT_PRESENT message after a
> + * cd change.
> + *
> + * After we've sent that message, the guest will poke at
> + * us again and send the UNIT_ATTENTION message then.
> + * Once this is done, reset the UNIT_ATTENTION message to
> + * ensure we don't keep repeating it.
> + */
Indentation is off here.
> +if (!s->media_change_notified) {
> +ide_atapi_cmd_error(s, SENSE_NOT_READY,
> +ASC_MEDIUM_NOT_PRESENT);
> +s->media_change_notified = 1;
> +} else if (s->cdrom_changed) {
> +s->sense_key = SENSE_UNIT_ATTENTION;
> +s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
> +ide_atapi_cmd_ok(s);
> +
> +s->cdrom_changed = 0;
> + sense = SENSE_NONE;
Indentation is off here.
Otherwise looks good. I will test a Windows 2003 Server guest.
Stefan
Re: [Qemu-devel] [PATCH 1/5] ppce500_mpc8544ds: Fix compile with --enable-debug and --disable-kvm
On 07.04.2011, at 05:02, David Gibson wrote: > From: Alexey Kardashevskiy > > When configured with --enable-debug, the makefile does not use any > optimization and compilation of hw/ppce500_mpc8544ds.c fails because gcc > does not remove the never called without kvm function > mpc8544_copy_soc_cell(), which will fail to link without the kvm code. I'm not sure I can follow. So the problem is that we call kvmppc_read_host_property and don't provide a stub wrapper for it? Let's provide a wrapper then instead of crippling the target code :) Alex
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
On Thu, Apr 07, 2011 at 10:35:18AM +0530, Amit Shah wrote:
> @@ -1105,10 +1105,11 @@ static void ide_atapi_cmd(IDEState *s)
> /* If there's a UNIT_ATTENTION condition pending, only
> REQUEST_SENSE and INQUIRY commands are allowed to complete. */
> if (s->sense_key == SENSE_UNIT_ATTENTION &&
> - s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
> - s->io_buffer[0] != GPCMD_INQUIRY) {
> - ide_atapi_cmd_check_status(s);
> - return;
> +s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
> +s->io_buffer[0] != GPCMD_INQUIRY &&
> +s->io_buffer[0] != GPCMD_TEST_UNIT_READY) {
> +ide_atapi_cmd_check_status(s);
> +return;
Looks good but please update the comment.
Stefan
Re: [Qemu-devel] [PATCH] virtio-blk: fail unaligned requests
On Wed, Apr 06, 2011 at 08:28:34PM +0200, Christoph Hellwig wrote: > Like all block drivers virtio-blk should not allow small than block size > granularity access. But given that the protocol specifies a > byte unit length field we currently accept such requests, which cause > qemu to abort() in lower layers. Add checks to the main read and > write handlers to catch them early. > > Reported-by: Conor Murphy > Tested-by: Conor Murphy > Signed-off-by: Christoph Hellwig Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On Thu, Apr 07, 2011 at 12:19:01AM -, r...@humppa.name wrote: > @@ -267,6 +267,9 @@ int load_multiboot(void *fw_cfg, > /* if a space comes after the module filename, treat everything > after that as parameters */ > target_phys_addr_t c = mb_add_cmdline(&mbs, initrd_filename); > +/* Kill spaces at the beginning of the filename */ > +while( *initrd_filename == ' ' ) > + initrd_filename++; If we want to do this, shouldn't it be done before adding to the multiboot command-line? Otherwise the multiboot image also has to strip leading spaces. Stefan
[Qemu-devel] [PATCH v3 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
We restrict the commands that a guest can send us after a cdrom change
event. The current list includes REQUEST_SENSE and INQUIRY commands.
Guests can also issue TEST_UNIT_READY to inquire for the status, so
allow this command as well.
This also gets rid of one cause of the HSM violation errors in Linux
guests. Those errors came up because we had the UNIT_ATTENTION event
pending and we replied with an error message to a command that should be
allowed in such a condition. The guest then did a soft reset to get to
a sane state.
Signed-off-by: Amit Shah
---
hw/ide/core.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 007a4ee..d55d804 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1105,10 +1105,11 @@ static void ide_atapi_cmd(IDEState *s)
/* If there's a UNIT_ATTENTION condition pending, only
REQUEST_SENSE and INQUIRY commands are allowed to complete. */
if (s->sense_key == SENSE_UNIT_ATTENTION &&
- s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
- s->io_buffer[0] != GPCMD_INQUIRY) {
- ide_atapi_cmd_check_status(s);
- return;
+s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
+s->io_buffer[0] != GPCMD_INQUIRY &&
+s->io_buffer[0] != GPCMD_TEST_UNIT_READY) {
+ide_atapi_cmd_check_status(s);
+return;
}
switch(s->io_buffer[0]) {
case GPCMD_TEST_UNIT_READY:
--
1.7.4
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
On (Thu) 07 Apr 2011 [09:42:30], Stefan Hajnoczi wrote:
> On Thu, Apr 07, 2011 at 10:35:18AM +0530, Amit Shah wrote:
> > @@ -1105,10 +1105,11 @@ static void ide_atapi_cmd(IDEState *s)
> > /* If there's a UNIT_ATTENTION condition pending, only
> > REQUEST_SENSE and INQUIRY commands are allowed to complete. */
> > if (s->sense_key == SENSE_UNIT_ATTENTION &&
> > - s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
> > - s->io_buffer[0] != GPCMD_INQUIRY) {
> > - ide_atapi_cmd_check_status(s);
> > - return;
> > +s->io_buffer[0] != GPCMD_REQUEST_SENSE &&
> > +s->io_buffer[0] != GPCMD_INQUIRY &&
> > +s->io_buffer[0] != GPCMD_TEST_UNIT_READY) {
> > +ide_atapi_cmd_check_status(s);
> > +return;
>
> Looks good but please update the comment.
Argh! I'll update to a generic one as there are more commands that we
need to allow.
Amit
[Qemu-devel] [PATCH v3 0/2] Correct transitions for cd change state
Hello, These two patches fix the cd media size change bugs. The test scenario is: 1. create an iso image from a file 2. create a second iso image from a bigger file 3. mount 1st cd in guest 4. unmount it 5. change cd via qemu monitor 6. mount 2nd cd 7. copy file on cd to local disk -- shows errors. v2: Set media_change_notified to 1 if SENSE_UNIT_ATTENTION is not set after migration. This is the only thing needed for migration compat. v3: - Use cdrom_changed to hold all state changes instead of introducing a new variable. (Paolo Bonzini) - Slightly better comment and commit messages Please apply. Amit Shah (2): cdrom: Allow the TEST_UNIT_READY command after a cdrom change cdrom: Make disc change event visible to guests hw/ide/core.c | 56 +++- 1 files changed, 47 insertions(+), 9 deletions(-) -- 1.7.4
[Qemu-devel] [PATCH v3 2/2] cdrom: Make disc change event visible to guests
Commit 93c8cfd9e67a62711b86f4c93747566885eb7928 sent a 'no disc' event
after a cdrom change so that guests notice a cd change event between two
'cd present' states. However, we don't follow the 2nd arrow in:
'cd present' -> 'no cd' -> 'cd present'
as the SENSE_UNIT_ATTENTION sense_key is written over by the
ide_atapi_cmd_error() function.
So for the disc change event, let us ensure the error() function doesn't
trample over that value so we do get to report it the next time around.
Also, ensure we go from 'no cd' to 'cd present' state.
With this, older Linux guests (< 2.6.38) notice cd changes just fine.
For newer Linux guests (2.6.38+) cd change events break again and that
will be fixed by implementing the GET_EVENT_STATUS_NOTIFICATION command.
Signed-off-by: Amit Shah
---
hw/ide/core.c | 47 ++-
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index d55d804..3f00cff 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1113,10 +1113,47 @@ static void ide_atapi_cmd(IDEState *s)
}
switch(s->io_buffer[0]) {
case GPCMD_TEST_UNIT_READY:
-if (bdrv_is_inserted(s->bs) && !s->cdrom_changed) {
-ide_atapi_cmd_ok(s);
+if (bdrv_is_inserted(s->bs)) {
+int sense, asc;
+
+sense = s->sense_key;
+asc = s->asc;
+
+/*
+ * Check if there's any pending media change notification
+ * to be given.
+ *
+ * We want the guest to notice an empty tray after a cd
+ * change, so that the guest can trigger its new media
+ * paths. So send one MEDIUM_NOT_PRESENT message after a
+ * cd change.
+ *
+ * After we've sent that message, the guest will poke at
+ * us again. Send the UNIT_ATTENTION message then. Once
+ * this is done, reset the UNIT_ATTENTION message to
+ * ensure we don't keep repeating it.
+ */
+switch(s->cdrom_changed) {
+case 0:
+ide_atapi_cmd_ok(s);
+break;
+case 1:
+s->sense_key = SENSE_UNIT_ATTENTION;
+s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
+ide_atapi_cmd_ok(s);
+
+ sense = SENSE_NONE;
+s->cdrom_changed--;
+break;
+case 2:
+ide_atapi_cmd_error(s, SENSE_NOT_READY,
+ASC_MEDIUM_NOT_PRESENT);
+s->cdrom_changed--;
+break;
+}
+s->sense_key = sense;
+s->asc = asc;
} else {
-s->cdrom_changed = 0;
ide_atapi_cmd_error(s, SENSE_NOT_READY,
ASC_MEDIUM_NOT_PRESENT);
}
@@ -1612,7 +1649,7 @@ static void cdrom_change_cb(void *opaque, int reason)
s->sense_key = SENSE_UNIT_ATTENTION;
s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
-s->cdrom_changed = 1;
+s->cdrom_changed = 2;
ide_set_irq(s->bus);
}
@@ -2712,7 +2749,7 @@ static int ide_drive_post_load(void *opaque, int
version_id)
if (version_id < 3) {
if (s->sense_key == SENSE_UNIT_ATTENTION &&
s->asc == ASC_MEDIUM_MAY_HAVE_CHANGED) {
-s->cdrom_changed = 1;
+s->cdrom_changed = 2;
}
}
return 0;
--
1.7.4
Re: [Qemu-devel] [PATCH 1/5] ppce500_mpc8544ds: Fix compile with --enable-debug and --disable-kvm
On 07.04.2011 18:42, Alexander Graf wrote: On 07.04.2011, at 05:02, David Gibson wrote: From: Alexey Kardashevskiy When configured with --enable-debug, the makefile does not use any optimization and compilation of hw/ppce500_mpc8544ds.c fails because gcc does not remove the never called without kvm function mpc8544_copy_soc_cell(), which will fail to link without the kvm code. I'm not sure I can follow. So the problem is that we call kvmppc_read_host_property and don't provide a stub wrapper for it? Let's provide a wrapper then instead of crippling the target code :) The problems exists only with --disable-kvm and --enable-debug. Without --enable-debug, qemu is compiled with -O2, gcc detects that kvm_enabled() always returns false and optimizes out mpc8544_copy_soc_cell calls which will not be called anyway. With --enable-debug, the linker cannot find symbols which it won't call anyway. alexey.
[Qemu-devel] Re: [PATCH v2 2/2] rbd: allow configuration of rados from the rbd filename
On Thu, Apr 07, 2011 at 10:14:03AM +0900, Yoshiaki Tamura wrote: > 2011/3/29 Josh Durgin : > > The new format is > > rbd:pool/image[@snapshot][:option1=value1[:option2=value2...]] > > Each option is used to configure rados, and may be any Ceph option, or > > "conf". > > The "conf" option specifies a Ceph configuration file to read. > > > > This allows rbd volumes from more than one Ceph cluster to be used by > > specifying different monitor addresses, as well as having different > > logging levels or locations for different volumes. > > > > Signed-off-by: Josh Durgin > > --- > > block/rbd.c | 119 > > ++ > > 1 files changed, 102 insertions(+), 17 deletions(-) > > > > diff --git a/block/rbd.c b/block/rbd.c > > index cb76dd3..bc3323d 100644 > > --- a/block/rbd.c > > +++ b/block/rbd.c > > @@ -22,13 +22,17 @@ > > /* > > * When specifying the image filename use: > > * > > - * rbd:poolname/devicename > > + * > > rbd:poolname/devicename[@snapshotname][:option1=value1[:option2=value2...]] > > I'm not sure IIUC, but currently this @snapshotname seems to be > meaningless; it doesn't allow you to boot from a snapshot because it's > read only. Am I misunderstanding or tested incorrectly? Read-only block devices are supported by QEMU and can be useful. Stefan
Re: [Qemu-devel] Assorted trivial bugfixes
On Thu, Apr 07, 2011 at 01:02:00PM +1000, David Gibson wrote: > This series contains 5 essentially unrelated trivial bugfixes for qemu > code. Most are aimed at eventually getting virtio devices working on > the pseries target, the others are just annoying build bugs. Thanks, patches 2-4 are in the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Patch 1 is being discussed and patch 5 needs review from Amit, it's too large to throw in here. I will send a pull request today that includes patches 2-4. For more information on the trivial patches tree: http://qemu.org/Contribute/TrivialPatches Stefan
[Qemu-devel] Re: [PATCH v2 2/2] cdrom: Make disc change event visible to guests
On (Thu) 07 Apr 2011 [09:41:09], Stefan Hajnoczi wrote:
> On Thu, Apr 07, 2011 at 10:35:19AM +0530, Amit Shah wrote:
> > + /*
> > +* First, check if there's any pending media change
> > +* notification to be given.
> > +*
> > +* We want the guest to notice an empty tray between a cd
> > +* change, so send one MEDIUM_NOT_PRESENT message after a
> > +* cd change.
> > +*
> > +* After we've sent that message, the guest will poke at
> > +* us again and send the UNIT_ATTENTION message then.
> > +* Once this is done, reset the UNIT_ATTENTION message to
> > +* ensure we don't keep repeating it.
> > +*/
>
> Indentation is off here.
Fixed in v3.
> > +if (!s->media_change_notified) {
> > +ide_atapi_cmd_error(s, SENSE_NOT_READY,
> > +ASC_MEDIUM_NOT_PRESENT);
> > +s->media_change_notified = 1;
> > +} else if (s->cdrom_changed) {
> > +s->sense_key = SENSE_UNIT_ATTENTION;
> > +s->asc = ASC_MEDIUM_MAY_HAVE_CHANGED;
> > +ide_atapi_cmd_ok(s);
> > +
> > +s->cdrom_changed = 0;
> > + sense = SENSE_NONE;
>
> Indentation is off here.
>
> Otherwise looks good. I will test a Windows 2003 Server guest.
Thanks; I tested Win XP and RHEL6 guests.
Amit
Re: [Qemu-devel] Re: [PATCH] configure: add --version flag
On Thu, Apr 07, 2011 at 09:31:24AM +0200, Paolo Bonzini wrote: > On 04/07/2011 07:12 AM, Mike Frysinger wrote: > > Standard autoconf scripts include a --version flag so people can easily > > query things. Add this to qemu's configure so it too can integrate with > > build systems that have standard autotool helpers. > > > > Signed-off-by: Mike Frysinger > > ACK Applied, thanks. Cheers
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
Am 07.04.2011 07:05, schrieb Amit Shah: > We restrict the commands that a guest can send us after a cdrom change > event. The current list includes REQUEST_SENSE and INQUIRY commands. > Guests can also issue TEST_UNIT_READY to inquire for the status, so > allow this command as well. > > Signed-off-by: Amit Shah Hm... MMC-5, section 4.1.6.1 seems to conflict with this: "If a Host issues a command other than GET CONFIGURATION, GET EVENT STATUS NOTIFICATION, INQUIRY or REQUEST SENSE while a unit attention condition exists for that Host, the Drive shall not perform the command and shall report CHECK CONDITION status unless a higher priority status as defined by the Drive is also pending." So while you're right that our list is incomplete, TEST UNIT READY doesn't seem to be among the missing commands. Kevin
[Qemu-devel] HELLO
I am writing this letter out of a genuine desperation to find a reliable partner in an unfolding transaction. I seek your help and genuine co-operation to our mutual benefit and I believe that you will not letdown the trust and confidence I am about to repose on you. I am Anita, Purchasing Manager to Gss solid minerals company. I used to represent my company to several Asian countries to purchase a product called Xsp solution, this is a chemical liquid use for cleaning Gold, Silvers, Stones and soon. Now, our company want to send another staff from our company duo to my inability to travel this time, that's why am contacting you. I will introduce you to my company's General Manager as the main supplier of the chemical. Per packet of the vaccine cost $6,500 in UNITED STATE, but in Asia Malaysia where I have been purchasing, it only cost $2,500 per packet and you will supply to my company at the rate of $5,100.Per packet. Note, do not disclose the actual cost of the chemical i.e. $2,500 to my company GM as this will affect our profit. My company's directors don't know the seller of this product and the seller doesn't know my company directors, I 'll introduce you as the main supplier. My company normally purchase 20, 30-150cartons in each trip I make depending on the product we have left in the company. The distributor of this product is a Malaysian, you will purchase the product from the Malaysian dealer and supply to my company, my company will now pay you cash on delivery. Let the above mentioned be in mutual beneficiary for us and an opportunity to embark in future engagements. If you wish to take up this offer, kindly mail me and I will reply you with all the contact details and that of my GM whom you will contact and send you quotation. I will also give you the price to quote.If you have any question, feel free to ask or contact me through my personal e-mail (anitaabdulra...@hotmail.co.uk) Best regards Anita Abdul Razak GSS Solid Minerals E-mail: anitaabdulra...@hotmail.co.uk
Re: [Qemu-devel] [PATCH 1/5] ppce500_mpc8544ds: Fix compile with --enable-debug and --disable-kvm
On 07.04.2011, at 10:52, Alexey Kardashevskiy wrote: > On 07.04.2011 18:42, Alexander Graf wrote: >> On 07.04.2011, at 05:02, David Gibson wrote: >> >>> From: Alexey Kardashevskiy >>> >>> When configured with --enable-debug, the makefile does not use any >>> optimization and compilation of hw/ppce500_mpc8544ds.c fails because gcc >>> does not remove the never called without kvm function >>> mpc8544_copy_soc_cell(), which will fail to link without the kvm code. >> I'm not sure I can follow. So the problem is that we call >> kvmppc_read_host_property and don't provide a stub wrapper for it? Let's >> provide a wrapper then instead of crippling the target code :) > > The problems exists only with --disable-kvm and --enable-debug. Without > --enable-debug, qemu is compiled with -O2, gcc detects that kvm_enabled() > always returns false and optimizes out mpc8544_copy_soc_cell calls which will > not be called anyway. With --enable-debug, the linker cannot find symbols > which it won't call anyway. Ah, there is the kvm_enabled path. I would still find it a superior approach to provide a stub function for the missing call. Potentially, the target should be built without knowledge of config options. Alex
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
On (Thu) 07 Apr 2011 [10:59:20], Kevin Wolf wrote:
> Am 07.04.2011 07:05, schrieb Amit Shah:
> > We restrict the commands that a guest can send us after a cdrom change
> > event. The current list includes REQUEST_SENSE and INQUIRY commands.
> > Guests can also issue TEST_UNIT_READY to inquire for the status, so
> > allow this command as well.
> >
> > Signed-off-by: Amit Shah
>
> Hm... MMC-5, section 4.1.6.1 seems to conflict with this:
>
> "If a Host issues a command other than GET CONFIGURATION, GET EVENT
> STATUS NOTIFICATION, INQUIRY or REQUEST SENSE while a unit attention
> condition exists for that Host, the Drive shall not perform the command
> and shall report CHECK CONDITION status unless a higher priority status
> as defined by the Drive is also pending."
>
> So while you're right that our list is incomplete, TEST UNIT READY
> doesn't seem to be among the missing commands.
Hm - older Linux guests (pre 2.6.38) and Windows guests, as Gleb's
commit mentioned, rely on this command to get CD change notifications:
/* identical to scsi_test_unit_ready except that it doesn't
* eat the NOT_READY returns for removable media */
int sr_test_unit_ready(struct scsi_device *sdev, struct scsi_sense_hdr *sshdr)
{
int retries = MAX_RETRIES;
int the_result;
u8 cmd[] = {TEST_UNIT_READY, 0, 0, 0, 0, 0 };
/* issue TEST_UNIT_READY until the initial startup UNIT_ATTENTION
* conditions are gone, or a timeout happens
*/
do {
the_result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL,
0, sshdr, SR_TIMEOUT,
retries--, NULL);
if (scsi_sense_valid(sshdr) &&
sshdr->sense_key == UNIT_ATTENTION)
sdev->changed = 1;
} while (retries > 0 &&
(!scsi_status_is_good(the_result) ||
(scsi_sense_valid(sshdr) &&
sshdr->sense_key == UNIT_ATTENTION)));
return the_result;
}
There could be something else brewing as well. We never report a
'tray open' condition; maybe the guest will be happy with such a thing
as well. Will have to check.
Amit
[Qemu-devel] Re: [PATCH v3 0/2] Correct transitions for cd change state
Windows Server 2003 works - media change is detected and size is updated correctly. Tested-by: Stefan Hajnoczi
[Qemu-devel] Re: [PATCH v3 0/2] Correct transitions for cd change state
On 04/07/2011 10:46 AM, Amit Shah wrote: Hello, These two patches fix the cd media size change bugs. The test scenario is: 1. create an iso image from a file 2. create a second iso image from a bigger file 3. mount 1st cd in guest 4. unmount it 5. change cd via qemu monitor 6. mount 2nd cd 7. copy file on cd to local disk -- shows errors. v2: Set media_change_notified to 1 if SENSE_UNIT_ATTENTION is not set after migration. This is the only thing needed for migration compat. v3: - Use cdrom_changed to hold all state changes instead of introducing a new variable. (Paolo Bonzini) - Slightly better comment and commit messages Please apply. Amit Shah (2): cdrom: Allow the TEST_UNIT_READY command after a cdrom change cdrom: Make disc change event visible to guests hw/ide/core.c | 56 +++- 1 files changed, 47 insertions(+), 9 deletions(-) Thanks! Reviewed-by: Paolo Bonzini Paolo
Re: [Qemu-devel] KVM call agenda for April 05
On 04/06/2011 02:00 AM, Anthony Liguori wrote: On 04/05/2011 03:25 PM, Peter Maydell wrote: On 5 April 2011 14:14, Stefan Hajnoczi wrote: This stems from the fact that development is centered around the mailing list. Some folks have put technical documentation on the wiki but a lot simply happens on the mailing list. I'm unsure how we can sustainably keep the wiki up-to-date on detailed code internals knowledge. Any suggestions, any examples of projects doing this successfully? Well, Libvirt community does follow the practice of requiring the patch submitter to provide enough documentation within docs/ folder or in the patch itself. The commiter ensures that the docs/ are updated with the patch desc if docs/ are not updated as a part of the patch. See http://libvirt.org/hacking.html#patches Another approach would be to try to increase the use of docs/ for technical code internals information. The advantage would be that we could choose to require docs/ updates for design changes in order for a code change to pass patch review; the disadvantage would be that it's inevitably more of a pain to update. Yes, Its better to have code and docs being updated together with the patches coming in, however, it will become more difficult to follow this practice if it is not followed regularly, for. eg, if patch A doesnt updates the docs as required, and a patch B which is based on Patch A wants to update docs, it needs to get the required docuemntation for patch A first before putting documentation for the patch B itself. We've been unofficially doing that for a lot of recent stuff. I don't know that that really helps with the problem of keeping it up to date though. Well, as we have been doing it unofficially for recent stuff, it will be better to have it officially now :). It shall definitely help, as it gives an opportunity to even update an obsolete piece of info as compared to having no docs to update. As they say, something is better than nothing ! regards, Harsh Regards, Anthony Liguori -- PMM
[Qemu-devel] Re: [PATCH v2 2/2] rbd: allow configuration of rados from the rbd filename
2011/4/7 Stefan Hajnoczi : > On Thu, Apr 07, 2011 at 10:14:03AM +0900, Yoshiaki Tamura wrote: >> 2011/3/29 Josh Durgin : >> > The new format is >> > rbd:pool/image[@snapshot][:option1=value1[:option2=value2...]] >> > Each option is used to configure rados, and may be any Ceph option, or >> > "conf". >> > The "conf" option specifies a Ceph configuration file to read. >> > >> > This allows rbd volumes from more than one Ceph cluster to be used by >> > specifying different monitor addresses, as well as having different >> > logging levels or locations for different volumes. >> > >> > Signed-off-by: Josh Durgin >> > --- >> > block/rbd.c | 119 >> > ++ >> > 1 files changed, 102 insertions(+), 17 deletions(-) >> > >> > diff --git a/block/rbd.c b/block/rbd.c >> > index cb76dd3..bc3323d 100644 >> > --- a/block/rbd.c >> > +++ b/block/rbd.c >> > @@ -22,13 +22,17 @@ >> > /* >> > * When specifying the image filename use: >> > * >> > - * rbd:poolname/devicename >> > + * >> > rbd:poolname/devicename[@snapshotname][:option1=value1[:option2=value2...]] >> >> I'm not sure IIUC, but currently this @snapshotname seems to be >> meaningless; it doesn't allow you to boot from a snapshot because it's >> read only. Am I misunderstanding or tested incorrectly? > > Read-only block devices are supported by QEMU and can be useful. I agree. My expectation was that @snapshotname is introduced to have writable snapshot. Yoshi > > Stefan >
Re: [Qemu-devel] KVM call minutes for Apr 5
On Tue, Apr 5, 2011 at 6:37 PM, Lucas Meneghel Rodrigues wrote: Thanks for your detailed response! > On Tue, 2011-04-05 at 16:29 +0100, Stefan Hajnoczi wrote: >> * Public notifications of breakage, qemu.git/master failures to >> qemu-devel mailing list. > > ^ The challenge is to get enough data to determine what is a new > breakage from a known issue, mainly. More related to have historical > data from test results than anything else, IMO. I agree. Does kvm-autotest currently archive test results? >> * A one-time contributor can get their code tested. No requirement to >> set up a server because contributors may not have the resources. > > Coming back to the point that many colleagues made: We need a sort of > 'make test' on the qemu trees that would fetch autotest and could setup > basic tests that people could run, maybe suggest test sets... > > The problem I see is, getting guests up and running using configs that > actually matter is not trivial (there are things such as ensuring that > all auxiliary utilities are installed in a distro agnostic fashion, > having bridges and DHCP server setup on possibly a disconnected work > laptop, and stuff). > > So, having a 'no brains involved at all' setup is quite a challenge, > suggestions welcome. Also, downloading isos, waiting for guests to > install and run thorough tests won't be fast. So J. Random Developer > might not bother to run tests even if we can provide a fool proof, > perfectly automated setup, because it'd take a long time at first to get > the tests run. This is also a challenge. I'm actually starting to think that there is no one-size-fits-all solution. Developers need "make check"-type unit tests for various QEMU subsystems. kvm-autotest could also run these unit tests as part of its execution. Then there are end-to-end acceptance tests. They simply require storage, network, and time resources and there's no way around that. These tests are more suited to centralized testing infrastructure that periodically tests qemu.git. On the community call I was trying to see if there is a "lightweight" version of kvm-autotest that could be merged into qemu.git. But now I think that this isn't realistic and it would be better to grow unit tests in qemu.git while covering it with kvm-autotest for acceptance testing. >> Perhaps kvm-autotest is a good platform for the automated testing of >> ARM TCG. Paul is CCed, I recently saw the Jenkins qemu build and boot >> tests he has set up. Lucas, do you have ideas on how these efforts >> can work together to bring testing to upstream QEMU? >> http://validation.linaro.org/jenkins/job/qemu-boot-images/ > > I heard about jenkins before and it is indeed a nice project. What they > do here, from what I could assess browsing at the webpage you provided > is: > > 1) Build qemu.git every time there are commits > 2) Boot pre-made 'pristine' images, one is a lenny arm image and the > other is a linaro arm image. > > It is possible to do the same with kvm autotest, just a matter of not > performing guest install tests and executing only the boot tests with > pre-made images. What jenkins does here is a even quicker and shorter > version of our sanity jobs. > > About how we can work together, I thought about some possibilities: > > 1) Modify the jenkins test step to execute a kvm autotest job after the > build, with the stripped down test set. We might gain some extra debug > info, that the current test step does not seem to provide > 2) Do the normal test step and if that succeeds, trigger a kvm autotest > job that does more comprehensive testing, such as migration, time drift, > block layer, etc > > The funny thing is that KVM autotest has infrastructure to do the same > as jenkins does, but jenkins is highly streamlined for the buildbot use > case (continuous build and integration), and I see that as a very nice > advantage. So I'd rather keep use jenkins and have kvm autotest plugged > into it conveniently. That sounds good. I think the benefit of working together is that different entities (Linaro, Red Hat, etc) can contribute QEMU tests into a single place. That testing can then cover to both upstream and downstream to prevent breakage. So kvm-autotest can run in single job mode and kicked off from jenkins or buildbot? It sounds like kvm-autotest has or needs its own cron, result archiving, etc infrastructure. Does it make sense to use a harness like jenkins or buildbot instead and focus kvm-autotest purely as a testing framework? Stefan
Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI
On Wed, Apr 06, 2011 at 11:54:47PM +0100, Paul Brook wrote: > > > Last year, I was also interested in working on S3 Trio emulation. This > > > year, the same idea is on the ideas list. The hardware is pretty > > > thoroughly documented through source code and textual documentation, and > > > I'm already familiar with adding PCI devices to Qemu, so I do see a > > > rough outline of how I would implement it. > > > > > > However, last year, Paul Brook commented [1] that he wasn't convinced > > > about the usefulness of emulating an S3 Trio or Virge card, because of > > > performance reasons. He suggested that accelerating the 2D engine would > > > be tricky because the framebuffer is exposed to the guest. This might be > > > just me not fully understanding his point, but isn't this also the case > > > with the Cirrus Logic GD5446 card? > > > > > > He also suggested paravirtualization for 3D acceleration. Do you think > > > it would make a good summer project? > > > > I can't comment on these issues, CC'ing Paul, Anthony and Stefan. > > My understanding is that Cirrus logic cards also have 2D acceleration. We > implement this in qemu, but not in a way that's likely to be fast. I don't > really know either card in detail, but they're both a similar age, so I'd > expect the functionality to be fairly similar. > > The 2D engines you're talking about are of questionable benefit. IIUC > They're > basically a memcpy engine with some weird bitmasking operations that line up > with the windows 3 GDI raster ops. While accelerating this maybe made sense > on a 386, it's not worth the effort on modern CPUs. The latency and overhead > of setting up and syncronising with the async blit engine is greater than the > cost of just doing it in software. In practice modern desktop environments > just use the 3D engine. > > IMO emulating useful 'real' 3D hardware is not feasible. In theory you could > emulate an old card, however these are also of limited practical benefit. > For > the S3 cards the 3D engine is so crippled that even when new it wasn't worth > using. You could maybe implement an old fixed-function card like, e.g. an > i810 or 3dfx card, however drivers for these are also getting hard to come > by, > and the functionality is still limited. You basically get raster offloading, > and everything else is done in software. Emulation overhead may be greater > than useful offloaded work. > > For good 3D support you're looking at something shader based. Emulating real > hardware is not going to happen. With real hardware the interface qemu needs > to emulate is directly tied to the implementation details of that particular > chipset. The guest driver generally uses intimate knowledge of these > implementation details (e.g. vram layout, shader ISA). Different > implementations may provide the same high-level functionality, however the > low-level implementations are very different. Reconstructing high-level > operations from the low-level stream is extremely hard, probably harder than > the main CPU emulation that qemu does. > > IMO a good rule of thumb is that the output of the render pipeline should not > be guest visible. Anything where the guest can observe/manipulate the output > or intermediate results makes it very hard to isolate the guest from the > implementation details (i.e. whatever hardware acceleration the host > provides). > > There are already a handful of different paravirtual graphics drivers, of > varying quality and openness. This includes: > > - Several OpenGL passthrough drivers. These are effectively just re- > implementing GLX, often badly. I suspect that given a decent virtual > network, > remote X (including 3D via GLX) already works pretty well. > > - SPICE. IIUC this is an ugly hack that maps directly onto legacy Windows/GDI Hey, take that back! ;) except for the ugly and hack parts, yes. Also has grown surfaces support to map better to how X works. > operations. I'm not aware of any substantive plan for making this work well > in other environments (using the subset that's basically a dumb framebuffer > doesn't count), or for doing 3D. We are planning 3D support, based on shaders (basically, vgallium), feature page is http://spice-space.org/page/Features/Spice3D > > - Whatever VMware uses. > > - Whatever VirtualBox uses. > > - At least two gallium3D based projects. I think this includes Xen, and > possibly VirtualBox. Given the whole point of Gallium3D is to provide a > common abstraction layer between the application API and the hardware this > would be my choice. > > Paul >
Re: [Qemu-devel] How long does it normally take patches to make their way into git?
On Wed, 6 Apr 2011, Stefan Hajnoczi wrote: > On Wed, Apr 6, 2011 at 3:59 PM, John Haxby wrote: > > Hello, > > > > How long does it normally take patches to make their way into git? I > > only ask because > > > > [PATCH 1/2][REPOST] Introduce a new 'connected' xendev op called when > > Connected. > > [PATCH 2/2][REPOST] Move the xenfb pointer handler to the connected method > > > > were (reposted) just under a month ago (11-Mar-2011) and I have a vested > > interest in them :-) > > > > I'm quite happy to wait but I want to make sure that they're acceptable > > and, if so, that they will eventually appear. > > This has been discussed recently and there are efforts underway to > improve it, basically we need more active subsystem maintainers to > make the development process scale. > > How about Stefano or Anthony Perard collect Xen patches that look good > and have at least one Ack/Reviewed-by and send pull requests to > qemu-devel and "Anthony Liguori" ? I am up for it and I think is a good idea, especially after Anthony's patch series is applied, because we'll drop the current qemu-xen tree and start using upstream qemu with xen-unstable.
Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI
On Wed, Apr 06, 2011 at 11:54:47PM +0100, Paul Brook wrote: > > > Last year, I was also interested in working on S3 Trio emulation. This > > > year, the same idea is on the ideas list. The hardware is pretty > > > thoroughly documented through source code and textual documentation, and > > > I'm already familiar with adding PCI devices to Qemu, so I do see a > > > rough outline of how I would implement it. > > > > > > However, last year, Paul Brook commented [1] that he wasn't convinced > > > about the usefulness of emulating an S3 Trio or Virge card, because of > > > performance reasons. He suggested that accelerating the 2D engine would > > > be tricky because the framebuffer is exposed to the guest. This might be > > > just me not fully understanding his point, but isn't this also the case > > > with the Cirrus Logic GD5446 card? > > > > > > He also suggested paravirtualization for 3D acceleration. Do you think > > > it would make a good summer project? > > > > I can't comment on these issues, CC'ing Paul, Anthony and Stefan. > > My understanding is that Cirrus logic cards also have 2D acceleration. We > implement this in qemu, but not in a way that's likely to be fast. I don't > really know either card in detail, but they're both a similar age, so I'd > expect the functionality to be fairly similar. > > The 2D engines you're talking about are of questionable benefit. IIUC > They're > basically a memcpy engine with some weird bitmasking operations that line up > with the windows 3 GDI raster ops. While accelerating this maybe made sense > on a 386, it's not worth the effort on modern CPUs. The latency and overhead > of setting up and syncronising with the async blit engine is greater than the > cost of just doing it in software. In practice modern desktop environments > just use the 3D engine. > > IMO emulating useful 'real' 3D hardware is not feasible. In theory you could > emulate an old card, however these are also of limited practical benefit. > For > the S3 cards the 3D engine is so crippled that even when new it wasn't worth > using. You could maybe implement an old fixed-function card like, e.g. an > i810 or 3dfx card, however drivers for these are also getting hard to come > by, > and the functionality is still limited. You basically get raster offloading, > and everything else is done in software. Emulation overhead may be greater > than useful offloaded work. > > For good 3D support you're looking at something shader based. Emulating real > hardware is not going to happen. With real hardware the interface qemu needs > to emulate is directly tied to the implementation details of that particular > chipset. The guest driver generally uses intimate knowledge of these > implementation details (e.g. vram layout, shader ISA). Different > implementations may provide the same high-level functionality, however the > low-level implementations are very different. Reconstructing high-level > operations from the low-level stream is extremely hard, probably harder than > the main CPU emulation that qemu does. > > IMO a good rule of thumb is that the output of the render pipeline should not > be guest visible. Anything where the guest can observe/manipulate the output > or intermediate results makes it very hard to isolate the guest from the > implementation details (i.e. whatever hardware acceleration the host > provides). > > There are already a handful of different paravirtual graphics drivers, of > varying quality and openness. This includes: > > - Several OpenGL passthrough drivers. These are effectively just re- > implementing GLX, often badly. I suspect that given a decent virtual > network, > remote X (including 3D via GLX) already works pretty well. > > - SPICE. IIUC this is an ugly hack that maps directly onto legacy Windows/GDI > operations. I'm not aware of any substantive plan for making this work well > in other environments (using the subset that's basically a dumb framebuffer Also, spice doesn't let the guest touch the framebuffer, unless it explicitly asks for it (printscreen). So most of the time the 2d operations (like you said, they are basically the gdi lexicon) are passed to the server and from it to the client, which actually performs them. If you do a printscreen the server also has to perform them to provide the updated framebuffer to the guest. The guest however doesn't write to the framebuffers. > doesn't count), or for doing 3D. > > - Whatever VMware uses. > > - Whatever VirtualBox uses. > > - At least two gallium3D based projects. I think this includes Xen, and > possibly VirtualBox. Given the whole point of Gallium3D is to provide a > common abstraction layer between the application API and the hardware this > would be my choice. > > Paul >
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
Leading spaces mustn't be stripped! The commandline could look like: qemu -kernel kern -initrd "1.mod arg=foo arg2=bar, 2.mod arg=asdf" The problem is, that the string "1.mod arg=foo arg2=bar, 2.mod arg=asdf" is divided at the ','. So we have two string "1.mod arg=foo arg2=bar" and " 2.mod arg=asdf" ^ This space causes the error "Failed to get image size" So just the spaces at the beginning of the file have to be stripped. Spaces at the end could be important for the commandline. E.g. -initrd "1.mod arg=argwithmanyspaces, 2.mod" -- Ralf > If we want to do this, shouldn't it be done before adding to the > multiboot command-line? Otherwise the multiboot image also has to strip > leading spaces. > > Stefan >
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
Am 07.04.2011 11:11, schrieb Amit Shah:
> On (Thu) 07 Apr 2011 [10:59:20], Kevin Wolf wrote:
>> Am 07.04.2011 07:05, schrieb Amit Shah:
>>> We restrict the commands that a guest can send us after a cdrom change
>>> event. The current list includes REQUEST_SENSE and INQUIRY commands.
>>> Guests can also issue TEST_UNIT_READY to inquire for the status, so
>>> allow this command as well.
>>>
>>> Signed-off-by: Amit Shah
>>
>> Hm... MMC-5, section 4.1.6.1 seems to conflict with this:
>>
>> "If a Host issues a command other than GET CONFIGURATION, GET EVENT
>> STATUS NOTIFICATION, INQUIRY or REQUEST SENSE while a unit attention
>> condition exists for that Host, the Drive shall not perform the command
>> and shall report CHECK CONDITION status unless a higher priority status
>> as defined by the Drive is also pending."
>>
>> So while you're right that our list is incomplete, TEST UNIT READY
>> doesn't seem to be among the missing commands.
>
> Hm - older Linux guests (pre 2.6.38) and Windows guests, as Gleb's
> commit mentioned, rely on this command to get CD change notifications:
>
> /* identical to scsi_test_unit_ready except that it doesn't
> * eat the NOT_READY returns for removable media */
> int sr_test_unit_ready(struct scsi_device *sdev, struct scsi_sense_hdr *sshdr)
> {
> int retries = MAX_RETRIES;
> int the_result;
> u8 cmd[] = {TEST_UNIT_READY, 0, 0, 0, 0, 0 };
>
> /* issue TEST_UNIT_READY until the initial startup UNIT_ATTENTION
> * conditions are gone, or a timeout happens
> */
> do {
> the_result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL,
> 0, sshdr, SR_TIMEOUT,
> retries--, NULL);
> if (scsi_sense_valid(sshdr) &&
> sshdr->sense_key == UNIT_ATTENTION)
> sdev->changed = 1;
>
> } while (retries > 0 &&
> (!scsi_status_is_good(the_result) ||
> (scsi_sense_valid(sshdr) &&
>sshdr->sense_key == UNIT_ATTENTION)));
> return the_result;
> }
I think the scsi_execute_req() call might issue a REQUEST SENSE
internally and therefore clear the unit attention condition. Tried to
check that in the source, but I'm hopelessly lost in the kernel...
Kevin
[Qemu-devel] [PATCH 0/5] kvm/vhost: enable durty logging during memory registration
I've tested and applied this patchset on my tree. Currently, vga cards that allocate vga ram, register it as regular ram, and then request dirty logging from kvm (which is required for this hack to function correctly). Both these operations involve memory slot update and flush in kvm and in vhost which is a slow operation. This was observed to slow down windows guests with a huge amount of memory and cpu and with cirrus vga. As a solution, this adds an explicit flag that will enable dirty logging directly when registering the ram. kvm then needs a single system call to update tables for vga ram, vhost-net can simply ignore it. This patchset only updates the cirrus vga lfb vram mapping. Follow-up patchsets will update all the rest of the cards and then remove vga_dirty_log_xxx completely. This replaces the RFC patchset as well as the RFC 'vga: flag vga ram for notifiers'. Changes since RFC: in patch vhost: optimize out no-change assignment, moved the no-change test to later in function to catch more cases. Test setup: host: 512G -smp 64 guest -m 256G -smp 32 cirrus vga; windows boot time goes down from 30 min to 1 min. Michael S. Tsirkin (5): cpu: add set_memory flag to request dirty logging kvm: halve number of set memory calls for vga vhost: skip memory which needs dirty logging vhost: optimize out no-change assignment cirrus_vga: flag on-device ram for dirty logging cpu-common.h| 22 +++ exec.c | 14 +++- hw/cirrus_vga.c | 16 + hw/vhost.c | 61 +- kvm-all.c | 62 +- 5 files changed, 134 insertions(+), 41 deletions(-) -- 1.7.3.2.91.g446ac
[Qemu-devel] [PATCH 3/5] vhost: skip memory which needs dirty logging
vhost doesn't support write logging
(except for migration), anyway.
Signed-off-by: Michael S. Tsirkin
---
hw/vhost.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index dc3d0e2..257e3dd 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -311,6 +311,10 @@ static void vhost_client_set_memory(CPUPhysMemoryClient
*client,
int r;
dev->mem = qemu_realloc(dev->mem, s);
+if (log_dirty) {
+flags = IO_MEM_UNASSIGNED;
+}
+
assert(size);
vhost_dev_unassign_memory(dev, start_addr, size);
--
1.7.3.2.91.g446ac
[Qemu-devel] [PATCH 1/5] cpu: add set_memory flag to request dirty logging
Pass the flag to all cpu notifiers, doing
nothing at this point. Will be used by
follow-up patches.
Signed-off-by: Michael S. Tsirkin
---
cpu-common.h | 22 +-
exec.c | 14 --
hw/vhost.c |3 ++-
kvm-all.c|3 ++-
4 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index ef4e8da..c239cc0 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -34,10 +34,21 @@ typedef unsigned long ram_addr_t;
typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr,
uint32_t value);
typedef uint32_t CPUReadMemoryFunc(void *opaque, target_phys_addr_t addr);
-void cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
- ram_addr_t size,
- ram_addr_t phys_offset,
- ram_addr_t region_offset);
+void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
+ ram_addr_t size,
+ ram_addr_t phys_offset,
+ ram_addr_t region_offset,
+ bool log_dirty);
+
+static inline void cpu_register_physical_memory_offset(target_phys_addr_t
start_addr,
+ ram_addr_t size,
+ ram_addr_t phys_offset,
+ ram_addr_t
region_offset)
+{
+cpu_register_physical_memory_log(start_addr, size, phys_offset,
+ region_offset, false);
+}
+
static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
ram_addr_t size,
ram_addr_t phys_offset)
@@ -91,7 +102,8 @@ struct CPUPhysMemoryClient {
void (*set_memory)(struct CPUPhysMemoryClient *client,
target_phys_addr_t start_addr,
ram_addr_t size,
- ram_addr_t phys_offset);
+ ram_addr_t phys_offset,
+ bool log_dirty);
int (*sync_dirty_bitmap)(struct CPUPhysMemoryClient *client,
target_phys_addr_t start_addr,
target_phys_addr_t end_addr);
diff --git a/exec.c b/exec.c
index 964ce31..d1a066c 100644
--- a/exec.c
+++ b/exec.c
@@ -1711,11 +1711,12 @@ static QLIST_HEAD(memory_client_list,
CPUPhysMemoryClient) memory_client_list
static void cpu_notify_set_memory(target_phys_addr_t start_addr,
ram_addr_t size,
- ram_addr_t phys_offset)
+ ram_addr_t phys_offset,
+ bool log_dirty)
{
CPUPhysMemoryClient *client;
QLIST_FOREACH(client, &memory_client_list, list) {
-client->set_memory(client, start_addr, size, phys_offset);
+client->set_memory(client, start_addr, size, phys_offset, log_dirty);
}
}
@@ -1755,7 +1756,7 @@ static void phys_page_for_each_1(CPUPhysMemoryClient
*client,
for (i = 0; i < L2_SIZE; ++i) {
if (pd[i].phys_offset != IO_MEM_UNASSIGNED) {
client->set_memory(client, pd[i].region_offset,
- TARGET_PAGE_SIZE, pd[i].phys_offset);
+ TARGET_PAGE_SIZE, pd[i].phys_offset, false);
}
}
} else {
@@ -2600,10 +2601,11 @@ static subpage_t *subpage_init (target_phys_addr_t
base, ram_addr_t *phys,
start_addr and region_offset are rounded down to a page boundary
before calculating this offset. This should not be a problem unless
the low bits of start_addr and region_offset differ. */
-void cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
+void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
ram_addr_t size,
ram_addr_t phys_offset,
- ram_addr_t region_offset)
+ ram_addr_t region_offset,
+ bool log_dirty)
{
target_phys_addr_t addr, end_addr;
PhysPageDesc *p;
@@ -2611,7 +2613,7 @@ void
cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
ram_addr_t orig_size = size;
subpage_t *subpage;
-cpu_notify_set_memory(start_addr, size, phys_offset);
+cpu_notify_set_memory(start_addr, size, phys_offset, log_dirty);
if (phys_offset == IO_MEM_UNASSIGNED) {
region_offset = start_addr;
diff --git a/hw/vhost.c b/hw/vhost.c
index 14b571d..dc3d0e2 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -300,7 +300,8 @@ static int vhost_verify_ring_mappings(struct vhost_dev *dev,
[Qemu-devel] [PATCH 2/5] kvm: halve number of set memory calls for vga
use the new api to reduce the number of these (expensive)
system calls.
Note: using this API, we should be able to
get rid of vga_dirty_log_xxx APIs. Using them doesn't
affect the performance though because we detects
the log_dirty flag set and ignores the call.
Signed-off-by: Michael S. Tsirkin
---
kvm-all.c | 59 ---
1 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 1647e1a..7ace9a2 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -245,48 +245,60 @@ err:
/*
* dirty pages logging control
*/
-static int kvm_dirty_pages_log_change(target_phys_addr_t phys_addr,
- ram_addr_t size, int flags, int mask)
+
+static int kvm_mem_flags(KVMState *s, bool log_dirty)
+{
+return log_dirty ? KVM_MEM_LOG_DIRTY_PAGES : 0;
+}
+
+static int kvm_slot_dirty_pages_log_change(KVMSlot *mem, bool log_dirty)
{
KVMState *s = kvm_state;
-KVMSlot *mem = kvm_lookup_matching_slot(s, phys_addr, phys_addr + size);
+int flags, mask = KVM_MEM_LOG_DIRTY_PAGES;
int old_flags;
-if (mem == NULL) {
-fprintf(stderr, "BUG: %s: invalid parameters " TARGET_FMT_plx "-"
-TARGET_FMT_plx "\n", __func__, phys_addr,
-(target_phys_addr_t)(phys_addr + size - 1));
-return -EINVAL;
-}
-
old_flags = mem->flags;
-flags = (mem->flags & ~mask) | flags;
+flags = (mem->flags & ~mask) | kvm_mem_flags(s, log_dirty);
mem->flags = flags;
/* If nothing changed effectively, no need to issue ioctl */
if (s->migration_log) {
flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
+
if (flags == old_flags) {
-return 0;
+return 0;
}
return kvm_set_user_memory_region(s, mem);
}
+static int kvm_dirty_pages_log_change(target_phys_addr_t phys_addr,
+ ram_addr_t size, bool log_dirty)
+{
+KVMState *s = kvm_state;
+KVMSlot *mem = kvm_lookup_matching_slot(s, phys_addr, phys_addr + size);
+
+if (mem == NULL) {
+fprintf(stderr, "BUG: %s: invalid parameters " TARGET_FMT_plx "-"
+TARGET_FMT_plx "\n", __func__, phys_addr,
+(target_phys_addr_t)(phys_addr + size - 1));
+return -EINVAL;
+}
+return kvm_slot_dirty_pages_log_change(mem, log_dirty);
+}
+
static int kvm_log_start(CPUPhysMemoryClient *client,
target_phys_addr_t phys_addr, ram_addr_t size)
{
-return kvm_dirty_pages_log_change(phys_addr, size, KVM_MEM_LOG_DIRTY_PAGES,
- KVM_MEM_LOG_DIRTY_PAGES);
+return kvm_dirty_pages_log_change(phys_addr, size, true);
}
static int kvm_log_stop(CPUPhysMemoryClient *client,
target_phys_addr_t phys_addr, ram_addr_t size)
{
-return kvm_dirty_pages_log_change(phys_addr, size, 0,
- KVM_MEM_LOG_DIRTY_PAGES);
+return kvm_dirty_pages_log_change(phys_addr, size, false);
}
static int kvm_set_migration_log(int enable)
@@ -495,7 +507,7 @@ kvm_check_extension_list(KVMState *s, const
KVMCapabilityInfo *list)
}
static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
- ram_addr_t phys_offset)
+ ram_addr_t phys_offset, bool log_dirty)
{
KVMState *s = kvm_state;
ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
@@ -520,7 +532,8 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr,
ram_addr_t size,
(start_addr + size <= mem->start_addr + mem->memory_size) &&
(phys_offset - start_addr == mem->phys_offset - mem->start_addr)) {
/* The new slot fits into the existing one and comes with
- * identical parameters - nothing to be done. */
+ * identical parameters - update flags and done. */
+kvm_slot_dirty_pages_log_change(mem, log_dirty);
return;
}
@@ -550,7 +563,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr,
ram_addr_t size,
mem->memory_size = old.memory_size;
mem->start_addr = old.start_addr;
mem->phys_offset = old.phys_offset;
-mem->flags = 0;
+mem->flags = kvm_mem_flags(s, log_dirty);
err = kvm_set_user_memory_region(s, mem);
if (err) {
@@ -571,7 +584,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr,
ram_addr_t size,
mem->memory_size = start_addr - old.start_addr;
mem->start_addr = old.start_addr;
mem->phys_offset = old.phys_offset;
-mem->flags = 0;
+mem->flags = kvm_mem_flags(s, log_dirty);
err = kvm_set_user_memory_region(s, mem);
if (err) {
@@ -590,7 +603,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr,
ram_addr_t size,
s
[Qemu-devel] [PATCH 5/5] cirrus_vga: flag on-device ram for dirty logging
Signed-off-by: Michael S. Tsirkin
---
hw/cirrus_vga.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index bdf4c8b..7212849 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2489,7 +2489,9 @@ static void map_linear_vram(CirrusVGAState *s)
if (!s->vga.map_addr && s->vga.lfb_addr && s->vga.lfb_end) {
s->vga.map_addr = s->vga.lfb_addr;
s->vga.map_end = s->vga.lfb_end;
-cpu_register_physical_memory(s->vga.map_addr, s->vga.map_end -
s->vga.map_addr, s->vga.vram_offset);
+cpu_register_physical_memory_log(s->vga.map_addr,
+s->vga.map_end - s->vga.map_addr,
+s->vga.vram_offset, 0, true);
}
if (!s->vga.map_addr)
@@ -2502,10 +2504,14 @@ static void map_linear_vram(CirrusVGAState *s)
&& !((s->vga.gr[0x0B] & 0x14) == 0x14)
&& !(s->vga.gr[0x0B] & 0x02)) {
-cpu_register_physical_memory(isa_mem_base + 0xa, 0x8000,
-(s->vga.vram_offset +
s->cirrus_bank_base[0]) | IO_MEM_RAM);
-cpu_register_physical_memory(isa_mem_base + 0xa8000, 0x8000,
-(s->vga.vram_offset +
s->cirrus_bank_base[1]) | IO_MEM_RAM);
+cpu_register_physical_memory_log(isa_mem_base + 0xa, 0x8000,
+(s->vga.vram_offset +
+ s->cirrus_bank_base[0]) |
+IO_MEM_RAM, 0, true);
+cpu_register_physical_memory_log(isa_mem_base + 0xa8000, 0x8000,
+(s->vga.vram_offset +
+ s->cirrus_bank_base[1]) |
+IO_MEM_RAM, 0, true);
s->vga.lfb_vram_mapped = 1;
}
--
1.7.3.2.91.g446ac
Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Roland, El 05/04/2011, a las 14:36, Roland Elek escribió: > Dear Qemu developers, > > First, I'd like to reintroduce myself, as my university and official duties > prevented me from being active in the community since last year. I am Roland > Elek, a student from Hungary, and a successful student participant of Google > Summer of Code 2010. This year, I would like to participate again. I know I'm > a bit late, but I'm still hoping to get things arranged before the deadline. > > Last year, I worked on AHCI emulation with Alex as my mentor. Do you think a > proper summer project could be proposed from what is still missing? If so, > can I kindly ask someone to give me some pointers to what the project needs > the most, and where I should look first for things to include in my proposal? > Also, if the idea is feasible, would there be someone who could be my mentor? You should ask Alex himself directly. > Last year, I was also interested in working on S3 Trio emulation. This year, > the same idea is on the ideas list. The hardware is pretty thoroughly > documented through source code and textual documentation, and I'm already > familiar with adding PCI devices to Qemu, so I do see a rough outline of how > I would implement it. > > However, last year, Paul Brook commented [1] that he wasn't convinced about > the usefulness of emulating an S3 Trio or Virge card, because of performance > reasons. He suggested that accelerating the 2D engine would be tricky because > the framebuffer is exposed to the guest. This might be just me not fully > understanding his point, but isn't this also the case with the Cirrus Logic > GD5446 card? The 2D accelenration engine of that cards were merely an implementation of Windows 3.1 GDI calls, a bitblt, draw a circle, so on, over a framebuffer. They are pretty simple and easily converted to GDI+, SDL or Cocoa, whatever QEMU is needing in the host to draw the framebuffer. The idea of emulating a S3 Trio however is not to give 2D acceleration to guests but to have a hardware with wider support from guests. The S3 Trio is supported by almost all known x86 guests and a good couple of non-x86 ones (including BeOS, Windows NT, NeXTStep). The GDI accelerated functions were used only by Windows and only in some resolutions (640x480 at 16 colors mostly). The card's VESA implementation was 2.0 (without 2D acceleration) and buggy enough to have made the manufacturer itself include a software implementation of VESA 3.0. Anyway just digging again on Google shows me that the trio also accelerated YUV to RGB conversion (easily done, I have it in my webcam emulation) and that it is fully emulated by DOSBox (so their source can be used as a start) and of course, like past year, for VirtualPC (so emulation is possible and performance is not bad). > He also suggested paravirtualization for 3D acceleration. Do you think it > would make a good summer project? For this you would need to implement some kind of MPI between guest and host and trap the WGL/GLX/AGL calls and pass them as host WGL/GLX/AGL calls. It is feasible but you should provide your own drivers for the guests because emulating the registers of a real 3D call will be simply performance-nulling. Whatever you think is best for your abilities, apply for it on GSoC webpage. However personally there are already two students applying for S3 and I would prefer everyone to have a choice so I recommend you to apply for the AHCI finishing or 3D virtualization, as you see fit. Regards, Natalia Portillo -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk2dmKcACgkQv/wfOsykIRTxTQD/QM1nKJGpLMRuCokKaoVBUYmK 94xs4L1rcbIXsxYoifwBALLZtuWZI29eP4Nz/DE55E5uX4AV3RHrcWw/ngvOPhD0 =46Q8 -END PGP SIGNATURE-
[Qemu-devel] [PATCH 4/5] vhost: optimize out no-change assignment
Cirrus VGA (at least) calls register memory region
with the same values again and again. The
registration in vhost-net slows this a lot,
optimize by checking that the same data is already registered.
Signed-off-by: Michael S. Tsirkin
---
hw/vhost.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index 257e3dd..80f771e 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -297,6 +297,45 @@ static int vhost_verify_ring_mappings(struct vhost_dev
*dev,
return 0;
}
+static struct vhost_memory_region *vhost_dev_find_reg(struct vhost_dev *dev,
+ uint64_t start_addr,
+ uint64_t size)
+{
+int i, n = dev->mem->nregions;
+for (i = 0; i < n; ++i) {
+struct vhost_memory_region *reg = dev->mem->regions + i;
+if (ranges_overlap(reg->guest_phys_addr, reg->memory_size,
+ start_addr, size)) {
+return reg;
+}
+}
+return NULL;
+}
+
+static bool vhost_dev_cmp_memory(struct vhost_dev *dev,
+ uint64_t start_addr,
+ uint64_t size,
+ uint64_t uaddr)
+{
+struct vhost_memory_region *reg = vhost_dev_find_reg(dev, start_addr,
size);
+uint64_t reglast;
+uint64_t memlast;
+
+if (!reg) {
+return true;
+}
+
+reglast = range_get_last(reg->guest_phys_addr, reg->memory_size);
+memlast = range_get_last(start_addr, size);
+
+/* Need to extend region? */
+if (start_addr < reg->guest_phys_addr || memlast > reglast) {
+return true;
+}
+/* userspace_addr changed? */
+return uaddr != reg->userspace_addr + start_addr - reg->guest_phys_addr;
+}
+
static void vhost_client_set_memory(CPUPhysMemoryClient *client,
target_phys_addr_t start_addr,
ram_addr_t size,
@@ -309,6 +348,7 @@ static void vhost_client_set_memory(CPUPhysMemoryClient
*client,
(dev->mem->nregions + 1) * sizeof dev->mem->regions[0];
uint64_t log_size;
int r;
+
dev->mem = qemu_realloc(dev->mem, s);
if (log_dirty) {
@@ -317,6 +357,20 @@ static void vhost_client_set_memory(CPUPhysMemoryClient
*client,
assert(size);
+/* Optimize no-change case. At least cirrus_vga does this a lot at this
time. */
+if (flags == IO_MEM_RAM) {
+if (!vhost_dev_cmp_memory(dev, start_addr, size,
+ (uintptr_t)qemu_get_ram_ptr(phys_offset))) {
+/* Region exists with same address. Nothing to do. */
+return;
+}
+} else {
+if (!vhost_dev_find_reg(dev, start_addr, size)) {
+/* Removing region that we don't access. Nothing to do. */
+return;
+}
+}
+
vhost_dev_unassign_memory(dev, start_addr, size);
if (flags == IO_MEM_RAM) {
/* Add given mapping, merging adjacent regions if any */
--
1.7.3.2.91.g446ac
[Qemu-devel] Re: [PATCH v2 1/2] cdrom: Allow the TEST_UNIT_READY command after a cdrom change
On (Thu) 07 Apr 2011 [12:20:16], Kevin Wolf wrote:
> Am 07.04.2011 11:11, schrieb Amit Shah:
> > On (Thu) 07 Apr 2011 [10:59:20], Kevin Wolf wrote:
> >> Am 07.04.2011 07:05, schrieb Amit Shah:
> >>> We restrict the commands that a guest can send us after a cdrom change
> >>> event. The current list includes REQUEST_SENSE and INQUIRY commands.
> >>> Guests can also issue TEST_UNIT_READY to inquire for the status, so
> >>> allow this command as well.
> >>>
> >>> Signed-off-by: Amit Shah
> >>
> >> Hm... MMC-5, section 4.1.6.1 seems to conflict with this:
> >>
> >> "If a Host issues a command other than GET CONFIGURATION, GET EVENT
> >> STATUS NOTIFICATION, INQUIRY or REQUEST SENSE while a unit attention
> >> condition exists for that Host, the Drive shall not perform the command
> >> and shall report CHECK CONDITION status unless a higher priority status
> >> as defined by the Drive is also pending."
> >>
> >> So while you're right that our list is incomplete, TEST UNIT READY
> >> doesn't seem to be among the missing commands.
> >
> > Hm - older Linux guests (pre 2.6.38) and Windows guests, as Gleb's
> > commit mentioned, rely on this command to get CD change notifications:
> >
> > /* identical to scsi_test_unit_ready except that it doesn't
> > * eat the NOT_READY returns for removable media */
> > int sr_test_unit_ready(struct scsi_device *sdev, struct scsi_sense_hdr
> > *sshdr)
> > {
> > int retries = MAX_RETRIES;
> > int the_result;
> > u8 cmd[] = {TEST_UNIT_READY, 0, 0, 0, 0, 0 };
> >
> > /* issue TEST_UNIT_READY until the initial startup UNIT_ATTENTION
> > * conditions are gone, or a timeout happens
> > */
> > do {
> > the_result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL,
> > 0, sshdr, SR_TIMEOUT,
> > retries--, NULL);
> > if (scsi_sense_valid(sshdr) &&
> > sshdr->sense_key == UNIT_ATTENTION)
> > sdev->changed = 1;
> >
> > } while (retries > 0 &&
> > (!scsi_status_is_good(the_result) ||
> > (scsi_sense_valid(sshdr) &&
> >sshdr->sense_key == UNIT_ATTENTION)));
> > return the_result;
> > }
>
> I think the scsi_execute_req() call might issue a REQUEST SENSE
> internally and therefore clear the unit attention condition. Tried to
> check that in the source, but I'm hopelessly lost in the kernel...
No, it doesn't.
It's clear the 2nd patch is needed; the 1st one must be papering over
something else. Right now I'm inclined to think that it's because we
don't report tray open and no media as separate events to the guest,
as Markus has found out.
Amit
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On 07.04.2011 um 10:38, Alexander Graf wrote:
>
> Also, I just realized that you did miss another small part that needs change.
> A few lines above, there is code to interpret the modules right before that
> as well:
>
>if (initrd_filename) {
>const char *r = initrd_filename;
>mbs.mb_buf_size += strlen(r) + 1;
>mbs.mb_mods_avail = 1;
>while ((r = strchr(r, ','))) {
> mbs.mb_mods_avail++;
> r++;
>}
>mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
>}
>
> This code would need some change as well, as now the mb_buf_size field is
> incorrect. It doesn't really hurt, but is bad style to not use the exact
> amount of memory we need to.
You're right, I didn't look at this section. But now i had a deeper look into
the code, and I noticed the the mb_buf size seems to be incorrect anyway.
Look at this line:
mbs.mb_buf_size += strlen(r) + 1;
If I start qemu with the option -initrd "mod1 arg=bla, mod2 arg=foo, mod3
arg=bar", then r contains
"mod1 arg=bla, mod2 arg=foo, mod3 arg=bar", so the commas and spaces after the
comma are counted for the size of the multiboot command line.
Yes, this doesn't really hurt, but it's nevertheless not the exact amount of
memory. I'll try to fix it.
--
Ralf
Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI
On 07.04.2011, at 12:57, Natalia Portillo wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Roland, > > El 05/04/2011, a las 14:36, Roland Elek escribió: > >> Dear Qemu developers, >> >> First, I'd like to reintroduce myself, as my university and official duties >> prevented me from being active in the community since last year. I am Roland >> Elek, a student from Hungary, and a successful student participant of Google >> Summer of Code 2010. This year, I would like to participate again. I know >> I'm a bit late, but I'm still hoping to get things arranged before the >> deadline. >> >> Last year, I worked on AHCI emulation with Alex as my mentor. Do you think a >> proper summer project could be proposed from what is still missing? If so, >> can I kindly ask someone to give me some pointers to what the project needs >> the most, and where I should look first for things to include in my >> proposal? Also, if the idea is feasible, would there be someone who could be >> my mentor? > > You should ask Alex himself directly. I don't think there's enough left to be done to warrant a full GSoC project. Alex
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On 07.04.2011, at 14:07, Ralf Ramsauer wrote:
> On 07.04.2011 um 10:38, Alexander Graf wrote:
>>
>> Also, I just realized that you did miss another small part that needs
>> change. A few lines above, there is code to interpret the modules right
>> before that as well:
>>
>> if (initrd_filename) {
>> const char *r = initrd_filename;
>> mbs.mb_buf_size += strlen(r) + 1;
>> mbs.mb_mods_avail = 1;
>> while ((r = strchr(r, ','))) {
>> mbs.mb_mods_avail++;
>> r++;
>> }
>> mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
>> }
>>
>> This code would need some change as well, as now the mb_buf_size field is
>> incorrect. It doesn't really hurt, but is bad style to not use the exact
>> amount of memory we need to.
>
> You're right, I didn't look at this section. But now i had a deeper look into
> the code, and I noticed the the mb_buf size seems to be incorrect anyway.
>
> Look at this line:
>
> mbs.mb_buf_size += strlen(r) + 1;
>
> If I start qemu with the option -initrd "mod1 arg=bla, mod2 arg=foo, mod3
> arg=bar", then r contains
> "mod1 arg=bla, mod2 arg=foo, mod3 arg=bar", so the commas and spaces after
> the comma are counted for the size of the multiboot command line.
> Yes, this doesn't really hurt, but it's nevertheless not the exact amount of
> memory. I'll try to fix it.
Good point. Thanks!
Alex
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
Hello again, there's another problem with parsing the initrd string: If you want to start qemu with ... -initrd "mod1 arg=foo,bar , mod2 arg=bar,foo" it won't work The string is separated at every comma, arguments containing a comma are misinterpreted. So we'd think about another way delivering the arguments to load_multiboot. -initrd is used passing multiboot modules, but multiboot modules aren't really initrd's Multiboot modules are only loaded when qemu identifies the kernel as a Multiboot kernel. It would be much easier to pass the modules to qemu using a commandline argument like -multiboot. e.g. qemu -kernel mymultibootkern -module "1.mod arg=bla" -module "2.mod arg=foo" Well i didn't look at the global command line parsing of qemu, and i don't know how difficult it would be to realize this. Anyone ideas? -- Ralf
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
Out of curiousity, why are you trying to kill spaces at all? Why not just use a correct command-line to invoke QEMU? Stefan
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On 07.04.2011, at 14:48, Stefan Hajnoczi wrote: > Out of curiousity, why are you trying to kill spaces at all? > > Why not just use a correct command-line to invoke QEMU? > > Stefan Well it took me 2 days to find out why -initrd "module1, module2" didn't work. If there's a space after the comma you'll always get the error message "Failed to get image size". And if you want to pass a comma in a multiboot argument you've no way to do this. So -initrd"module1 settings=use_foo,use_bar" won't work! -- Ralf
Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI
On 04/06/2011 05:54 PM, Paul Brook wrote: Last year, I was also interested in working on S3 Trio emulation. This year, the same idea is on the ideas list. The hardware is pretty thoroughly documented through source code and textual documentation, and I'm already familiar with adding PCI devices to Qemu, so I do see a rough outline of how I would implement it. However, last year, Paul Brook commented [1] that he wasn't convinced about the usefulness of emulating an S3 Trio or Virge card, because of performance reasons. He suggested that accelerating the 2D engine would be tricky because the framebuffer is exposed to the guest. This might be just me not fully understanding his point, but isn't this also the case with the Cirrus Logic GD5446 card? He also suggested paravirtualization for 3D acceleration. Do you think it would make a good summer project? I can't comment on these issues, CC'ing Paul, Anthony and Stefan. My understanding is that Cirrus logic cards also have 2D acceleration. We implement this in qemu, but not in a way that's likely to be fast. I don't really know either card in detail, but they're both a similar age, so I'd expect the functionality to be fairly similar. The 2D engines you're talking about are of questionable benefit. IIUC They're basically a memcpy engine with some weird bitmasking operations that line up with the windows 3 GDI raster ops. While accelerating this maybe made sense on a 386, it's not worth the effort on modern CPUs. The latency and overhead of setting up and syncronising with the async blit engine is greater than the cost of just doing it in software. In practice modern desktop environments just use the 3D engine. 2d acceleration is more useful for more remote graphics protocols than local performance. We make use of Cirrus's bitblt and it's a huge performance optimization for VNC. The other big non-3d optimizations are YUV surfaces, hardware scaling, and RGBA hardware mouse rendering. With those things, you can get 90% of the way to having a nice desktop experience. And this is basically what VMware VGA has FWIW. To get the rest of the way, you really need something like QXL that has offscreen surfaces, text rendering, etc. Regards, Anthony Liguori IMO emulating useful 'real' 3D hardware is not feasible. In theory you could emulate an old card, however these are also of limited practical benefit. For the S3 cards the 3D engine is so crippled that even when new it wasn't worth using. You could maybe implement an old fixed-function card like, e.g. an i810 or 3dfx card, however drivers for these are also getting hard to come by, and the functionality is still limited. You basically get raster offloading, and everything else is done in software. Emulation overhead may be greater than useful offloaded work. For good 3D support you're looking at something shader based. Emulating real hardware is not going to happen. With real hardware the interface qemu needs to emulate is directly tied to the implementation details of that particular chipset. The guest driver generally uses intimate knowledge of these implementation details (e.g. vram layout, shader ISA). Different implementations may provide the same high-level functionality, however the low-level implementations are very different. Reconstructing high-level operations from the low-level stream is extremely hard, probably harder than the main CPU emulation that qemu does. IMO a good rule of thumb is that the output of the render pipeline should not be guest visible. Anything where the guest can observe/manipulate the output or intermediate results makes it very hard to isolate the guest from the implementation details (i.e. whatever hardware acceleration the host provides). There are already a handful of different paravirtual graphics drivers, of varying quality and openness. This includes: - Several OpenGL passthrough drivers. These are effectively just re- implementing GLX, often badly. I suspect that given a decent virtual network, remote X (including 3D via GLX) already works pretty well. - SPICE. IIUC this is an ugly hack that maps directly onto legacy Windows/GDI operations. I'm not aware of any substantive plan for making this work well in other environments (using the subset that's basically a dumb framebuffer doesn't count), or for doing 3D. - Whatever VMware uses. - Whatever VirtualBox uses. - At least two gallium3D based projects. I think this includes Xen, and possibly VirtualBox. Given the whole point of Gallium3D is to provide a common abstraction layer between the application API and the hardware this would be my choice. Paul
[Qemu-devel] [Bug 732155] Re: system_reset doesn't work with qemu-kvm and latest SeaBIOS
qemu 0.12 and newer reboot of FreeBSD (m0n0wall.vmdk http://m0n0.ch/wall/ ) fails. The Server (IBM xSeries 206), on which i found this "problem", has no kvm support... finally i decided not to use the IBM server [it is awfully slow when booting, although ubuntu server is really fast available ;-))...but sometimes fails to boot...so i don't use it for production]. I ran several tests and here is my expierence when trying to run m0n0wall.vmdk in qemu: everything works fine: system starts and can be configured... BUT, when I tell the system to reboot, it shuts down only until the message rebooting appears...nothing more happens... i can kill the Vmachine and restart it from commandline, but this is not very handy... it worked in qemu 0.9 and BOCHS Bios it always works with kvm: i need to start it as root (sudo kvm), otherwise it also won't reboot. I tested it with several versions on servers, with kvm-support: - Ubuntu 10.04 server 32 bit - Ubuntu 10.04 server 64 bit - Suse 11.4 32 bit -seabios 0.5: reboot worked with kvm, but didn't work with qemu (without kvm support) -seabios 0.6: reboot worked with kvm, but didn't work with qemu (without kvm support) Hope it helps somebody! stefan ** Attachment added: "qemu --no-kvm reboot problem monowall (FreeBSD 6)" https://bugs.launchpad.net/qemu/+bug/732155/+attachment/1993986/+files/qemo-nokvm-reboot-problem.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/732155 Title: system_reset doesn't work with qemu-kvm and latest SeaBIOS Status in QEMU: New Bug description: I've built qemu-kvm and seabios from the latest git sources, and found that the system_reset monitor command causes a freeze if I start qemu- system-x86_64 with the -no-kvm flag. This is a serial log from an attempt at rebooting: $ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -bios ../seabios/out/bios.bin -serial /dev/stdout -no-kvm QEMU 0.14.50 monitor - type 'help' for more information (qemu) Changing serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Ram Size=0x0800 (0x high) CPU Mhz=2202 PCI: pci_bios_init_bus_rec bus = 0x0 PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xf000 region 1: 0xf200 region 6: 0xf201 PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139 region 0: 0xc100 region 1: 0xf202 region 6: 0xf203 Found 1 cpu(s) max supported 1 cpu(s) MP table addr=0x000fdb40 MPC table addr=0x000fdb50 size=224 SMBIOS ptr=0x000fdb20 table=0x07fffef0 ACPI tables: RSDP=0x000fdaf0 RSDT=0x07ffd6a0 Scan for VGA option rom Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version pre-0.6.3-20110309_171929-desk4) PS2 keyboard initialized Found 1 lpt ports Found 1 serial ports ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 1 at 170/374/0 (irq 15 dev 9) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0 Scan for option roms Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm call arg1=2 pmm call arg1=0 Searching bootorder for: /pci@i0cf8/*@3 Searching bootorder for: /rom@genroms/vapic.bin Running option rom at c980:0003 ebda moved from 9fc00 to 9f400 Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 07ffd000 = 1 4: 07ffd000 - 0800 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from DVD/CD... Device reports MEDIUM NOT PRESENT atapi_is_ready returned -1 Boot failed: Could not read from CDROM (code 0003) enter handle_18: NULL Booting from ROM... Booting from c900:0336 (qemu) (qemu) system_reset (qemu) RESET REQUESTEDChanging serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Attempting a hard reboot prep_reset apm_shutdown? i8042_reboot i8042: wait to write... i8042: outb RESET REQUESTED (qemu) (qemu) (qemu) (qemu) info cpus * CPU #0: pc=0xfff0 thread_id=18125 (qemu) system_reset (qemu) RESET REQUESTED (qemu) (qemu) q I've tried fiddling a few build options in SeaBIOS but I'm not sure that's where the issue lies. The RESET REQUESTED is me adding some extra debug to vl.c:1477 in the clause that tests for a reset request, and the i8042: l
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On 04/07/2011 03:22 AM, Bei Guan wrote: Hi, I have some questions about the qemu's bios. How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Which function or code file need I to pay more attention to? For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into the same funciton rom_add_file() in hw/loader.c. Is it the right function, which loads the bioses? And then another question, how qemu give the control to bios when the bios file is loaded? Maybe this question is not in the scope of qemu, however, can you give me some cue point. I had some stuff written up locally so I posted it to the wiki at http://wiki.qemu.org/Documentation/Platforms/PC The x86 architecture defines the initial state of the chip to have the CS register have a base of 0xF000 and an IP of 0xFFF0. The result is that the actual memory address of the first instruction falls at the end of the BIOS ROM segment. This is the entry point to the BIOS. The VGABIOS is treated like any other option ROM and is initialized during option ROM scanning. Regards, Anthony Liguori Any reply are appreciated. Thanks. Gavin
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On Thu, Apr 7, 2011 at 1:56 PM, Ralf Ramsauer wrote: > On 07.04.2011, at 14:48, Stefan Hajnoczi wrote: > >> Out of curiousity, why are you trying to kill spaces at all? >> >> Why not just use a correct command-line to invoke QEMU? >> >> Stefan > > Well it took me 2 days to find out why -initrd "module1, module2" didn't > work. If there's a space after the comma you'll always > get the error message "Failed to get image size". How about improving the error message? > And if you want to pass a comma in a multiboot argument you've no way to do > this. > So -initrd"module1 settings=use_foo,use_bar" won't work! >From what I can tell your patch does not change this. Stefan
Re: [Qemu-devel] [PATCH] virtio-blk: fail unaligned requests
Am 06.04.2011 20:28, schrieb Christoph Hellwig: > Like all block drivers virtio-blk should not allow small than block size > granularity access. But given that the protocol specifies a > byte unit length field we currently accept such requests, which cause > qemu to abort() in lower layers. Add checks to the main read and > write handlers to catch them early. > > Reported-by: Conor Murphy > Tested-by: Conor Murphy > Signed-off-by: Christoph Hellwig Thanks, applied to the block branch. Kevin
[Qemu-devel] [GIT PULL] Trivial patches for 6-7 April 2011
The following changes since commit 3b8e6a2db1946b5f21e69fde31b39f43367f1928: exec: Handle registrations of the entire address space (2011-04-07 10:53:41 +0200) are available in the git repository at: git://repo.or.cz/qemu/stefanha.git trivial-patches Alexey Kardashevskiy (3): spapr_llan: Fix warning when compiled with -dDEBUG virtio-9p: fixed LE-to-host conversion bug when QEMU is called from guest virtio-balloon: fixed endianness bug in the config space Brad Hards (1): usb-ccid: Spelling fixes Michael Tokarev (1): qdev: Fix comment around qdev_init_nofail() hw/qdev.c |3 ++- hw/spapr_llan.c |3 --- hw/usb-ccid.c |8 hw/virtio-9p.c |9 +++-- hw/virtio-balloon.c |2 +- 5 files changed, 10 insertions(+), 15 deletions(-)
[Qemu-devel] [PULL 00/15] Block patches
The following changes since commit 3b8e6a2db1946b5f21e69fde31b39f43367f1928: exec: Handle registrations of the entire address space (2011-04-07 10:53:41 +0200) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Avishay Traeger (1): Fix integer overflow in block migration bandwidth calculation Christoph Hellwig (1): virtio-blk: fail unaligned requests Feiran Zheng (1): hw/xen_disk: ioreq not finished on error Isaku Yamahata (1): ide: consolidate drive_get(IF_IDE) Jason Wang (1): floppy: save and restore DIR register Jes Sorensen (1): qemu-img: Initial progress printing support Kevin Wolf (1): qemu-img rebase: Fix segfault if backing file can't be opened Michael Tokarev (1): exit if -drive specified is invalid instead of ignoring the "wrong" -drive Nick Thomas (4): NBD library: whitespace changes Set errno=ENOTSUP for attempts to use UNIX sockets on Windows platforms NBD: Use qemu_socket functions to open TCP and UNIX sockets NBD device: Separate out parsing configuration and opening sockets. Ryan Harper (1): Do not delete BlockDriverState when deleting the drive Stefan Hajnoczi (2): trace: Trace bdrv_set_locked() block: Do not cache device size for removable media Makefile.objs |4 +- block-migration.c |2 +- block.c| 28 +- block.h|1 + block/nbd.c| 157 ++--- blockdev.c | 25 +- hw/fdc.c | 51 +++- hw/ide.h |3 + hw/ide/core.c | 14 + hw/mips_fulong2e.c |9 +- hw/mips_malta.c| 10 +- hw/mips_r4k.c | 10 +- hw/pc_piix.c | 10 +- hw/ppc_newworld.c | 11 +- hw/ppc_oldworld.c | 11 +- hw/ppc_prep.c | 10 +- hw/sun4u.c |9 +- hw/virtio-blk.c|8 + hw/xen_disk.c | 10 +- nbd.c | 993 +++- nbd.h |9 +- qemu-common.h |4 + qemu-img-cmds.hx |4 +- qemu-img.c | 46 +++- qemu-progress.c| 89 + qemu-sockets.c |4 + trace-events |1 + vl.c |4 +- 28 files changed, 825 insertions(+), 712 deletions(-) create mode 100644 qemu-progress.c
[Qemu-devel] [PATCH 02/15] Do not delete BlockDriverState when deleting the drive
From: Ryan Harper
When removing a drive from the host-side via drive_del we currently have
the following path:
drive_del
qemu_aio_flush()
bdrv_close()// zaps bs->drv, which makes any subsequent I/O get
// dropped. Works as designed
drive_uninit()
bdrv_delete() // frees the bs. Since the device is still connected to
// bs, any subsequent I/O is a use-after-free.
The value of bs->drv becomes unpredictable on free. As long as it
remains null, I/O still gets dropped, however it could become non-null
at any point after the free resulting SEGVs or other QEMU state
corruption.
To resolve this issue as simply as possible, we can chose to not
actually delete the BlockDriverState pointer. Since bdrv_close()
handles setting the drv pointer to NULL, we just need to remove the
BlockDriverState from the QLIST that is used to enumerate the block
devices. This is currently handled within bdrv_delete, so move this
into its own function, bdrv_make_anon().
The result is that we can now invoke drive_del, this closes the file
descriptors and sets BlockDriverState->drv to NULL which prevents futher
IO to the device, and since we do not free BlockDriverState, we don't
have to worry about the copy retained in the block devices.
We also don't attempt to remove the qdev property since we are no longer
deleting the BlockDriverState on drives with associated drives. This
also allows for removing Drives with no devices associated either.
Reported-by: Markus Armbruster
Signed-off-by: Ryan Harper
Acked-by: Markus Armbruster
Signed-off-by: Kevin Wolf
---
block.c| 14 +++---
block.h|1 +
blockdev.c | 25 -
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/block.c b/block.c
index c8e2f97..c93ec6d 100644
--- a/block.c
+++ b/block.c
@@ -697,14 +697,22 @@ void bdrv_close_all(void)
}
}
+/* make a BlockDriverState anonymous by removing from bdrv_state list.
+ Also, NULL terminate the device_name to prevent double remove */
+void bdrv_make_anon(BlockDriverState *bs)
+{
+if (bs->device_name[0] != '\0') {
+QTAILQ_REMOVE(&bdrv_states, bs, list);
+}
+bs->device_name[0] = '\0';
+}
+
void bdrv_delete(BlockDriverState *bs)
{
assert(!bs->peer);
/* remove from list, if necessary */
-if (bs->device_name[0] != '\0') {
-QTAILQ_REMOVE(&bdrv_states, bs, list);
-}
+bdrv_make_anon(bs);
bdrv_close(bs);
if (bs->file != NULL) {
diff --git a/block.h b/block.h
index 5d78fc0..52e9cad 100644
--- a/block.h
+++ b/block.h
@@ -66,6 +66,7 @@ int bdrv_create(BlockDriver *drv, const char* filename,
QEMUOptionParameter *options);
int bdrv_create_file(const char* filename, QEMUOptionParameter *options);
BlockDriverState *bdrv_new(const char *device_name);
+void bdrv_make_anon(BlockDriverState *bs);
void bdrv_delete(BlockDriverState *bs);
int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags);
int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
diff --git a/blockdev.c b/blockdev.c
index bbe92fe..5429621 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -737,8 +737,6 @@ int do_drive_del(Monitor *mon, const QDict *qdict, QObject
**ret_data)
{
const char *id = qdict_get_str(qdict, "id");
BlockDriverState *bs;
-BlockDriverState **ptr;
-Property *prop;
bs = bdrv_find(id);
if (!bs) {
@@ -755,24 +753,17 @@ int do_drive_del(Monitor *mon, const QDict *qdict,
QObject **ret_data)
bdrv_flush(bs);
bdrv_close(bs);
-/* clean up guest state from pointing to host resource by
- * finding and removing DeviceState "drive" property */
+/* if we have a device associated with this BlockDriverState (bs->peer)
+ * then we need to make the drive anonymous until the device
+ * can be removed. If this is a drive with no device backing
+ * then we can just get rid of the block driver state right here.
+ */
if (bs->peer) {
-for (prop = bs->peer->info->props; prop && prop->name; prop++) {
-if (prop->info->type == PROP_TYPE_DRIVE) {
-ptr = qdev_get_prop_ptr(bs->peer, prop);
-if (*ptr == bs) {
-bdrv_detach(bs, bs->peer);
-*ptr = NULL;
-break;
-}
-}
-}
+bdrv_make_anon(bs);
+} else {
+drive_uninit(drive_get_by_blockdev(bs));
}
-/* clean up host side */
-drive_uninit(drive_get_by_blockdev(bs));
-
return 0;
}
--
1.7.2.3
[Qemu-devel] [PATCH 06/15] qemu-img rebase: Fix segfault if backing file can't be opened
bdrv_delete must not be called for a NULL BlockDriverState.
Signed-off-by: Kevin Wolf
Reviewed-by: Stefan Hajnoczi
---
qemu-img.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 074388c..d9c2c12 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1411,8 +1411,12 @@ out:
qemu_progress_end();
/* Cleanup */
if (!unsafe) {
-bdrv_delete(bs_old_backing);
-bdrv_delete(bs_new_backing);
+if (bs_old_backing != NULL) {
+bdrv_delete(bs_old_backing);
+}
+if (bs_new_backing != NULL) {
+bdrv_delete(bs_new_backing);
+}
}
bdrv_delete(bs);
--
1.7.2.3
[Qemu-devel] [PATCH 10/15] Set errno=ENOTSUP for attempts to use UNIX sockets on Windows platforms
From: Nick Thomas
Signed-off-by: Nick Thomas
Signed-off-by: Kevin Wolf
---
qemu-sockets.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/qemu-sockets.c b/qemu-sockets.c
index c526324..eda1850 100644
--- a/qemu-sockets.c
+++ b/qemu-sockets.c
@@ -627,24 +627,28 @@ int unix_connect(const char *path)
int unix_listen_opts(QemuOpts *opts)
{
fprintf(stderr, "unix sockets are not available on windows\n");
+errno = ENOTSUP;
return -1;
}
int unix_connect_opts(QemuOpts *opts)
{
fprintf(stderr, "unix sockets are not available on windows\n");
+errno = ENOTSUP;
return -1;
}
int unix_listen(const char *path, char *ostr, int olen)
{
fprintf(stderr, "unix sockets are not available on windows\n");
+errno = ENOTSUP;
return -1;
}
int unix_connect(const char *path)
{
fprintf(stderr, "unix sockets are not available on windows\n");
+errno = ENOTSUP;
return -1;
}
--
1.7.2.3
[Qemu-devel] [PATCH 03/15] trace: Trace bdrv_set_locked()
From: Stefan Hajnoczi
It can be handy to know when the guest locks/unlocks the CD-ROM tray.
This trace event makes that possible.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block.c |2 ++
trace-events |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index c93ec6d..d8da3b0 100644
--- a/block.c
+++ b/block.c
@@ -2817,6 +2817,8 @@ void bdrv_set_locked(BlockDriverState *bs, int locked)
{
BlockDriver *drv = bs->drv;
+trace_bdrv_set_locked(bs, locked);
+
bs->locked = locked;
if (drv && drv->bdrv_set_locked) {
drv->bdrv_set_locked(bs, locked);
diff --git a/trace-events b/trace-events
index 06efdb7..703b745 100644
--- a/trace-events
+++ b/trace-events
@@ -54,6 +54,7 @@ disable bdrv_aio_multiwrite_latefail(void *mcb, int i) "mcb
%p i %d"
disable bdrv_aio_flush(void *bs, void *opaque) "bs %p opaque %p"
disable bdrv_aio_readv(void *bs, int64_t sector_num, int nb_sectors, void
*opaque) "bs %p sector_num %"PRId64" nb_sectors %d opaque %p"
disable bdrv_aio_writev(void *bs, int64_t sector_num, int nb_sectors, void
*opaque) "bs %p sector_num %"PRId64" nb_sectors %d opaque %p"
+disable bdrv_set_locked(void *bs, int locked) "bs %p locked %d"
# hw/virtio-blk.c
disable virtio_blk_req_complete(void *req, int status) "req %p status %d"
--
1.7.2.3
[Qemu-devel] [PATCH 05/15] qemu-img: Initial progress printing support
From: Jes Sorensen
This adds the basic infrastructure for supporting progress output
on the command line, as well as progress support for qemu-img commands
'rebase' and 'convert'.
Signed-off-by: Jes Sorensen
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
Makefile.objs|2 +-
qemu-common.h|4 ++
qemu-img-cmds.hx |4 +-
qemu-img.c | 38 ++-
qemu-progress.c | 89 ++
5 files changed, 132 insertions(+), 5 deletions(-)
create mode 100644 qemu-progress.c
diff --git a/Makefile.objs b/Makefile.objs
index c05f5e5..94587e1 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -14,7 +14,7 @@ oslib-obj-$(CONFIG_POSIX) += oslib-posix.o
# block-obj-y is code used by both qemu system emulation and qemu-img
block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o
async.o
-block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o
+block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o qemu-progress.o
block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
diff --git a/qemu-common.h b/qemu-common.h
index 8ecb488..82e27c1 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -334,6 +334,10 @@ void qemu_iovec_memset(QEMUIOVector *qiov, int c, size_t
count);
void qemu_iovec_memset_skip(QEMUIOVector *qiov, int c, size_t count,
size_t skip);
+void qemu_progress_init(int enabled, float min_skip);
+void qemu_progress_end(void);
+void qemu_progress_print(float percent, int max);
+
/* Convert a byte between binary and BCD. */
static inline uint8_t to_bcd(uint8_t val)
{
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 6c7176f..3072d38 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -28,7 +28,7 @@ STEXI
ETEXI
DEF("convert", img_convert,
-"convert [-c] [-f fmt] [-O output_fmt] [-o options] [-s snapshot_name]
filename [filename2 [...]] output_filename")
+"convert [-c] [-p] [-f fmt] [-O output_fmt] [-o options] [-s
snapshot_name] filename [filename2 [...]] output_filename")
STEXI
@item convert [-c] [-f @var{fmt}] [-O @var{output_fmt}] [-o @var{options}] [-s
@var{snapshot_name}] @var{filename} [@var{filename2} [...]]
@var{output_filename}
ETEXI
@@ -46,7 +46,7 @@ STEXI
ETEXI
DEF("rebase", img_rebase,
-"rebase [-f fmt] [-u] -b backing_file [-F backing_fmt] filename")
+"rebase [-f fmt] [-p] [-u] -b backing_file [-F backing_fmt] filename")
STEXI
@item rebase [-f @var{fmt}] [-u] -b @var{backing_file} [-F @var{backing_fmt}]
@var{filename}
ETEXI
diff --git a/qemu-img.c b/qemu-img.c
index 7e3cc4c..074388c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -77,6 +77,7 @@ static void help(void)
" match exactly. The image doesn't need a working backing
file before\n"
" rebasing in this case (useful for renaming the backing
file)\n"
" '-h' with or without a command shows this help and lists the
supported formats\n"
+ " '-p' show progress of command (only certain commands)\n"
"\n"
"Parameters to snapshot subcommand:\n"
" 'snapshot' is the name of the snapshot to create, apply or
delete\n"
@@ -567,6 +568,7 @@ static int compare_sectors(const uint8_t *buf1, const
uint8_t *buf2, int n,
static int img_convert(int argc, char **argv)
{
int c, ret = 0, n, n1, bs_n, bs_i, compress, cluster_size, cluster_sectors;
+int progress = 0;
const char *fmt, *out_fmt, *out_baseimg, *out_filename;
BlockDriver *drv, *proto_drv;
BlockDriverState **bs = NULL, *out_bs = NULL;
@@ -579,13 +581,14 @@ static int img_convert(int argc, char **argv)
QEMUOptionParameter *out_baseimg_param;
char *options = NULL;
const char *snapshot_name = NULL;
+float local_progress;
fmt = NULL;
out_fmt = "raw";
out_baseimg = NULL;
compress = 0;
for(;;) {
-c = getopt(argc, argv, "f:O:B:s:hce6o:");
+c = getopt(argc, argv, "f:O:B:s:hce6o:p");
if (c == -1) {
break;
}
@@ -620,6 +623,9 @@ static int img_convert(int argc, char **argv)
case 's':
snapshot_name = optarg;
break;
+case 'p':
+progress = 1;
+break;
}
}
@@ -642,6 +648,9 @@ static int img_convert(int argc, char **argv)
goto out;
}
+qemu_progress_init(progress, 2.0);
+qemu_progress_print(0, 100);
+
bs = qemu_mallocz(bs_n * sizeof(BlockDriverState *));
total_sectors = 0;
@@ -773,6 +782,11 @@ static int img_convert(int argc, char **argv)
}
cluster_sectors = cluster_size >> 9;
sector_num = 0;
+
+nb_sectors = total_sectors;
+local_progress = (float)100 /
+(nb_sectors / MIN(nb_sectors, (cluster_sectors)));
+
for(;;) {
int64_t bs_num;
int remainder;
@@ -832,6 +846,7 @@ static
[Qemu-devel] [PATCH 12/15] NBD device: Separate out parsing configuration and opening sockets.
From: Nick Thomas
We also change the way the file parameter is parsed so IPv6 IP
addresses can be used, e.g.: "drive=nbd:[::1]:5000"
Signed-off-by: Nick Thomas
Signed-off-by: Kevin Wolf
---
block/nbd.c | 157 ++-
1 files changed, 102 insertions(+), 55 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index c8dc763..1d6b225 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -29,96 +29,152 @@
#include "qemu-common.h"
#include "nbd.h"
#include "module.h"
+#include "qemu_socket.h"
#include
#include
#define EN_OPTSTR ":exportname="
+/* #define DEBUG_NBD */
+
+#if defined(DEBUG_NBD)
+#define logout(fmt, ...) \
+fprintf(stderr, "nbd\t%-24s" fmt, __func__, ##__VA_ARGS__)
+#else
+#define logout(fmt, ...) ((void)0)
+#endif
+
typedef struct BDRVNBDState {
int sock;
off_t size;
size_t blocksize;
+char *export_name; /* An NBD server may export several devices */
+
+/* If it begins with '/', this is a UNIX domain socket. Otherwise,
+ * it's a string of the form :port
+ */
+char *host_spec;
} BDRVNBDState;
-static int nbd_open(BlockDriverState *bs, const char* filename, int flags)
+static int nbd_config(BDRVNBDState *s, const char *filename, int flags)
{
-BDRVNBDState *s = bs->opaque;
-uint32_t nbdflags;
-
char *file;
-char *name;
-const char *host;
+char *export_name;
+const char *host_spec;
const char *unixpath;
-int sock;
-off_t size;
-size_t blocksize;
-int ret;
int err = -EINVAL;
file = qemu_strdup(filename);
-name = strstr(file, EN_OPTSTR);
-if (name) {
-if (name[strlen(EN_OPTSTR)] == 0) {
+export_name = strstr(file, EN_OPTSTR);
+if (export_name) {
+if (export_name[strlen(EN_OPTSTR)] == 0) {
goto out;
}
-name[0] = 0;
-name += strlen(EN_OPTSTR);
+export_name[0] = 0; /* truncate 'file' */
+export_name += strlen(EN_OPTSTR);
+s->export_name = qemu_strdup(export_name);
}
-if (!strstart(file, "nbd:", &host)) {
+/* extract the host_spec - fail if it's not nbd:... */
+if (!strstart(file, "nbd:", &host_spec)) {
goto out;
}
-if (strstart(host, "unix:", &unixpath)) {
-
-if (unixpath[0] != '/') {
+/* are we a UNIX or TCP socket? */
+if (strstart(host_spec, "unix:", &unixpath)) {
+if (unixpath[0] != '/') { /* We demand an absolute path*/
goto out;
}
-
-sock = unix_socket_outgoing(unixpath);
-
+s->host_spec = qemu_strdup(unixpath);
} else {
-uint16_t port = NBD_DEFAULT_PORT;
-char *p, *r;
-char hostname[128];
+s->host_spec = qemu_strdup(host_spec);
+}
-pstrcpy(hostname, 128, host);
+err = 0;
-p = strchr(hostname, ':');
-if (p != NULL) {
-*p = '\0';
-p++;
+out:
+qemu_free(file);
+if (err != 0) {
+qemu_free(s->export_name);
+qemu_free(s->host_spec);
+}
+return err;
+}
-port = strtol(p, &r, 0);
-if (r == p) {
-goto out;
-}
-}
+static int nbd_establish_connection(BlockDriverState *bs)
+{
+BDRVNBDState *s = bs->opaque;
+int sock;
+int ret;
+off_t size;
+size_t blocksize;
+uint32_t nbdflags;
-sock = tcp_socket_outgoing(hostname, port);
+if (s->host_spec[0] == '/') {
+sock = unix_socket_outgoing(s->host_spec);
+} else {
+sock = tcp_socket_outgoing_spec(s->host_spec);
}
+/* Failed to establish connection */
if (sock == -1) {
-err = -errno;
-goto out;
+logout("Failed to establish connection to NBD server\n");
+return -errno;
}
-ret = nbd_receive_negotiate(sock, name, &nbdflags, &size, &blocksize);
+/* NBD handshake */
+ret = nbd_receive_negotiate(sock, s->export_name, &nbdflags, &size,
+&blocksize);
if (ret == -1) {
-err = -errno;
-goto out;
+logout("Failed to negotiate with the NBD server\n");
+closesocket(sock);
+return -errno;
}
+/* Now that we're connected, set the socket to be non-blocking */
+socket_set_nonblock(sock);
+
s->sock = sock;
s->size = size;
s->blocksize = blocksize;
-err = 0;
-out:
-qemu_free(file);
-return err;
+logout("Established connection with NBD server\n");
+return 0;
+}
+
+static void nbd_teardown_connection(BlockDriverState *bs)
+{
+BDRVNBDState *s = bs->opaque;
+struct nbd_request request;
+
+request.type = NBD_CMD_DISC;
+request.handle = (uint64_t)(intptr_t)bs;
+request.from = 0;
+request.len = 0;
+nbd_send_request(s->sock, &request);
+
+closesocket(s->sock);
+}
+
+static int nbd_open(BlockDriverState *bs, const char* filename, int flags)
+{
+BDRVNBDSta
[Qemu-devel] [PATCH 01/15] hw/xen_disk: ioreq not finished on error
From: Feiran Zheng Bug fix: routines 'ioreq_runio_qemu_sync' and 'ioreq_runio_qemu_aio' won't call 'ioreq_unmap' or 'ioreq_finish' on errors, leaving ioreq in the blkdev->inflight list and a leak. Signed-off-by: Feiran Zheng Acked-by: Stefano Stabellini Signed-off-by: Kevin Wolf --- hw/xen_disk.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 445bf03..558bf8a 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -310,7 +310,7 @@ static int ioreq_runio_qemu_sync(struct ioreq *ioreq) off_t pos; if (ioreq->req.nr_segments && ioreq_map(ioreq) == -1) - goto err; + goto err_no_map; if (ioreq->presync) bdrv_flush(blkdev->bs); @@ -364,6 +364,9 @@ static int ioreq_runio_qemu_sync(struct ioreq *ioreq) return 0; err: +ioreq_unmap(ioreq); +err_no_map: +ioreq_finish(ioreq); ioreq->status = BLKIF_RSP_ERROR; return -1; } @@ -393,7 +396,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) struct XenBlkDev *blkdev = ioreq->blkdev; if (ioreq->req.nr_segments && ioreq_map(ioreq) == -1) - goto err; + goto err_no_map; ioreq->aio_inflight++; if (ioreq->presync) @@ -427,6 +430,9 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) return 0; err: +ioreq_unmap(ioreq); +err_no_map: +ioreq_finish(ioreq); ioreq->status = BLKIF_RSP_ERROR; return -1; } -- 1.7.2.3
[Qemu-devel] [PATCH 09/15] NBD library: whitespace changes
From: Nick Thomas
Signed-off-by: Nick Thomas
Signed-off-by: Kevin Wolf
---
nbd.c | 835 +
1 files changed, 418 insertions(+), 417 deletions(-)
diff --git a/nbd.c b/nbd.c
index d8ebc42..abe0ecb 100644
--- a/nbd.c
+++ b/nbd.c
@@ -49,7 +49,7 @@
/* This is all part of the "official" NBD API */
-#define NBD_REPLY_SIZE (4 + 4 + 8)
+#define NBD_REPLY_SIZE (4 + 4 + 8)
#define NBD_REQUEST_MAGIC 0x25609513
#define NBD_REPLY_MAGIC 0x67446698
@@ -59,11 +59,11 @@
#define NBD_DO_IT _IO(0xab, 3)
#define NBD_CLEAR_SOCK _IO(0xab, 4)
#define NBD_CLEAR_QUE _IO(0xab, 5)
-#define NBD_PRINT_DEBUG_IO(0xab, 6)
-#define NBD_SET_SIZE_BLOCKS_IO(0xab, 7)
+#define NBD_PRINT_DEBUG _IO(0xab, 6)
+#define NBD_SET_SIZE_BLOCKS _IO(0xab, 7)
#define NBD_DISCONNECT _IO(0xab, 8)
-#define NBD_OPT_EXPORT_NAME(1 << 0)
+#define NBD_OPT_EXPORT_NAME (1 << 0)
/* That's all folks */
@@ -273,241 +273,241 @@ int unix_socket_outgoing(const char *path)
int nbd_negotiate(int csock, off_t size)
{
- char buf[8 + 8 + 8 + 128];
-
- /* Negotiate
- [ 0 .. 7] passwd ("NBDMAGIC")
- [ 8 .. 15] magic(0x00420281861253)
- [16 .. 23] size
- [24 .. 151] reserved (0)
-*/
-
- TRACE("Beginning negotiation.");
- memcpy(buf, "NBDMAGIC", 8);
- cpu_to_be64w((uint64_t*)(buf + 8), 0x00420281861253LL);
- cpu_to_be64w((uint64_t*)(buf + 16), size);
- memset(buf + 24, 0, 128);
-
- if (write_sync(csock, buf, sizeof(buf)) != sizeof(buf)) {
- LOG("write failed");
- errno = EINVAL;
- return -1;
- }
-
- TRACE("Negotation succeeded.");
-
- return 0;
+char buf[8 + 8 + 8 + 128];
+
+/* Negotiate
+[ 0 .. 7] passwd ("NBDMAGIC")
+[ 8 .. 15] magic(0x00420281861253)
+[16 .. 23] size
+[24 .. 151] reserved (0)
+ */
+
+TRACE("Beginning negotiation.");
+memcpy(buf, "NBDMAGIC", 8);
+cpu_to_be64w((uint64_t*)(buf + 8), 0x00420281861253LL);
+cpu_to_be64w((uint64_t*)(buf + 16), size);
+memset(buf + 24, 0, 128);
+
+if (write_sync(csock, buf, sizeof(buf)) != sizeof(buf)) {
+LOG("write failed");
+errno = EINVAL;
+return -1;
+}
+
+TRACE("Negotation succeeded.");
+
+return 0;
}
int nbd_receive_negotiate(int csock, const char *name, uint32_t *flags,
off_t *size, size_t *blocksize)
{
- char buf[256];
- uint64_t magic, s;
- uint16_t tmp;
-
- TRACE("Receiving negotation.");
-
- if (read_sync(csock, buf, 8) != 8) {
- LOG("read failed");
- errno = EINVAL;
- return -1;
- }
-
- buf[8] = '\0';
- if (strlen(buf) == 0) {
- LOG("server connection closed");
- errno = EINVAL;
- return -1;
- }
-
- TRACE("Magic is %c%c%c%c%c%c%c%c",
- qemu_isprint(buf[0]) ? buf[0] : '.',
- qemu_isprint(buf[1]) ? buf[1] : '.',
- qemu_isprint(buf[2]) ? buf[2] : '.',
- qemu_isprint(buf[3]) ? buf[3] : '.',
- qemu_isprint(buf[4]) ? buf[4] : '.',
- qemu_isprint(buf[5]) ? buf[5] : '.',
- qemu_isprint(buf[6]) ? buf[6] : '.',
- qemu_isprint(buf[7]) ? buf[7] : '.');
-
- if (memcmp(buf, "NBDMAGIC", 8) != 0) {
- LOG("Invalid magic received");
- errno = EINVAL;
- return -1;
- }
-
- if (read_sync(csock, &magic, sizeof(magic)) != sizeof(magic)) {
- LOG("read failed");
- errno = EINVAL;
- return -1;
- }
- magic = be64_to_cpu(magic);
- TRACE("Magic is 0x%" PRIx64, magic);
-
- if (name) {
- uint32_t reserved = 0;
- uint32_t opt;
- uint32_t namesize;
-
- TRACE("Checking magic (opts_magic)");
- if (magic != 0x49484156454F5054LL) {
- LOG("Bad magic received");
- errno = EINVAL;
- return -1;
- }
- if (read_sync(csock, &tmp, sizeof(tmp)) != sizeof(tmp)) {
- LOG("flags read failed");
- errno = EINVAL;
- return -1;
- }
- *flags = be16_to_cpu(tmp) << 16;
- /* reserved for future use */
- if (write_sync(csock, &reserved, sizeof(reserved)) !=
- sizeof(reserved)) {
- LOG("write failed (reserved)");
- errno = EINVAL;
- return -1;
- }
- /* write the export name */
- magic = cpu_to_be64(mag
[Qemu-devel] [PATCH 15/15] virtio-blk: fail unaligned requests
From: Christoph Hellwig
Like all block drivers virtio-blk should not allow small than block size
granularity access. But given that the protocol specifies a
byte unit length field we currently accept such requests, which cause
qemu to abort() in lower layers. Add checks to the main read and
write handlers to catch them early.
Reported-by: Conor Murphy
Tested-by: Conor Murphy
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
hw/virtio-blk.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index b14fb99..91e0394 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -290,6 +290,10 @@ static void virtio_blk_handle_write(VirtIOBlockReq *req,
MultiReqBuffer *mrb)
virtio_blk_rw_complete(req, -EIO);
return;
}
+if (req->qiov.size % req->dev->conf->logical_block_size) {
+virtio_blk_rw_complete(req, -EIO);
+return;
+}
if (mrb->num_writes == 32) {
virtio_submit_multiwrite(req->dev->bs, mrb);
@@ -317,6 +321,10 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
virtio_blk_rw_complete(req, -EIO);
return;
}
+if (req->qiov.size % req->dev->conf->logical_block_size) {
+virtio_blk_rw_complete(req, -EIO);
+return;
+}
acb = bdrv_aio_readv(req->dev->bs, sector, &req->qiov,
req->qiov.size / BDRV_SECTOR_SIZE,
--
1.7.2.3
[Qemu-devel] [PATCH 04/15] block: Do not cache device size for removable media
From: Stefan Hajnoczi
The block layer caches the device size to avoid doing lseek(fd, 0,
SEEK_END) every time this value is needed. For removable media the
device size becomes stale if a new medium is inserted. This patch
simply prevents device size caching for removable media.
A smarter solution is to update the cached device size when a new medium
is inserted. Given that there are currently bugs with CD-ROM media
change I do not want to implement that approach until we've gotten
things correct first.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/block.c b/block.c
index d8da3b0..f731c7a 100644
--- a/block.c
+++ b/block.c
@@ -1161,14 +1161,12 @@ int64_t bdrv_getlength(BlockDriverState *bs)
if (!drv)
return -ENOMEDIUM;
-/* Fixed size devices use the total_sectors value for speed instead of
- issuing a length query (like lseek) on each call. Also, legacy block
- drivers don't provide a bdrv_getlength function and must use
- total_sectors. */
-if (!bs->growable || !drv->bdrv_getlength) {
-return bs->total_sectors * BDRV_SECTOR_SIZE;
-}
-return drv->bdrv_getlength(bs);
+if (bs->growable || bs->removable) {
+if (drv->bdrv_getlength) {
+return drv->bdrv_getlength(bs);
+}
+}
+return bs->total_sectors * BDRV_SECTOR_SIZE;
}
/* return 0 as number of sectors if no device present or error */
--
1.7.2.3
[Qemu-devel] [PATCH 08/15] ide: consolidate drive_get(IF_IDE)
From: Isaku Yamahata
factor out ide initialization to call drive_get(IF_IDE)
Signed-off-by: Isaku Yamahata
Signed-off-by: Kevin Wolf
---
hw/ide.h |3 +++
hw/ide/core.c | 14 ++
hw/mips_fulong2e.c |9 +
hw/mips_malta.c| 10 +-
hw/mips_r4k.c | 10 +-
hw/pc_piix.c | 10 +-
hw/ppc_newworld.c | 11 ++-
hw/ppc_oldworld.c | 11 +++
hw/ppc_prep.c | 10 +-
hw/sun4u.c |9 +
10 files changed, 28 insertions(+), 69 deletions(-)
diff --git a/hw/ide.h b/hw/ide.h
index 73fb550..34d9394 100644
--- a/hw/ide.h
+++ b/hw/ide.h
@@ -28,4 +28,7 @@ void mmio_ide_init (target_phys_addr_t membase,
target_phys_addr_t membase2,
void ide_get_bs(BlockDriverState *bs[], BusState *qbus);
+/* ide/core.c */
+void ide_drive_get(DriveInfo **hd, int max_bus);
+
#endif /* HW_IDE_H */
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 007a4ee..c11d457 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2826,3 +2826,17 @@ const VMStateDescription vmstate_ide_bus = {
VMSTATE_END_OF_LIST()
}
};
+
+void ide_drive_get(DriveInfo **hd, int max_bus)
+{
+int i;
+
+if (drive_get_max_bus(IF_IDE) >= max_bus) {
+fprintf(stderr, "qemu: too many IDE bus: %d\n", max_bus);
+exit(1);
+}
+
+for(i = 0; i < max_bus * MAX_IDE_DEVS; i++) {
+hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
+}
+}
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
index f5ae639..0e90d68 100644
--- a/hw/mips_fulong2e.c
+++ b/hw/mips_fulong2e.c
@@ -338,14 +338,7 @@ static void mips_fulong2e_init(ram_addr_t ram_size, const
char *boot_device,
pci_bus = bonito_init((qemu_irq *)&(env->irq[2]));
/* South bridge */
-if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
-fprintf(stderr, "qemu: too many IDE bus\n");
-exit(1);
-}
-
-for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
-hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
-}
+ide_drive_get(hd, MAX_IDE_BUS);
via_devfn = vt82c686b_init(pci_bus, PCI_DEVFN(FULONG2E_VIA_SLOT, 0));
if (via_devfn < 0) {
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d8baa6d..bf0d76d 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -905,15 +905,7 @@ void mips_malta_init (ram_addr_t ram_size,
pci_bus = gt64120_register(i8259);
/* Southbridge */
-
-if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
-fprintf(stderr, "qemu: too many IDE bus\n");
-exit(1);
-}
-
-for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
-hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
-}
+ide_drive_get(hd, MAX_IDE_BUS);
piix4_devfn = piix4_init(pci_bus, 80);
isa_bus_irqs(i8259);
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 8feb461..2834a46 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -287,15 +287,7 @@ void mips_r4k_init (ram_addr_t ram_size,
if (nd_table[0].vlan)
isa_ne2000_init(0x300, 9, &nd_table[0]);
-if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
-fprintf(stderr, "qemu: too many IDE bus\n");
-exit(1);
-}
-
-for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
-hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
-}
-
+ide_drive_get(hd, MAX_IDE_BUS);
for(i = 0; i < MAX_IDE_BUS; i++)
isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
hd[MAX_IDE_DEVS * i],
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index b3ede89..4d54ca1 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -129,15 +129,7 @@ static void pc_init1(ram_addr_t ram_size,
pci_nic_init_nofail(nd, "e1000", NULL);
}
-if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
-fprintf(stderr, "qemu: too many IDE bus\n");
-exit(1);
-}
-
-for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
-hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
-}
-
+ide_drive_get(hd, MAX_IDE_BUS);
if (pci_enabled) {
PCIDevice *dev;
dev = pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index b9245f0..86f1cfb 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -325,20 +325,13 @@ static void ppc_core99_init (ram_addr_t ram_size,
for(i = 0; i < nb_nics; i++)
pci_nic_init_nofail(&nd_table[i], "ne2k_pci", NULL);
-if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
-fprintf(stderr, "qemu: too many IDE bus\n");
-exit(1);
-}
+ide_drive_get(hd, MAX_IDE_BUS);
dbdma = DBDMA_init(&dbdma_mem_index);
/* We only emulate 2 out of 3 IDE controllers for now */
ide_mem_index[0] = -1;
-hd[0] = drive_get(IF_IDE, 0, 0);
-hd[1] = drive_get(IF_IDE, 0, 1);
ide_mem_index[1] = pmac_ide_init(hd, pic[0x0d], dbdma, 0x16, pic[0x02]);
-hd[0] = drive_get(IF_IDE, 1, 0);
-h
[Qemu-devel] [PATCH 07/15] exit if -drive specified is invalid instead of ignoring the "wrong" -drive
From: Michael Tokarev
This fixes the problem when qemu continues even if -drive specification
is somehow invalid, resulting in a mess. Applicable for both current
master and for stable-0.14 (and the same issue exist 0.13 and 0.12 too).
The prob can actually be seriuos: when you start guest with two drives
and make an error in the specification of one of them, and the guest
has something like a raid array on the two drives, guest may start failing
that array or kick "missing" drives which may result in a mess - this is
what actually happened to me, I did't want a resync at all, and a resync
resulted in re-writing (and allocating) a 4TB virtual drive I used for
testing, which in turn resulted in my filesystem filling up and whole
thing failing badly. Yes it was just testing VM, I experimented with
larger raid arrays, but the end result was quite, well, unexpected.
Signed-off-by: Michael Tokarev
Acked-by: Jes Sorensen
Signed-off-by: Kevin Wolf
---
vl.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index de232b7..68c3b53 100644
--- a/vl.c
+++ b/vl.c
@@ -2102,7 +2102,9 @@ int main(int argc, char **argv, char **envp)
HD_OPTS);
break;
case QEMU_OPTION_drive:
-drive_def(optarg);
+if (drive_def(optarg) == NULL) {
+exit(1);
+}
break;
case QEMU_OPTION_set:
if (qemu_set_option(optarg) != 0)
--
1.7.2.3
[Qemu-devel] [PATCH 14/15] Fix integer overflow in block migration bandwidth calculation
From: Avishay Traeger
block_mig_state.reads is an int, and multiplying by BLOCK_SIZE yielded a
negative number, resulting in a negative bandwidth (running on a 32-bit
machine). Change order to avoid.
Signed-off-by: Avishay Traeger
Signed-off-by: Kevin Wolf
---
block-migration.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 8218bac..576e55a 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -140,7 +140,7 @@ static inline void add_avg_read_time(int64_t time)
static inline long double compute_read_bwidth(void)
{
assert(block_mig_state.total_time != 0);
-return (block_mig_state.reads * BLOCK_SIZE)/ block_mig_state.total_time;
+return (block_mig_state.reads / block_mig_state.total_time) * BLOCK_SIZE;
}
static int bmds_aio_inflight(BlkMigDevState *bmds, int64_t sector)
--
1.7.2.3
[Qemu-devel] [PATCH 11/15] NBD: Use qemu_socket functions to open TCP and UNIX sockets
From: Nick Thomas
This commit has the side-effect of making the qemu-nbd binary
capable of binding to IPv6 addresses. ("-b ::1", for instance).
block/nbd.c fails to parse IPv6 IP addresses correctly at this
point, but will work over IPv6 when given a hostname. It still
works over IPv4 as before.
We move the qemu-sockets object from the 'common' to the 'block'
list in the Makefile. The common list includes the block list,
so this is effectively a no-op for the rest of the code.
We also add 32-bit 'magic' attributes to nbd_(request|reply) to
facilitate calculating maximum request/response sizes later.
Signed-off-by: Nick Thomas
Signed-off-by: Kevin Wolf
---
Makefile.objs |4 +-
nbd.c | 158 ++--
nbd.h |9 +++-
3 files changed, 38 insertions(+), 133 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index 94587e1..44ce368 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -14,7 +14,7 @@ oslib-obj-$(CONFIG_POSIX) += oslib-posix.o
# block-obj-y is code used by both qemu system emulation and qemu-img
block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o
async.o
-block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o qemu-progress.o
+block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o qemu-progress.o
qemu-sockets.o
block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
@@ -94,7 +94,7 @@ common-obj-$(CONFIG_SSI_SD) += ssi-sd.o
common-obj-$(CONFIG_SD) += sd.o
common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o
usb-bt.o
common-obj-y += bt-hci-csr.o
-common-obj-y += buffered_file.o migration.o migration-tcp.o qemu-sockets.o
+common-obj-y += buffered_file.o migration.o migration-tcp.o
common-obj-y += qemu-char.o savevm.o #aio.o
common-obj-y += msmouse.o ps2.o
common-obj-y += qdev.o qdev-properties.o
diff --git a/nbd.c b/nbd.c
index abe0ecb..0dcd86b 100644
--- a/nbd.c
+++ b/nbd.c
@@ -107,155 +107,55 @@ size_t nbd_wr_sync(int fd, void *buffer, size_t size,
bool do_read)
return offset;
}
-int tcp_socket_outgoing(const char *address, uint16_t port)
+static void combine_addr(char *buf, size_t len, const char* address,
+ uint16_t port)
{
-int s;
-struct in_addr in;
-struct sockaddr_in addr;
-
-s = socket(PF_INET, SOCK_STREAM, 0);
-if (s == -1) {
-return -1;
-}
-
-if (inet_aton(address, &in) == 0) {
-struct hostent *ent;
-
-ent = gethostbyname(address);
-if (ent == NULL) {
-goto error;
-}
-
-memcpy(&in, ent->h_addr, sizeof(in));
-}
-
-addr.sin_family = AF_INET;
-addr.sin_port = htons(port);
-memcpy(&addr.sin_addr.s_addr, &in, sizeof(in));
-
-if (connect(s, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
-goto error;
+/* If the address-part contains a colon, it's an IPv6 IP so needs [] */
+if (strstr(address, ":")) {
+snprintf(buf, len, "[%s]:%u", address, port);
+} else {
+snprintf(buf, len, "%s:%u", address, port);
}
-
-return s;
-error:
-closesocket(s);
-return -1;
}
-int tcp_socket_incoming(const char *address, uint16_t port)
+int tcp_socket_outgoing(const char *address, uint16_t port)
{
-int s;
-struct in_addr in;
-struct sockaddr_in addr;
-int opt;
-
-s = socket(PF_INET, SOCK_STREAM, 0);
-if (s == -1) {
-return -1;
-}
-
-if (inet_aton(address, &in) == 0) {
-struct hostent *ent;
-
-ent = gethostbyname(address);
-if (ent == NULL) {
-goto error;
-}
-
-memcpy(&in, ent->h_addr, sizeof(in));
-}
-
-addr.sin_family = AF_INET;
-addr.sin_port = htons(port);
-memcpy(&addr.sin_addr.s_addr, &in, sizeof(in));
-
-opt = 1;
-if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,
- (const void *) &opt, sizeof(opt)) == -1) {
-goto error;
-}
-
-if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
-goto error;
-}
-
-if (listen(s, 128) == -1) {
-goto error;
-}
-
-return s;
-error:
-closesocket(s);
-return -1;
+char address_and_port[128];
+combine_addr(address_and_port, 128, address, port);
+return tcp_socket_outgoing_spec(address_and_port);
}
-#ifndef _WIN32
-int unix_socket_incoming(const char *path)
+int tcp_socket_outgoing_spec(const char *address_and_port)
{
-int s;
-struct sockaddr_un addr;
-
-s = socket(PF_UNIX, SOCK_STREAM, 0);
-if (s == -1) {
-return -1;
-}
-
-memset(&addr, 0, sizeof(addr));
-addr.sun_family = AF_UNIX;
-pstrcpy(addr.sun_path, sizeof(addr.sun_path), path);
-
-if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
-goto error;
-}
-
-if (listen(s, 128) == -1) {
-goto error;
-}
-
-return s;
-error:
-closesocket(s);
-return -1;
+return inet_co
[Qemu-devel] [PATCH 13/15] floppy: save and restore DIR register
From: Jason Wang
We need to keep DIR register unchanged across migration, but currently it
depends on the media_changed flags from block layer. Since we do not
save/restore it and the bdrv_open() called in dest node may set the
media_changed flag when trying to open floppy image, guest driver may think the
floppy have changed after migration. To fix this, a new filed media_changed in
FDrive strcutre was introduced in order to save and restore the it from block
layer through pre_save/post_load callbacks.
Signed-off-by: Jason Wang
Reviewed-by: Juan Quintela
Acked-by: Paolo Bonzini
Signed-off-by: Kevin Wolf
---
hw/fdc.c | 51 ++-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index 9fdbc75..edf0360 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -36,6 +36,7 @@
#include "qdev-addr.h"
#include "blockdev.h"
#include "sysemu.h"
+#include "block_int.h"
//
/* debug Floppy devices */
@@ -82,6 +83,7 @@ typedef struct FDrive {
uint8_t max_track;/* Nb of tracks */
uint16_t bps; /* Bytes per sector */
uint8_t ro; /* Is read-only */
+uint8_t media_changed;/* Is media changed */
} FDrive;
static void fd_init(FDrive *drv)
@@ -533,16 +535,63 @@ static CPUWriteMemoryFunc * const
fdctrl_mem_write_strict[3] = {
NULL,
};
+static void fdrive_media_changed_pre_save(void *opaque)
+{
+FDrive *drive = opaque;
+
+drive->media_changed = drive->bs->media_changed;
+}
+
+static int fdrive_media_changed_post_load(void *opaque, int version_id)
+{
+FDrive *drive = opaque;
+
+if (drive->bs != NULL) {
+drive->bs->media_changed = drive->media_changed;
+}
+
+/* User ejected the floppy when drive->bs == NULL */
+return 0;
+}
+
+static bool fdrive_media_changed_needed(void *opaque)
+{
+FDrive *drive = opaque;
+
+return (drive->bs != NULL && drive->bs->media_changed != 1);
+}
+
+static const VMStateDescription vmstate_fdrive_media_changed = {
+.name = "fdrive/media_changed",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.pre_save = fdrive_media_changed_pre_save,
+.post_load = fdrive_media_changed_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(media_changed, FDrive),
+VMSTATE_END_OF_LIST()
+}
+};
+
static const VMStateDescription vmstate_fdrive = {
.name = "fdrive",
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
-.fields = (VMStateField []) {
+.fields = (VMStateField[]) {
VMSTATE_UINT8(head, FDrive),
VMSTATE_UINT8(track, FDrive),
VMSTATE_UINT8(sect, FDrive),
VMSTATE_END_OF_LIST()
+},
+.subsections = (VMStateSubsection[]) {
+{
+.vmsd = &vmstate_fdrive_media_changed,
+.needed = &fdrive_media_changed_needed,
+} , {
+/* empty */
+}
}
};
--
1.7.2.3
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote: > On 04/07/2011 03:22 AM, Bei Guan wrote: > >Hi, > > > >I have some questions about the qemu's bios. How does the QEMU > >load the binary files bios.bin and vgabios-cirrus.bin? Which > >function or code file need I to pay more attention to? > > > >For the loading of vgabios-cirrus.bin and bios.bin, I just trace > >them into the same funciton rom_add_file() in hw/loader.c. Is it > >the right function, which loads the bioses? > > > >And then another question, how qemu give the control to bios when > >the bios file is loaded? Maybe this question is not in the scope > >of qemu, however, can you give me some cue point. > > I had some stuff written up locally so I posted it to the wiki at > http://wiki.qemu.org/Documentation/Platforms/PC > > The x86 architecture defines the initial state of the chip to have > the CS register have a base of 0xF000 and an IP of 0xFFF0. The > result is that the actual memory address of the first instruction > falls at the end of the BIOS ROM segment. This is the entry point > to the BIOS. > Actually after reset on x86 IP=0xfff0, CS=0xf000, CS.BASE= 0x, CS.LIMIT=0x. So the execution begins at 0xfff0 where ROM is mapped initially. > The VGABIOS is treated like any other option ROM and is initialized > during option ROM scanning. > > Regards, > > Anthony Liguori > > >Any reply are appreciated. Thanks. > > > >Gavin > > > > > > > > > -- Gleb.
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On 04/07/2011 10:31 AM, Gleb Natapov wrote: On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote: On 04/07/2011 03:22 AM, Bei Guan wrote: Hi, I have some questions about the qemu's bios. How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Which function or code file need I to pay more attention to? For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into the same funciton rom_add_file() in hw/loader.c. Is it the right function, which loads the bioses? And then another question, how qemu give the control to bios when the bios file is loaded? Maybe this question is not in the scope of qemu, however, can you give me some cue point. I had some stuff written up locally so I posted it to the wiki at http://wiki.qemu.org/Documentation/Platforms/PC The x86 architecture defines the initial state of the chip to have the CS register have a base of 0xF000 and an IP of 0xFFF0. The result is that the actual memory address of the first instruction falls at the end of the BIOS ROM segment. This is the entry point to the BIOS. Actually after reset on x86 IP=0xfff0, CS=0xf000, CS.BASE= 0x, CS.LIMIT=0x. So the execution begins at 0xfff0 where ROM is mapped initially. That impossible because 1) the processor starts in 16 bit mode so such an address cannot be generated 2) the processor has a20 held to zero which makes that the processor cannot generate a load to an address with the 20th bit set to anything but zero. The CS base starts out at 0xf and IP is 0xfff0. That gives a real address of 0x0. This is usually a trampoline to somewhere else in the space. The mapping of BIOS to the top of 4GB is just a convention that modern BIOSes use because the legacy space isn't big enough for most modern BIOSes. Regards, Anthony Liguori The VGABIOS is treated like any other option ROM and is initialized during option ROM scanning. Regards, Anthony Liguori Any reply are appreciated. Thanks. Gavin -- Gleb.
Re: [Qemu-devel] [PULL 00/15] Block patches
On 04/07/2011 09:49 AM, Kevin Wolf wrote: The following changes since commit 3b8e6a2db1946b5f21e69fde31b39f43367f1928: exec: Handle registrations of the entire address space (2011-04-07 10:53:41 +0200) Pulled. Thanks. Regards, Anthony Liguori are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Avishay Traeger (1): Fix integer overflow in block migration bandwidth calculation Christoph Hellwig (1): virtio-blk: fail unaligned requests Feiran Zheng (1): hw/xen_disk: ioreq not finished on error Isaku Yamahata (1): ide: consolidate drive_get(IF_IDE) Jason Wang (1): floppy: save and restore DIR register Jes Sorensen (1): qemu-img: Initial progress printing support Kevin Wolf (1): qemu-img rebase: Fix segfault if backing file can't be opened Michael Tokarev (1): exit if -drive specified is invalid instead of ignoring the "wrong" -drive Nick Thomas (4): NBD library: whitespace changes Set errno=ENOTSUP for attempts to use UNIX sockets on Windows platforms NBD: Use qemu_socket functions to open TCP and UNIX sockets NBD device: Separate out parsing configuration and opening sockets. Ryan Harper (1): Do not delete BlockDriverState when deleting the drive Stefan Hajnoczi (2): trace: Trace bdrv_set_locked() block: Do not cache device size for removable media Makefile.objs |4 +- block-migration.c |2 +- block.c| 28 +- block.h|1 + block/nbd.c| 157 ++--- blockdev.c | 25 +- hw/fdc.c | 51 +++- hw/ide.h |3 + hw/ide/core.c | 14 + hw/mips_fulong2e.c |9 +- hw/mips_malta.c| 10 +- hw/mips_r4k.c | 10 +- hw/pc_piix.c | 10 +- hw/ppc_newworld.c | 11 +- hw/ppc_oldworld.c | 11 +- hw/ppc_prep.c | 10 +- hw/sun4u.c |9 +- hw/virtio-blk.c|8 + hw/xen_disk.c | 10 +- nbd.c | 993 +++- nbd.h |9 +- qemu-common.h |4 + qemu-img-cmds.hx |4 +- qemu-img.c | 46 +++- qemu-progress.c| 89 + qemu-sockets.c |4 + trace-events |1 + vl.c |4 +- 28 files changed, 825 insertions(+), 712 deletions(-) create mode 100644 qemu-progress.c
Re: [Qemu-devel] [GIT PULL] Trivial patches for 6-7 April 2011
On 04/07/2011 09:15 AM, Stefan Hajnoczi wrote: The following changes since commit 3b8e6a2db1946b5f21e69fde31b39f43367f1928: exec: Handle registrations of the entire address space (2011-04-07 10:53:41 +0200) are available in the git repository at: git://repo.or.cz/qemu/stefanha.git trivial-patches Pulled, thanks. In the future, can you just use [PULL instead of [GIT PULL? Regards, Anthony Liguori Alexey Kardashevskiy (3): spapr_llan: Fix warning when compiled with -dDEBUG virtio-9p: fixed LE-to-host conversion bug when QEMU is called from guest virtio-balloon: fixed endianness bug in the config space Brad Hards (1): usb-ccid: Spelling fixes Michael Tokarev (1): qdev: Fix comment around qdev_init_nofail() hw/qdev.c |3 ++- hw/spapr_llan.c |3 --- hw/usb-ccid.c |8 hw/virtio-9p.c |9 +++-- hw/virtio-balloon.c |2 +- 5 files changed, 10 insertions(+), 15 deletions(-)
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 10:42:56AM -0500, Anthony Liguori wrote: > On 04/07/2011 10:31 AM, Gleb Natapov wrote: > >On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote: > >>On 04/07/2011 03:22 AM, Bei Guan wrote: > >>>Hi, > >>> > >>>I have some questions about the qemu's bios. How does the QEMU > >>>load the binary files bios.bin and vgabios-cirrus.bin? Which > >>>function or code file need I to pay more attention to? > >>> > >>>For the loading of vgabios-cirrus.bin and bios.bin, I just trace > >>>them into the same funciton rom_add_file() in hw/loader.c. Is it > >>>the right function, which loads the bioses? > >>> > >>>And then another question, how qemu give the control to bios when > >>>the bios file is loaded? Maybe this question is not in the scope > >>>of qemu, however, can you give me some cue point. > >>I had some stuff written up locally so I posted it to the wiki at > >>http://wiki.qemu.org/Documentation/Platforms/PC > >> > >>The x86 architecture defines the initial state of the chip to have > >>the CS register have a base of 0xF000 and an IP of 0xFFF0. The > >>result is that the actual memory address of the first instruction > >>falls at the end of the BIOS ROM segment. This is the entry point > >>to the BIOS. > >> > >Actually after reset on x86 IP=0xfff0, CS=0xf000, CS.BASE= 0x, > >CS.LIMIT=0x. So the execution begins at 0xfff0 where ROM is > >mapped initially. > > That impossible because 1) the processor starts in 16 bit mode so > such an address cannot be generated 2) the processor has a20 held to > zero which makes that the processor cannot generate a load to an > address with the 20th bit set to anything but zero. > That may seams to be impossible but it is how HW works. And this is how QEMU emulates it. Look at target-i386/helper.c:cpu_reset() cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x, 0x, DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK); env->eip = 0xfff0; Don't know how a20 gate is handled btw. > The CS base starts out at 0xf and IP is 0xfff0. That gives a > real address of 0x0. This is usually a trampoline to somewhere > else in the space. CS descriptor and CS selector don't have to be in sync (big real mode). > > The mapping of BIOS to the top of 4GB is just a convention that > modern BIOSes use because the legacy space isn't big enough for most > modern BIOSes. > > Regards, > > Anthony Liguori > > >>The VGABIOS is treated like any other option ROM and is initialized > >>during option ROM scanning. > >> > >>Regards, > >> > >>Anthony Liguori > >> > >>>Any reply are appreciated. Thanks. > >>> > >>>Gavin > >>> > >>> > >>> > >>> > >-- > > Gleb. > > -- Gleb.
Re: [Qemu-devel] [GIT PULL] Trivial patches for 6-7 April 2011
On Thu, Apr 7, 2011 at 4:46 PM, Anthony Liguori wrote: > On 04/07/2011 09:15 AM, Stefan Hajnoczi wrote: >> >> The following changes since commit >> 3b8e6a2db1946b5f21e69fde31b39f43367f1928: >> >> exec: Handle registrations of the entire address space (2011-04-07 >> 10:53:41 +0200) >> >> are available in the git repository at: >> git://repo.or.cz/qemu/stefanha.git trivial-patches > > Pulled, thanks. > > In the future, can you just use [PULL instead of [GIT PULL? Sure. Stefan
[Qemu-devel] Re: [PATCH v2 2/2] rbd: allow configuration of rados from the rbd filename
On Thu, Apr 7, 2011 at 2:54 AM, Yoshiaki Tamura wrote: > 2011/4/7 Stefan Hajnoczi : >> On Thu, Apr 07, 2011 at 10:14:03AM +0900, Yoshiaki Tamura wrote: >>> 2011/3/29 Josh Durgin : >>> > The new format is >>> > rbd:pool/image[@snapshot][:option1=value1[:option2=value2...]] >>> > Each option is used to configure rados, and may be any Ceph option, or >>> > "conf". >>> > The "conf" option specifies a Ceph configuration file to read. >>> > >>> > This allows rbd volumes from more than one Ceph cluster to be used by >>> > specifying different monitor addresses, as well as having different >>> > logging levels or locations for different volumes. >>> > >>> > Signed-off-by: Josh Durgin >>> > --- >>> > block/rbd.c | 119 >>> > ++ >>> > 1 files changed, 102 insertions(+), 17 deletions(-) >>> > >>> > diff --git a/block/rbd.c b/block/rbd.c >>> > index cb76dd3..bc3323d 100644 >>> > --- a/block/rbd.c >>> > +++ b/block/rbd.c >>> > @@ -22,13 +22,17 @@ >>> > /* >>> > * When specifying the image filename use: >>> > * >>> > - * rbd:poolname/devicename >>> > + * >>> > rbd:poolname/devicename[@snapshotname][:option1=value1[:option2=value2...]] >>> >>> I'm not sure IIUC, but currently this @snapshotname seems to be >>> meaningless; it doesn't allow you to boot from a snapshot because it's >>> read only. Am I misunderstanding or tested incorrectly? >> >> Read-only block devices are supported by QEMU and can be useful. > > I agree. My expectation was that @snapshotname is introduced to have > writable snapshot. > The RADOS backend doesn't support writable snapshots. However, down the rbd roadmap we plan to have layering which in a sense is writable snapshots. The whole shift to librbd was done so that introducing such new functionality will be transparent and will not require much or any changes in the qemu code. Yehuda
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On 04/07/2011 10:51 AM, Gleb Natapov wrote: On Thu, Apr 07, 2011 at 10:42:56AM -0500, Anthony Liguori wrote: On 04/07/2011 10:31 AM, Gleb Natapov wrote: On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote: On 04/07/2011 03:22 AM, Bei Guan wrote: Hi, I have some questions about the qemu's bios. How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Which function or code file need I to pay more attention to? For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into the same funciton rom_add_file() in hw/loader.c. Is it the right function, which loads the bioses? And then another question, how qemu give the control to bios when the bios file is loaded? Maybe this question is not in the scope of qemu, however, can you give me some cue point. I had some stuff written up locally so I posted it to the wiki at http://wiki.qemu.org/Documentation/Platforms/PC The x86 architecture defines the initial state of the chip to have the CS register have a base of 0xF000 and an IP of 0xFFF0. The result is that the actual memory address of the first instruction falls at the end of the BIOS ROM segment. This is the entry point to the BIOS. Actually after reset on x86 IP=0xfff0, CS=0xf000, CS.BASE= 0x, CS.LIMIT=0x. So the execution begins at 0xfff0 where ROM is mapped initially. That impossible because 1) the processor starts in 16 bit mode so such an address cannot be generated 2) the processor has a20 held to zero which makes that the processor cannot generate a load to an address with the 20th bit set to anything but zero. That may seams to be impossible but it is how HW works. And this is how QEMU emulates it. Look at target-i386/helper.c:cpu_reset() cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x, 0x, DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK); env->eip = 0xfff0; Don't know how a20 gate is handled btw. I see that we use 0xf in the kernel but this is because of a limitation of VMX. I guess when 32-bit was introduced, this behavior was added. The CS base starts out at 0xf and IP is 0xfff0. That gives a real address of 0x0. This is usually a trampoline to somewhere else in the space. CS descriptor and CS selector don't have to be in sync (big real mode). Indeed. Regards, Anthony Liguori The mapping of BIOS to the top of 4GB is just a convention that modern BIOSes use because the legacy space isn't big enough for most modern BIOSes. Regards, Anthony Liguori The VGABIOS is treated like any other option ROM and is initialized during option ROM scanning. Regards, Anthony Liguori Any reply are appreciated. Thanks. Gavin -- Gleb. -- Gleb.
Re: [Qemu-devel] [PATCH RFC 0/5] kvm/vhost: enable durty logging during memory registration
On Thu, Apr 7, 2011 at 8:39 AM, Brad Hards wrote: > On Thu, 7 Apr 2011 06:41:35 am Michael S. Tsirkin wrote: >> As a solution, this adds an explicit flag that >> will enable dirty logging directly when registering >> the ram. kvm then needs a single system call >> to update tables for vga ram, vhost-net can simply ignore it. > I'm not very familiar with QEMU coding style and standards (so this could be > completely bogus), but I think that the code would be easier if you used a > integer flag / enum instead of a boolean. That would also give you options for > additional behaviour changes later too. So instead of passing true/false, pass > MEM_LOG_DIRTY_PAGES (or whatever you decide to call it). Good idea, it's more descriptive. Maybe also calls to qemu_register_coalesced_mmio() could be avoided with another flag?
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
2011/4/7 Anthony Liguori > On 04/07/2011 03:22 AM, Bei Guan wrote: > >> Hi, >> >> I have some questions about the qemu's bios. How does the QEMU load the >> binary files bios.bin and vgabios-cirrus.bin? Which function or code file >> need I to pay more attention to? >> >> For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into >> the same funciton rom_add_file() in hw/loader.c. Is it the right function, >> which loads the bioses? >> >> And then another question, how qemu give the control to bios when the bios >> file is loaded? Maybe this question is not in the scope of qemu, however, >> can you give me some cue point. >> > > I had some stuff written up locally so I posted it to the wiki at > http://wiki.qemu.org/Documentation/Platforms/PC Thanks for this detailed description. Is it to say that if we want to boot a BIOS (such as SeaBIOS), we must need to initialize the Memory ranged from 0x0 to 0xF, which includes DOS Memory Area, Video Memory, ISA Extension ROM and BIOS Extension ROM, with the information needed by BIOS? Another question is that in the QEMU, does all the information of the emulated hardware have to be filled in the memory layout before the SeaBIOS boot? And after it booting, the BIOS can do everything to boot the Operating System. This phase (BIOS runing) doesn't need any interaction with QEMU. Is it? Thanks. Gavin > > > The x86 architecture defines the initial state of the chip to have the CS > register have a base of 0xF000 and an IP of 0xFFF0. The result is that the > actual memory address of the first instruction falls at the end of the BIOS > ROM segment. This is the entry point to the BIOS. > > The VGABIOS is treated like any other option ROM and is initialized during > option ROM scanning. > > Regards, > > Anthony Liguori > > > Any reply are appreciated. Thanks. >> >> Gavin >> >> >> >> >> >
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, 7 Apr 2011, Anthony Liguori wrote: > On 04/07/2011 10:31 AM, Gleb Natapov wrote: > > On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote: > > > On 04/07/2011 03:22 AM, Bei Guan wrote: > > > > Hi, > > > > > > > > I have some questions about the qemu's bios. How does the QEMU > > > > load the binary files bios.bin and vgabios-cirrus.bin? Which > > > > function or code file need I to pay more attention to? > > > > > > > > For the loading of vgabios-cirrus.bin and bios.bin, I just trace > > > > them into the same funciton rom_add_file() in hw/loader.c. Is it > > > > the right function, which loads the bioses? > > > > > > > > And then another question, how qemu give the control to bios when > > > > the bios file is loaded? Maybe this question is not in the scope > > > > of qemu, however, can you give me some cue point. > > > I had some stuff written up locally so I posted it to the wiki at > > > http://wiki.qemu.org/Documentation/Platforms/PC > > > > > > The x86 architecture defines the initial state of the chip to have > > > the CS register have a base of 0xF000 and an IP of 0xFFF0. The > > > result is that the actual memory address of the first instruction > > > falls at the end of the BIOS ROM segment. This is the entry point > > > to the BIOS. > > > > > Actually after reset on x86 IP=0xfff0, CS=0xf000, CS.BASE= 0x, > > CS.LIMIT=0x. So the execution begins at 0xfff0 where ROM is > > mapped initially. > > That impossible because 1) the processor starts in 16 bit mode so such an > address cannot be generated 2) the processor has a20 held to zero which makes > that the processor cannot generate a load to an address with the 20th bit set > to anything but zero. It starts in big-real mode so only a20 can be a limiting factor.. > > The CS base starts out at 0xf and IP is 0xfff0. That gives a real address > of 0x0. This is usually a trampoline to somewhere else in the space. > > The mapping of BIOS to the top of 4GB is just a convention that modern BIOSes > use because the legacy space isn't big enough for most modern BIOSes. > > Regards, > > Anthony Liguori > > > > The VGABIOS is treated like any other option ROM and is initialized > > > during option ROM scanning. > > > > > > Regards, > > > > > > Anthony Liguori > > > > > > > Any reply are appreciated. Thanks. > > > > > > > > Gavin > > > > > > > > > > > > > > > > > > -- > > Gleb. > > > > -- mailto:av1...@comtv.ru
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
2011/4/8 Bei Guan > > > 2011/4/7 Anthony Liguori > >> On 04/07/2011 03:22 AM, Bei Guan wrote: >> >>> Hi, >>> >>> I have some questions about the qemu's bios. How does the QEMU load the >>> binary files bios.bin and vgabios-cirrus.bin? Which function or code file >>> need I to pay more attention to? >>> >>> For the loading of vgabios-cirrus.bin and bios.bin, I just trace them >>> into the same funciton rom_add_file() in hw/loader.c. Is it the right >>> function, which loads the bioses? >>> >>> And then another question, how qemu give the control to bios when the >>> bios file is loaded? Maybe this question is not in the scope of qemu, >>> however, can you give me some cue point. >>> >> >> I had some stuff written up locally so I posted it to the wiki at >> http://wiki.qemu.org/Documentation/Platforms/PC > > > Thanks for this detailed description. Is it to say that if we want to boot > a BIOS (such as SeaBIOS), we must need to initialize the Memory ranged from > 0x0 to 0xF, which includes DOS Memory Area, Video Memory, ISA > Extension ROM and BIOS Extension ROM, with the information needed by BIOS? > Is this Memory Layout all the same for all the BIOS booting? I mean that if we port another BIOS, do will need to modify the the codes of filling information into this Memory Layout? Thanks, Gavin > > Another question is that in the QEMU, does all the information of the > emulated hardware have to be filled in the memory layout before the SeaBIOS > boot? And after it booting, the BIOS can do everything to boot the Operating > System. This phase (BIOS runing) doesn't need any interaction with QEMU. Is > it? > > Thanks. > Gavin > > > >> >> >> The x86 architecture defines the initial state of the chip to have the CS >> register have a base of 0xF000 and an IP of 0xFFF0. The result is that the >> actual memory address of the first instruction falls at the end of the BIOS >> ROM segment. This is the entry point to the BIOS. >> >> The VGABIOS is treated like any other option ROM and is initialized during >> option ROM scanning. >> >> Regards, >> >> Anthony Liguori >> >> >> Any reply are appreciated. Thanks. >>> >>> Gavin >>> >>> >>> >>> >>> >> >
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 6 April 2011 20:34, Anthony Liguori wrote: > http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > > If an OS is totally hosed (spinning with interrupts disabled), and NMI can > be used to generate a crash dump. > > It's a debug feature and modelling it exactly the way we are probably makes > sense for other architectures too. The real semantics are basically force > guest crash dump. Ah, right. (There isn't really an equivalent to this on ARM since we don't have a real NMI equivalent. So any implementation for ARM qemu would be board dependent since you could wire a watchdog up to any interrupt.) Should we try to pick a command name that says what it's supposed to do rather than how it happens to be implemented on x86 ? -- PMM
Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading
On Thu Apr 07, 2011 at 14:52:34 +0100, Stefan Hajnoczi wrote: > On Thu, Apr 7, 2011 at 1:56 PM, Ralf Ramsauer > wrote: > > On 07.04.2011, at 14:48, Stefan Hajnoczi wrote: > > > >> Out of curiousity, why are you trying to kill spaces at all? > >> > >> Why not just use a correct command-line to invoke QEMU? > >> > >> Stefan > > > > Well it took me 2 days to find out why -initrd "module1, module2" didn't > > work. If there's a space after the comma you'll always > > get the error message "Failed to get image size". > > How about improving the error message? I'll send a patch shortly fixing the message. > > And if you want to pass a comma in a multiboot argument you've no way to do > > this. > > So -initrd"module1 settings=use_foo,use_bar" won't work! > > >From what I can tell your patch does not change this. It should be possible to put commas on the mb command line. Do we want to escape commas? Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 7, 2011 at 09:08, Anthony Liguori wrote: > On 04/07/2011 10:51 AM, Gleb Natapov wrote: >> That may seams to be impossible but it is how HW works. And this is how >> QEMU emulates it. Look at target-i386/helper.c:cpu_reset() >> >> cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x, 0x, >> DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | >> DESC_R_MASK | DESC_A_MASK); >> >> env->eip = 0xfff0; >> >> Don't know how a20 gate is handled btw. > > I see that we use 0xf in the kernel but this is because of a limitation > of VMX. I recently noticed that kvm does this. It does not seem to be a big deal as firmware can easily deal with it, but I did find it odd that kvm had the csbase of 0xf as processors generally use a csbase of 0x initially. (At least, this is what I've seen with Intel processors for the past 12 years.) How can this limitation exist with VMX if mode transitions are supported, in which case this type of csbase vs. real-mode segment mismatch can easily occur? > I guess when 32-bit was introduced, this behavior was added. > >>> The CS base starts out at 0xf and IP is 0xfff0. That gives a >>> real address of 0x0. This is usually a trampoline to somewhere >>> else in the space. >> >> CS descriptor and CS selector don't have to be in sync (big real mode). > > Indeed. Another place this will often be seen is SMM, as the SMBASE can easily be > 1MB, but the SMM entry is in 16 bit mode. -Jordan
[Qemu-devel] [PATCH] multiboot: Quote filename in error message.
Quote filename in error message to spot possible whitespace character in
the filename.
Signed-off-by: Adam Lackorzynski
---
hw/multiboot.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/multiboot.c b/hw/multiboot.c
index 0d2bfb4..6be6fa0 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -272,7 +272,7 @@ int load_multiboot(void *fw_cfg,
mb_debug("multiboot loading module: %s\n", initrd_filename);
mb_mod_length = get_image_size(initrd_filename);
if (mb_mod_length < 0) {
-fprintf(stderr, "failed to get %s image size\n",
initrd_filename);
+fprintf(stderr, "failed to get image size of '%s'\n",
initrd_filename);
exit(1);
}
--
1.7.4.1
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 11:18:54AM -0700, Jordan Justen wrote: > On Thu, Apr 7, 2011 at 09:08, Anthony Liguori wrote: > > On 04/07/2011 10:51 AM, Gleb Natapov wrote: > >> That may seams to be impossible but it is how HW works. And this is how > >> QEMU emulates it. Look at target-i386/helper.c:cpu_reset() > >> > >> cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x, 0x, > >> DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | > >> DESC_R_MASK | DESC_A_MASK); > >> > >> env->eip = 0xfff0; > >> > >> Don't know how a20 gate is handled btw. > > > > I see that we use 0xf in the kernel but this is because of a limitation > > of VMX. > > I recently noticed that kvm does this. It does not seem to be a big > deal as firmware can easily deal with it, but I did find it odd that > kvm had the csbase of 0xf as processors generally use a csbase of > 0x initially. (At least, this is what I've seen with Intel > processors for the past 12 years.) > > How can this limitation exist with VMX if mode transitions are > supported, in which case this type of csbase vs. real-mode segment > mismatch can easily occur? > VMX does not support real mode, so KVM uses vm86 to emulate real mode. Vm86 does not support case when CS != CS.BASE >> 4, so KVM needs to fall back to emulation if it occur. During mode transitions such situation usually exist for only a couple of instructions. This is one of the reasons why KVM does not support SMM. Newest Intel CPUs support real mode in VMX BTW. It is called "unrestricted guest" IIRC. > > I guess when 32-bit was introduced, this behavior was added. > > > >>> The CS base starts out at 0xf and IP is 0xfff0. That gives a > >>> real address of 0x0. This is usually a trampoline to somewhere > >>> else in the space. > >> > >> CS descriptor and CS selector don't have to be in sync (big real mode). > > > > Indeed. > > Another place this will often be seen is SMM, as the SMBASE can easily > be > 1MB, but the SMM entry is in 16 bit mode. > > -Jordan -- Gleb.
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 04/07/2011 01:10 PM, Peter Maydell wrote: On 6 April 2011 20:34, Anthony Liguori wrote: http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm If an OS is totally hosed (spinning with interrupts disabled), and NMI can be used to generate a crash dump. It's a debug feature and modelling it exactly the way we are probably makes sense for other architectures too. The real semantics are basically force guest crash dump. Ah, right. (There isn't really an equivalent to this on ARM since we don't have a real NMI equivalent. So any implementation for ARM qemu would be board dependent since you could wire a watchdog up to any interrupt.) Should we try to pick a command name that says what it's supposed to do rather than how it happens to be implemented on x86 ? Yup, I was thinking the same thing after I sent the note above. If we call it 'force-crash-dump', we can implement it as an NMI on target-i386 and potentially as something else on a different target. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On 04/07/2011 01:18 PM, Jordan Justen wrote: On Thu, Apr 7, 2011 at 09:08, Anthony Liguori wrote: On 04/07/2011 10:51 AM, Gleb Natapov wrote: That may seams to be impossible but it is how HW works. And this is how QEMU emulates it. Look at target-i386/helper.c:cpu_reset() cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x, 0x, DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK); env->eip = 0xfff0; Don't know how a20 gate is handled btw. I see that we use 0xf in the kernel but this is because of a limitation of VMX. I recently noticed that kvm does this. It does not seem to be a big deal as firmware can easily deal with it, but I did find it odd that kvm had the csbase of 0xf as processors generally use a csbase of 0x initially. (At least, this is what I've seen with Intel processors for the past 12 years.) How can this limitation exist with VMX if mode transitions are supported, in which case this type of csbase vs. real-mode segment mismatch can easily occur? Mismatches between cached segment descriptors and the segment registers are not problematic in KVM per say. The issue is that vm8086 mode doesn't allow for this and since KVM uses vm8086 to emulate real mode on processors that don't support whatever it is that Intel is calling it these days, we can't effectively support this. I guess when 32-bit was introduced, this behavior was added. The CS base starts out at 0xf and IP is 0xfff0. That gives a real address of 0x0. This is usually a trampoline to somewhere else in the space. CS descriptor and CS selector don't have to be in sync (big real mode). Indeed. Another place this will often be seen is SMM, as the SMBASE can easily be> 1MB, but the SMM entry is in 16 bit mode. KVM doesn't support SMM although that's not because of this. KVM doesn't allow execution of ROM memory which makes it difficult to implement PAM in the way it's intended to be implemented. This makes SMM a bit tricky to make work. Since there's never really been a pressing need to support SMM, to my knowledge, noone has even tried. Regards, Anthony Liguori -Jordan
[Qemu-devel] [Bug 753916] [NEW] performance bug with SeaBios 0.6.x
Public bug reported: in my tests SeaBios 0.5.1 has the best performance (100% faster) i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and windows xp (Pentium 4, 1 giga ram ddr) ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/753916 Title: performance bug with SeaBios 0.6.x Status in QEMU: New Bug description: in my tests SeaBios 0.5.1 has the best performance (100% faster) i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and windows xp (Pentium 4, 1 giga ram ddr)
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote: > The CS base starts out at 0xf and IP is 0xfff0. That gives a > real address of 0x0. This is usually a trampoline to somewhere > else in the space. > >>>CS descriptor and CS selector don't have to be in sync (big real mode). > >>Indeed. > >Another place this will often be seen is SMM, as the SMBASE can easily > >be> 1MB, but the SMM entry is in 16 bit mode. > > KVM doesn't support SMM although that's not because of this. KVM > doesn't allow execution of ROM memory which makes it difficult to > implement PAM in the way it's intended to be implemented. This > makes SMM a bit tricky to make work. Since there's never really > been a pressing need to support SMM, to my knowledge, noone has even > tried. > KVM allows to execute ROM memory (BIOS and option roms run this way). It just makes it indistinguishable from RAM, but read only memory slot support shouldn't be too hard. Why ability to execute ROM memory is needed to support SMM though? -- Gleb.
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote: > On 04/07/2011 01:10 PM, Peter Maydell wrote: > >On 6 April 2011 20:34, Anthony Liguori wrote: > >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > >> > >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can > >>be used to generate a crash dump. > >> > >>It's a debug feature and modelling it exactly the way we are probably makes > >>sense for other architectures too. The real semantics are basically force > >>guest crash dump. > >Ah, right. (There isn't really an equivalent to this on ARM since > >we don't have a real NMI equivalent. So any implementation for ARM > >qemu would be board dependent since you could wire a watchdog up to > >any interrupt.) > > > >Should we try to pick a command name that says what it's supposed to > >do rather than how it happens to be implemented on x86 ? > > Yup, I was thinking the same thing after I sent the note above. If > we call it 'force-crash-dump', we can implement it as an NMI on > target-i386 and potentially as something else on a different target. > NMI does not have to generate crash dump on every guest we support. Actually even for windows guest it does not generate one without tweaking registry. For all I know there is a guest that checks mail when NMI arrives. Lets give meaningful name, like inject-nmi, for nmi injection command. -- Gleb.
Re: [Qemu-devel] git.qemu.org problem, down?
On Sun, 3 Apr 2011, Anthony Liguori wrote: http://git.qemu.org/git/qemu.git Is the right http URL. Website still has wrong URL. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov wrote: > On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote: >> On 04/07/2011 01:10 PM, Peter Maydell wrote: >> >On 6 April 2011 20:34, Anthony Liguori wrote: >> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm >> >> >> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can >> >>be used to generate a crash dump. >> >> >> >>It's a debug feature and modelling it exactly the way we are probably makes >> >>sense for other architectures too. The real semantics are basically force >> >>guest crash dump. >> >Ah, right. (There isn't really an equivalent to this on ARM since >> >we don't have a real NMI equivalent. So any implementation for ARM >> >qemu would be board dependent since you could wire a watchdog up to >> >any interrupt.) >> > >> >Should we try to pick a command name that says what it's supposed to >> >do rather than how it happens to be implemented on x86 ? >> >> Yup, I was thinking the same thing after I sent the note above. If >> we call it 'force-crash-dump', we can implement it as an NMI on >> target-i386 and potentially as something else on a different target. >> > NMI does not have to generate crash dump on every guest we support. > Actually even for windows guest it does not generate one without > tweaking registry. For all I know there is a guest that checks mail when > NMI arrives. Lets give meaningful name, like inject-nmi, for nmi > injection command. I'd prefer something more generic like these: raise /apic@fee0:l1int lower /i44FX-pcihost/e1000@03.0/pinD The clumsier syntax shouldn't be a problem, since this would be a system developer tool. Some kind of IRQ registration would be needed for this to work without lots of changes.
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 7, 2011 at 11:44, Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
>> The CS base starts out at 0xf and IP is 0xfff0. That gives a
>> real address of 0x0. This is usually a trampoline to somewhere
>> else in the space.
>> >>>CS descriptor and CS selector don't have to be in sync (big real mode).
>> >>Indeed.
>> >Another place this will often be seen is SMM, as the SMBASE can easily
>> >be> 1MB, but the SMM entry is in 16 bit mode.
>>
>> KVM doesn't support SMM although that's not because of this. KVM
>> doesn't allow execution of ROM memory which makes it difficult to
>> implement PAM in the way it's intended to be implemented. This
>> makes SMM a bit tricky to make work. Since there's never really
>> been a pressing need to support SMM, to my knowledge, noone has even
>> tried.
>>
> KVM allows to execute ROM memory (BIOS and option roms run this way). It
> just makes it indistinguishable from RAM, but read only memory slot
> support shouldn't be too hard. Why ability to execute ROM memory is
> needed to support SMM though?
True.
The only possible requirement is to 'hide SMRAM' when not in SMM mode.
Even this is chipset specific, and arguable depending on the goals of
SMM support in that system. (Although, generally, hiding SMRAM is a
requirement. :)
But, Anthony's point ('there's never really been a pressing need to
support SMM') is probably the most important here, as I can't see a
compelling use for SMM in QEMU.
-Jordan
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
> On Thu, Apr 7, 2011 at 11:44, Gleb Natapov wrote:
> > On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
> >> The CS base starts out at 0xf and IP is 0xfff0. That gives a
> >> real address of 0x0. This is usually a trampoline to somewhere
> >> else in the space.
> >> >>>CS descriptor and CS selector don't have to be in sync (big real mode).
> >> >>Indeed.
> >> >Another place this will often be seen is SMM, as the SMBASE can easily
> >> >be> 1MB, but the SMM entry is in 16 bit mode.
> >>
> >> KVM doesn't support SMM although that's not because of this. KVM
> >> doesn't allow execution of ROM memory which makes it difficult to
> >> implement PAM in the way it's intended to be implemented. This
> >> makes SMM a bit tricky to make work. Since there's never really
> >> been a pressing need to support SMM, to my knowledge, noone has even
> >> tried.
> >>
> > KVM allows to execute ROM memory (BIOS and option roms run this way). It
> > just makes it indistinguishable from RAM, but read only memory slot
> > support shouldn't be too hard. Why ability to execute ROM memory is
> > needed to support SMM though?
>
> True.
>
> The only possible requirement is to 'hide SMRAM' when not in SMM mode.
> Even this is chipset specific, and arguable depending on the goals of
> SMM support in that system. (Although, generally, hiding SMRAM is a
> requirement. :)
>
> But, Anthony's point ('there's never really been a pressing need to
> support SMM') is probably the most important here, as I can't see a
> compelling use for SMM in QEMU.
>
Yeah, that is probably the main reason. Although lately there was a
proposition to use SMM in seabios to access MMIO bar of USB device from
16bit mode. Do not remember details exactly. But I, personally, will be
very glad to not implement SMM support for KVM ;)
--
Gleb.
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote: > On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov wrote: > > On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote: > >> On 04/07/2011 01:10 PM, Peter Maydell wrote: > >> >On 6 April 2011 20:34, Anthony Liguori wrote: > >> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > >> >> > >> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI > >> >>can > >> >>be used to generate a crash dump. > >> >> > >> >>It's a debug feature and modelling it exactly the way we are probably > >> >>makes > >> >>sense for other architectures too. The real semantics are basically > >> >>force > >> >>guest crash dump. > >> >Ah, right. (There isn't really an equivalent to this on ARM since > >> >we don't have a real NMI equivalent. So any implementation for ARM > >> >qemu would be board dependent since you could wire a watchdog up to > >> >any interrupt.) > >> > > >> >Should we try to pick a command name that says what it's supposed to > >> >do rather than how it happens to be implemented on x86 ? > >> > >> Yup, I was thinking the same thing after I sent the note above. If > >> we call it 'force-crash-dump', we can implement it as an NMI on > >> target-i386 and potentially as something else on a different target. > >> > > NMI does not have to generate crash dump on every guest we support. > > Actually even for windows guest it does not generate one without > > tweaking registry. For all I know there is a guest that checks mail when > > NMI arrives. Lets give meaningful name, like inject-nmi, for nmi > > injection command. > > I'd prefer something more generic like these: > raise /apic@fee0:l1int > lower /i44FX-pcihost/e1000@03.0/pinD > > The clumsier syntax shouldn't be a problem, since this would be a > system developer tool. > > Some kind of IRQ registration would be needed for this to work without > lots of changes. True. The ability to trigger any interrupt line is very useful for debugging. I often re-implement it during debug. -- Gleb.
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On 04/07/2011 01:44 PM, Gleb Natapov wrote: KVM doesn't support SMM although that's not because of this. KVM doesn't allow execution of ROM memory which makes it difficult to implement PAM in the way it's intended to be implemented. This makes SMM a bit tricky to make work. Since there's never really been a pressing need to support SMM, to my knowledge, noone has even tried. KVM allows to execute ROM memory (BIOS and option roms run this way). It just makes it indistinguishable from RAM, but read only memory slot support shouldn't be too hard. Why ability to execute ROM memory is needed to support SMM though? QEMU does the leg work already to support SMM. It doesn't work with KVM because we treat SMM as ROM memory and trap read/write access. To make it work with KVM, you'd have to hack things around to switch the VGA space to RAM in order to the let the SMM code run. It's not impossible, but that's the main reason it doesn't Just Work. Regards, Anthony Liguori -- Gleb.
Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
> But, Anthony's point ('there's never really been a pressing need to
> support SMM') is probably the most important here, as I can't see a
> compelling use for SMM in QEMU.
Running real biosen instead of seabios? Of course that's mostly
useful when reverse-engineering devices, which is a borderline use of
kvm.
OG.
