Re: [Qemu-devel] [PATCH] reenable vm_clock when resuming all vcpus
At 11/04/2011 10:48 AM, Zhi Yong Wu Write:
On Fri, Nov 4, 2011 at 10:45 AM, Wen Congyang we...@cn.fujitsu.com wrote:
We disable vm_clock when pausing all vcpus, but we forget to
reenable it when resuming all vcpus. It will cause that the
guest can not be rebooted.
Actually i also met this issue when rebooting the guest. When the
guest is rebooted, it will crash.
When I reboot the guest, it will hang.
Does this patch solve your problem?
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
cpus.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpus.c b/cpus.c
index 6aff425..82530c4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -891,6 +891,7 @@ void resume_all_vcpus(void)
{
CPUState *penv = first_cpu;
+qemu_clock_enable(vm_clock, true);
while (penv) {
penv-stop = 0;
penv-stopped = 0;
--
1.7.1
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] The mainpage of QEMU.org is attacked?
Am 04.11.2011 03:56, schrieb Anthony Liguori: On 11/03/2011 09:43 PM, Zhi Yong Wu wrote: HI, Just now i found that the mainpage of QEMU.org is hacked, right? http://wiki.qemu.org/Main_Page Not hacked, it's a wiki, so it's vulnerable to spam. Folks have been doing a great job reverting the spam. It amazes me that the spambots are beating the captcha so easily :-/ I've protected the front page for now as I think this is happening repeatedly. Regards, Anthony Liguori I suggest more restrictions for new user accounts to reduce wiki spam. These mediawiki extensions require more reasonable user names and account confirmation: http://www.mediawiki.org/wiki/Extension:ConfirmAccount http://www.mediawiki.org/wiki/Extension:AntiSpoof For someone who is really interested in contributing to the QEMU wiki, account confirmation should be acceptable, and we could be sure that there is at least a valid mail address connected to the new account. The rate of valid account request will be much less than the current rate of new spammer accounts and their bad contributions, so the work required to process them is less than the current work to remove spam. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH V3 05/10] pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
Good catch. This patch (and the next one 6/10) can be picked up independently through qemu-trivial or pci-tree. On Fri, Oct 28, 2011 at 04:07:31PM +0100, Anthony PERARD wrote: Value check in PCI Express Base Specification rev 1.1 Signed-off-by: Anthony PERARD anthony.per...@citrix.com --- hw/pci_regs.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pci_regs.h b/hw/pci_regs.h index e8357c3..6b42515 100644 --- a/hw/pci_regs.h +++ b/hw/pci_regs.h @@ -393,7 +393,7 @@ #define PCI_EXP_TYPE_DOWNSTREAM 0x6 /* Downstream Port */ #define PCI_EXP_TYPE_PCI_BRIDGE 0x7 /* PCI/PCI-X Bridge */ #define PCI_EXP_TYPE_RC_END 0x9 /* Root Complex Integrated Endpoint */ -#define PCI_EXP_TYPE_RC_EC 0x10/* Root Complex Event Collector */ +#define PCI_EXP_TYPE_RC_EC 0xa /* Root Complex Event Collector */ #define PCI_EXP_FLAGS_SLOT 0x0100 /* Slot implemented */ #define PCI_EXP_FLAGS_IRQ0x3e00 /* Interrupt message number */ #define PCI_EXP_DEVCAP 4 /* Device capabilities */ -- Anthony PERARD -- yamahata
Re: [Qemu-devel] [PATCH] reenable vm_clock when resuming all vcpus
On 11/04/2011 03:45 AM, Wen Congyang wrote:
We disable vm_clock when pausing all vcpus, but we forget to
reenable it when resuming all vcpus. It will cause that the
guest can not be rebooted.
Signed-off-by: Wen Congyangwe...@cn.fujitsu.com
---
cpus.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpus.c b/cpus.c
index 6aff425..82530c4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -891,6 +891,7 @@ void resume_all_vcpus(void)
{
CPUState *penv = first_cpu;
+qemu_clock_enable(vm_clock, true);
while (penv) {
penv-stop = 0;
penv-stopped = 0;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
The code I have now works for TCG, but of course not for KVM. Thanks.
Paolo
[Qemu-devel] [PATCH] block: Use bdrv functions to replace file operation in cow.c
Since common file operation functions lack of error detection,
so change them to bdrv series functions.
Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com
---
block/cow.c | 63 +-
1 files changed, 36 insertions(+), 27 deletions(-)
diff --git a/block/cow.c b/block/cow.c
index 707c0aa..46649c2 100644
--- a/block/cow.c
+++ b/block/cow.c
@@ -138,8 +138,8 @@ static int cow_is_allocated(BlockDriverState *bs, int64_t
sector_num,
int changed;
if (nb_sectors == 0) {
- *num_same = nb_sectors;
- return 0;
+*num_same = nb_sectors;
+return 0;
}
changed = is_bit_set(bs, sector_num);
@@ -148,8 +148,9 @@ static int cow_is_allocated(BlockDriverState *bs, int64_t
sector_num,
}
for (*num_same = 1; *num_same nb_sectors; (*num_same)++) {
- if (is_bit_set(bs, sector_num + *num_same) != changed)
- break;
+if (is_bit_set(bs, sector_num + *num_same) != changed) {
+break;
+}
}
return changed;
@@ -243,12 +244,13 @@ static void cow_close(BlockDriverState *bs)
static int cow_create(const char *filename, QEMUOptionParameter *options)
{
-int fd, cow_fd;
struct cow_header_v2 cow_header;
struct stat st;
int64_t image_sectors = 0;
const char *image_filename = NULL;
int ret;
+BlockDriverState *cow_bs;
+BlockDriverState *image_bs;
/* Read out options */
while (options options-name) {
@@ -260,10 +262,16 @@ static int cow_create(const char *filename,
QEMUOptionParameter *options)
options++;
}
-cow_fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY,
- 0644);
-if (cow_fd 0)
-return -errno;
+ret = bdrv_create_file(filename, options);
+if (ret 0) {
+return ret;
+}
+
+ret = bdrv_file_open(cow_bs, filename, BDRV_O_RDWR);
+if (ret 0) {
+return ret;
+}
+
memset(cow_header, 0, sizeof(cow_header));
cow_header.magic = cpu_to_be32(COW_MAGIC);
cow_header.version = cpu_to_be32(COW_VERSION);
@@ -271,16 +279,16 @@ static int cow_create(const char *filename,
QEMUOptionParameter *options)
/* Note: if no file, we put a dummy mtime */
cow_header.mtime = cpu_to_be32(0);
-fd = open(image_filename, O_RDONLY | O_BINARY);
-if (fd 0) {
-close(cow_fd);
+ret = bdrv_file_open(image_bs, image_filename, BDRV_O_RDWR);
+if (ret 0) {
+bdrv_close(cow_bs);
goto mtime_fail;
}
-if (fstat(fd, st) != 0) {
-close(fd);
+if (stat(image_filename, st) != 0) {
+bdrv_close(image_bs);
goto mtime_fail;
}
-close(fd);
+bdrv_close(image_bs);
cow_header.mtime = cpu_to_be32(st.st_mtime);
mtime_fail:
pstrcpy(cow_header.backing_file, sizeof(cow_header.backing_file),
@@ -288,21 +296,22 @@ static int cow_create(const char *filename,
QEMUOptionParameter *options)
}
cow_header.sectorsize = cpu_to_be32(512);
cow_header.size = cpu_to_be64(image_sectors * 512);
-ret = qemu_write_full(cow_fd, cow_header, sizeof(cow_header));
+ret = bdrv_pwrite(cow_bs, 0, cow_header, sizeof(cow_header));
if (ret != sizeof(cow_header)) {
ret = -errno;
goto exit;
}
/* resize to include at least all the bitmap */
-ret = ftruncate(cow_fd, sizeof(cow_header) + ((image_sectors + 7) 3));
+ret = bdrv_truncate(cow_bs,
+sizeof(cow_header) + ((image_sectors + 7) 3));
if (ret) {
ret = -errno;
goto exit;
}
exit:
-close(cow_fd);
+bdrv_close(cow_bs);
return ret;
}
@@ -326,16 +335,16 @@ static QEMUOptionParameter cow_create_options[] = {
};
static BlockDriver bdrv_cow = {
-.format_name = cow,
-.instance_size = sizeof(BDRVCowState),
-.bdrv_probe= cow_probe,
-.bdrv_open = cow_open,
-.bdrv_read = cow_co_read,
-.bdrv_write = cow_co_write,
-.bdrv_close= cow_close,
-.bdrv_create = cow_create,
+.format_name= cow,
+.instance_size = sizeof(BDRVCowState),
+.bdrv_probe = cow_probe,
+.bdrv_open = cow_open,
+.bdrv_read = cow_co_read,
+.bdrv_write = cow_co_write,
+.bdrv_close = cow_close,
+.bdrv_create= cow_create,
.bdrv_co_flush = cow_co_flush,
-.bdrv_is_allocated = cow_is_allocated,
+.bdrv_is_allocated = cow_is_allocated,
.create_options = cow_create_options,
};
--
1.7.4.1
Re: [Qemu-devel] qemu ARM host support likely to be broken in 1.0
On 11/04/2011 02:52 AM, Peter Maydell wrote: * the fixed address we mmap the code gen buffer to in system mode tends to overlap the libc heap (at least on Ubuntu oneiric); when this happens you typically get a sysmalloc abort Let's change this to use the .bss code gen buffer. We can make it depend on __arm__ for 1.0, and toggle it for all architectures for 1.1 after testing on Windows (Linux and Mac OS X should have no problem). Paolo
Re: [Qemu-devel] GSoC mentor summit QEMU users session
On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote: On 03/11/2011 08:44, Stefan Hajnoczi wrote: On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau chout...@adacore.com wrote: On 29/10/2011 15:52, Alexander Graf wrote: I took a quick peak at the qemu-trace.[ch] from couverture and it looks along the lines of the instrumentation that others have been doing too. I hope you have time to propose the coverage instrumentation for upstream QEMU. I don't know much about other instrumentations in Qemu (pointers are welcome :), but what we have in couverture-qemu is not trivial, especially when it comes to MC/DC analysis. You should take a look at 201005-erts2.pdf if you want technical details. My impression was that the QEMU portion of instrumentation was fairly simple - it writes out trace records at various interesting points during guest execution in TCG. I think fancy analysis scripts do not have to be part of QEMU but they could be added to scripts/ or put in a new contrib/ directory. On the train, can't access the PDF you mentioned right now. Stefan
Re: [Qemu-devel] [RFC] block: convert block_stream command to QAPI
On Thu, Nov 03, 2011 at 01:51:54PM -0200, Luiz Capitulino wrote: On Tue, 1 Nov 2011 18:08:16 + Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: Move from plain HMP/QMP command implementation to QAPI. The block_stream command takes arguments, returns nothing, may raise errors, and will raise a QMP event when the operation completes. --- Hi Luiz, I converted block_stream to QAPI. The in-tree examples are quite simple so far so I hope I've converted this command in a reasonable way. Please let me know what you think: In general it looks good. The fact that the diff is against your latest series (vs. against master) didn't help me, so I couldn't test the command. Thanks for the feedback. I will send out proper patches for all image streaming commands soon. Just wanted to make sure I'm using doing the QAPI conversion correctly before I do all of the commands. Stefan
Re: [Qemu-devel] [PATCH 3/8] block: add image streaming block job
On Thu, Nov 03, 2011 at 02:34:24PM -0200, Marcelo Tosatti wrote:
On Wed, Nov 02, 2011 at 03:43:49PM +, Stefan Hajnoczi wrote:
On Tue, Nov 1, 2011 at 6:06 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Oct 27, 2011 at 04:22:50PM +0100, Stefan Hajnoczi wrote:
+
+ for (sector_num = 0; sector_num end; sector_num += n) {
+ if (block_job_is_cancelled(s-common)) {
+ break;
+ }
If cancellation is seen here in the last loop iteration,
bdrv_change_backing_file below should not be executed.
I documented this case in the QMP API. I'm not sure if it's possible
to guarantee that the operation isn't just completing as you cancel
it. Any blocking point between completion of the last iteration and
completing the operation is vulnerable to missing the cancel. It's
easier to explicitly say the operation might just have completed when
you canceled, rather than trying to protect the completion path. Do
you think it's a problem to have these loose semantics that I
described?
No, that is ok. I'm referring to bdrv_change_backing_file() being
executed without the entire image being streamed.
if (sector_num == end ret == 0) includes both all sectors being
streamed and all sectors except the last iteration being streamed (due
to job cancelled break).
I don't see the case you mention. Here is the code again:
for (sector_num = 0; sector_num end; sector_num += n) {
if (block_job_is_cancelled(s-common)) {
break;
}
If we are on the last iteration, then sector_num = end - m, where m 0
and is the number of sectors we are about to stream.
If we are cancelled during this last iteration then sector_num == end
- m. Therefore the if (sector_num == end ret == 0) case does not
evaluate to true.
The only way we can reach sector_num == end is by having successfully
streamed those last m sectors. Why? Because sector_num is a 0-based
index and not a 1-based index, so it excludes end.
+
+ /* TODO rate-limit */
+ /* Note that even when no rate limit is applied we need to
yield with
+ * no pending I/O here so that qemu_aio_flush() is able to
return.
+ */
+ co_sleep_ns(rt_clock, 0);
How do you plan to implement rate limit?
It was implemented in the QED-specific image streaming series:
http://repo.or.cz/w/qemu/stefanha.git/commitdiff/22f2c09d2fcfe5e49ac4604fd23e4744f549a476
That implementation works fine and is small but I'd like to reuse the
migration speed limit, if possible. That way we don't have 3
different rate-limiting implementations in QEMU :).
One possibility would be to create a virtual block device for
streaming, sitting on top of the real block device. Then enforce block
I/O limits on the virtual block device, the guest would remain accessing
the real block device.
That's an interesting idea. I have also experimented with rate-limiting
and it seems the common code is really small - the rate-limiting code is
quite short to begin with. So I'm now tending to reimplementing it.
Stefan
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi
i can prevent the EPERM failures of ioctl(SG_IO) by opening the
device file /dev/sg1 with O_RDWR rather than O_RDONLY.
In block/raw-posix.c:raw_open_common i implemented this hack:
printf(block/raw-posix.c: raw_open_common(\%s\, %x)\n,
filename, s-open_flags);
if (strncmp(filename, /dev/sg, 7) == 0) {
s-open_flags |= O_RDWR;
printf(block/raw-posix.c: /dev/sg hack: s-open_flags is now %x\n,
s-open_flags);
}
before
s-fd = -1;
fd = qemu_open(filename, s-open_flags, 0644);
This enables CD-RW burning.
Burning of DVD+RW still fails quite badly, though.
Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?
--
While booting the guest, i get these messages
block/raw-posix.c: raw_open_common(/dvdbuffer/i386-install.qemu, 1000)
block/raw-posix.c: raw_open_common(/dvdbuffer/i386-install.qemu, 1002)
block/raw-posix.c: raw_open_common(/dev/sg1, 1000)
block/raw-posix.c: /dev/sg hack: s-open_flags is now 1002
block/raw-posix.c: raw_open_common(/dev/sg1, 1000)
block/raw-posix.c: /dev/sg hack: s-open_flags is now 1002
block/raw-posix.c: raw_open_common(/dvdbuffer/pseudo_drive, 1000)
block/raw-posix.c: raw_open_common(/dvdbuffer/pseudo_drive, 1000)
The printf for failed ioctl is still present, but does not report
anymore:
posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno=
1
I dare to burn a DVD+RW
xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/include --
It blocks on
SET STREAMING
b6 00 00 00 00 00 00 00 00 00 1c 00
To drive: 28b
00 00 00 00 00 00 00 00 00 23 04 88 10 00 00 00 00 00 03 e8
10 00 00 00 00 00 03 e8
The guest system finally gets incommunicado, while the qemu process
on the host consumes 100 % CPU.
No further messages appear on the qemu start terminal.
After 10 minutes i issued on the host kill -9 to get rid of the qemu
process.
I can start it again, but it does not accept SSH connections but rather
lets the CPU glow at 100 %. It can be killed again.
I reboot the host.
Now qemu can boot the guest again.
I retry with with CD-RW (and thus no SET STREAMING)
It burns !
Afterwards i have one more session on the CD-RW.
Drive current: -dev '/dev/sr1'
Drive type : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
Media current: CD-RW
Media product: 97m15s35f/79m59s74f , Nan-Ya Plastics Corporation
Media status : is written , is appendable
Media blocks : 43153 readable , 309794 writable , 359847 overall
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 27633s , ISOIMAGE
ISO session : 2 , 39183 , 3818s , ISOIMAGE
Media summary: 2 sessions, 31753 data blocks, 62.0m data, 605m free
Media nwa: 50053s
I do a checkread with the MD5s of the single content files, which
were generated and recorded by xorriso option -for_backup:
$ xorriso -for_backup -dev /dev/sr1 -check_md5_r sorry / --
...
Media summary: 2 sessions, 31753 data blocks, 62.0m data, 605m free
Volume id: 'ISOIMAGE'
xorriso : UPDATE : 65536 content bytes read in 6 seconds
xorriso : UPDATE : 13931k content bytes read in 11 seconds
xorriso : UPDATE : 30202k content bytes read in 16 seconds
xorriso : UPDATE : 45284k content bytes read in 21 seconds
xorriso : UPDATE : 61991k content bytes read in 26 seconds
xorriso : UPDATE : 64692k content bytes read in 27 seconds
File contents and their MD5 checksums match.
Comparing ISO image content with hard disk content:
$ xorriso -dev /dev/sr1 -compare_r /usr/include /usr/include
...
xorriso : UPDATE : 6015501 content bytes read in 9 seconds
Both file objects match as far as expectable.
$
Whew !
-
Ok. But why does it fail with SET STREAMING ?
This will demand a completely new dive into the entrails of qemu.
Maybe not before tomorrow.
-
Above hack does not repair the timeouts with READ DISC STRUCTURE,
which i use to inquire DVD media.
The problematic commands are accompanied by this ioctl failure:
posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ),
ret= -1 , errno= 22
This is EINVAL /* Invalid argument */.
The debugging message appears as soon the SCSI command is attempted,
not waiting until the timeout finally snaps.
I verified once again on the host system, that the commands succeed.
They deliver large results:
READ DISC STRUCTURE
ad 00 00 00 00 00 00 04 08 04 00 00
From drive: 2052b
...
READ DISC STRUCTURE
ad 00 00 00 00 00 00 11 01 04 00 00
From drive: 260b
...
But the mere size cannot be the reason, because on the guest, the
third command succeeds with 2052 bytes of payload data (as on the host):
Re: [Qemu-devel] Multiple instances of Qemu on Windows multicore
On 03/11/2011 12:50, Paolo Bonzini wrote:
On 11/03/2011 11:29 AM, Avi Kivity wrote:
It would ensure that two mutators wouldn't run concurrently. In some
sense, signal-safe code could then be considered thread-safe too.
How so? The scheduler can switch between the two threads on every
instruction.
In general signal-safe is more stringent than thread-safe, but with two
exceptions: memory barriers and locked memory access. On x86 (implied by
Windows...) you might also assume that the compiler will generate arithmetic
operations with a memory destination, which makes code like
void cpu_interrupt(CPUState *env, int mask)
{
env-interrupt_request |= mask; /* --- this */
cpu_unlink_tb(env);
}
signal-safe in practice---and even thread-safe on non-SMP systems. It's a
huge assumption though, and I don't think it should be assumed anymore.
What can we do to improve that?
With iothread the architecture of the QEMU main loop is anyway completely
different.
Are you saying that things are better or worst with iothread?
--
Fabien Chouteau
Re: [Qemu-devel] Multiple instances of Qemu on Windows multicore
On 11/04/2011 10:27 AM, Fabien Chouteau wrote: It's a huge assumption though, and I don't think it should be assumed anymore. What can we do to improve that? Remove the affinity change and see what breaks. :) With iothread the architecture of the QEMU main loop is anyway completely different. Are you saying that things are better or worst with iothread? I think better. Without iothread, cpu_interrupt was called by qemu_notify_event. With iothread it is not. Perhaps that was the original problem with timers?... Paolo
[Qemu-devel] [PATCH] qxl: Slot sanity check in qxl_phys2virt() is off by one, fix
Spotted by Coverity. Signed-off-by: Markus Armbruster arm...@redhat.com --- hw/qxl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/qxl.c b/hw/qxl.c index 84ffd45..c97bebe 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -1006,7 +1006,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL pqxl, int group_id) case MEMSLOT_GROUP_HOST: return (void*)offset; case MEMSLOT_GROUP_GUEST: -PANIC_ON(slot NUM_MEMSLOTS); +PANIC_ON(slot = NUM_MEMSLOTS); PANIC_ON(!qxl-guest_slots[slot].active); PANIC_ON(offset qxl-guest_slots[slot].delta); offset -= qxl-guest_slots[slot].delta; -- 1.7.6.4
[Qemu-devel] [PATCH] console: Fix rendering of VGA underline
vga_putcharxy()'s underline code sets font_data to 0x instead of
0xff. vga_putcharxy() then reads dmask16[0x 4] and
dmask4[0x 6]. In practice, these out-of-bounds subscripts
only put a few crap bits into the display surface.
For 32 bit pixels, there's no array access. font_data's extra bits go
straight into the display surface.
Broken when commit 6d6f7c28 implemented underline.
Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/console.c b/console.c
index e43de92..f6fe441 100644
--- a/console.c
+++ b/console.c
@@ -467,7 +467,7 @@ static void vga_putcharxy(DisplayState *ds, int x, int y,
int ch,
font_data = *font_ptr++;
if (t_attrib-uline
((i == FONT_HEIGHT - 2) || (i == FONT_HEIGHT - 3))) {
-font_data = 0x;
+font_data = 0xFF;
}
((uint32_t *)d)[0] = (dmask16[(font_data 4)] xorcol) ^ bgcol;
((uint32_t *)d)[1] = (dmask16[(font_data 0) 0xf] xorcol) ^
bgcol;
@@ -480,7 +480,7 @@ static void vga_putcharxy(DisplayState *ds, int x, int y,
int ch,
font_data = *font_ptr++;
if (t_attrib-uline
((i == FONT_HEIGHT - 2) || (i == FONT_HEIGHT - 3))) {
-font_data = 0x;
+font_data = 0xFF;
}
((uint32_t *)d)[0] = (dmask4[(font_data 6)] xorcol) ^ bgcol;
((uint32_t *)d)[1] = (dmask4[(font_data 4) 3] xorcol) ^
bgcol;
@@ -493,7 +493,7 @@ static void vga_putcharxy(DisplayState *ds, int x, int y,
int ch,
for(i = 0; i FONT_HEIGHT; i++) {
font_data = *font_ptr++;
if (t_attrib-uline ((i == FONT_HEIGHT - 2) || (i ==
FONT_HEIGHT - 3))) {
-font_data = 0x;
+font_data = 0xFF;
}
((uint32_t *)d)[0] = (-((font_data 7)) xorcol) ^ bgcol;
((uint32_t *)d)[1] = (-((font_data 6) 1) xorcol) ^ bgcol;
--
1.7.6.4
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
On 11/04/2011 10:18 AM, Thomas Schmitt wrote:
Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?
I think the problem is that you're passing media=cdrom:
if (media == MEDIA_CDROM) {
/* CDROM is fine for any interface, don't check. */
ro = 1;
}
Just do not do that when using scsi-generic.
Paolo
Re: [Qemu-devel] [PATCH] block: Use bdrv functions to replace file operation in cow.c
Li Zhi Hui zhihu...@linux.vnet.ibm.com writes: Since common file operation functions lack of error detection, so change them to bdrv series functions. Looks like a few indentation fixes crept in as well. Best to keep such style cleanups well separated from functional changes.
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent
On 10/28/2011 02:17 PM, Paolo Bonzini wrote: Yes, it would be better if we could have error output on stderr. Now, simple errors such as a missing image file (or wrong path to the image) are reported to syslog instead. It could be the source of some headaches... Is there a way we could have the child send the error to the parent over a pipe and have the parent print it on stderr? A way could be to change the fork() into a separate thread, so that you can daemonize as soon as you accept the socket rather than having to do it early. I tried implementing this, but in general daemonization (which forks and leave only the children) breaks the threading. So we could either keep this series (which moves all errors to syslog, but doesn't otherwise change behavior), or I can finish and post an alternative series that removes all forking from qemu-nbd *but* changes behavior in that qemu-nbd -c will not daemonize anymore. Since this is 1.0 after all, I'm slightly more inclined towards the latter. Opinions? Kevin, Anthony? Paolo
Re: [Qemu-devel] GSoC mentor summit QEMU users session
On 04/11/2011 09:36, Stefan Hajnoczi wrote: On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote: On 03/11/2011 08:44, Stefan Hajnoczi wrote: On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau chout...@adacore.com wrote: On 29/10/2011 15:52, Alexander Graf wrote: I took a quick peak at the qemu-trace.[ch] from couverture and it looks along the lines of the instrumentation that others have been doing too. I hope you have time to propose the coverage instrumentation for upstream QEMU. I don't know much about other instrumentations in Qemu (pointers are welcome :), but what we have in couverture-qemu is not trivial, especially when it comes to MC/DC analysis. You should take a look at 201005-erts2.pdf if you want technical details. My impression was that the QEMU portion of instrumentation was fairly simple - it writes out trace records at various interesting points during guest execution in TCG. It's not rocket science but for MC/DC you have to log history of branches (taken or not), but if you record everything the output will unreasonably grow. I think fancy analysis scripts do not have to be part of QEMU but they could be added to scripts/ or put in a new contrib/ directory. What script are you talking about? GNATcoverage is far more complex than a fancy script :) On the train, can't access the PDF you mentioned right now. Can't you checkout the repository? -- Fabien Chouteau
Re: [Qemu-devel] [PATCH] block: Use bdrv functions to replace file operation in cow.c
On Fri, Nov 04, 2011 at 03:43:04PM +0800, Li Zhi Hui wrote: Since common file operation functions lack of error detection, so change them to bdrv series functions. Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com --- block/cow.c | 63 +- 1 files changed, 36 insertions(+), 27 deletions(-) Please always send separate patches for coding style/whitespace changes. Note that coding style changes are usually only worth it if you are going to modify that function. They make it harder for people trying to follow the source history or backport commits because they perturb code. I also suggest CCing Kevin Wolf kw...@redhat.com on any block layer changes because he is the block layer maintainer. It's a good idea to check ./MAINTAINERS before sending a patch so you know the right people to CC - it helps get their attention. Stefan
Re: [Qemu-devel] [v8 Patch 3/6]Qemu: Cmd block_set_hostcache for dynamic cache change
Am 30.10.2011 11:34, schrieb Supriya Kannery:
New command block_set_hostcache added for dynamically changing
host pagecache setting of a block device.
Usage:
block_set_hostcache device option
device = block device
option = on/off
Example:
(qemu) block_set_hostcache ide0-hd0 off
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
---
block.c | 54 ++
block.h |2 ++
blockdev.c | 26 ++
blockdev.h |2 ++
hmp-commands.hx | 14 ++
qmp-commands.hx | 27 +++
6 files changed, 125 insertions(+)
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -693,6 +693,34 @@ unlink_and_fail:
return ret;
}
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
+{
+BlockDriver *drv = bs-drv;
+int ret = 0, open_flags;
+
+/* Quiesce IO for the given block device */
+qemu_aio_flush();
+if (bdrv_flush(bs)) {
+qerror_report(QERR_DATA_SYNC_FAILED, bs-device_name);
+return ret;
ret is always 0. I think you wanted to return the return value of
bdrv_flush?
+}
+open_flags = bs-open_flags;
+bdrv_close(bs);
+
+ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
+if (ret 0) {
+/* Reopen failed. Try to open with original flags */
+qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
+ret = bdrv_open(bs, bs-filename, open_flags, drv);
+if (ret 0) {
+/* Reopen failed with orig and modified flags */
+abort();
+}
+}
+
+return ret;
+}
+
void bdrv_close(BlockDriverState *bs)
{
if (bs-drv) {
@@ -730,6 +758,32 @@ void bdrv_close_all(void)
}
}
+int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache)
+{
+int bdrv_flags = bs-open_flags;
+
+/* set hostcache flags (without changing WCE/flush bits) */
+if (enable_host_cache) {
+bdrv_flags = ~BDRV_O_NOCACHE;
+} else {
+bdrv_flags |= BDRV_O_NOCACHE;
+}
+
+/* If no change in flags, no need to reopen */
+if (bdrv_flags == bs-open_flags) {
+return 0;
+}
+
+if (bdrv_is_inserted(bs)) {
+/* Reopen file with changed set of flags */
+return bdrv_reopen(bs, bdrv_flags);
+} else {
+/* Save hostcache change for future use */
+bs-open_flags = bdrv_flags;
+return 0;
+}
Maybe the !bdrv_is_inserted() case should be handled in bdrv_reopen(). I
think it would be the same for changing other flags.
Kevin
Re: [Qemu-devel] [v8 Patch 5/6]Qemu: Framework for reopening images safely
Am 30.10.2011 11:35, schrieb Supriya Kannery:
Struct BDRVReopenState along with three reopen related functions
introduced for handling reopen state of images safely. This can be
extended by each of the block drivers to reopen respective
image files.
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
Index: qemu/block_int.h
===
--- qemu.orig/block_int.h
+++ qemu/block_int.h
@@ -55,6 +55,14 @@ struct BlockDriver {
int (*bdrv_probe)(const uint8_t *buf, int buf_size, const char
*filename);
int (*bdrv_probe_device)(const char *filename);
int (*bdrv_open)(BlockDriverState *bs, int flags);
+
+/* For handling image reopen for split or non-split files */
+int (*bdrv_reopen_prepare)(BlockDriverState *bs, BDRVReopenState **rs,
+ int flags);
+void (*bdrv_reopen_commit)(BlockDriverState *bs, BDRVReopenState *rs,
+ int flags);
+void (*bdrv_reopen_abort)(BlockDriverState *bs, BDRVReopenState *rs);
+
int (*bdrv_file_open)(BlockDriverState *bs, const char *filename, int
flags);
int (*bdrv_read)(BlockDriverState *bs, int64_t sector_num,
uint8_t *buf, int nb_sectors);
@@ -211,6 +219,14 @@ struct BlockDriverState {
void *private;
};
+struct BDRVReopenState {
+BlockDriverState *bs;
+int reopen_flags;
+
+/* For raw-posix */
+int reopen_fd;
+};
I think I commented the same on the previous version: BDRVReopenState
shouldn't contain any format specific fields. raw-posix must extend the
struct like this and use container_of() to get it from a BDRVReopenState
pointer:
struct BDRVRawReopenState {
BDRVReopenState common;
int reopen_fd;
};
Kevin
[Qemu-devel] [PATCH] readline: Fix buffer overrun on re-add to history
readline_hist_add() moves the history entry to the end of history. It
uses memmove() to move rs-history[idx + 1..] to rs-history[idx..].
However, its size argument is off by two array elements, so it writes
one element beyond rs-history[], and reads two.
On my system, this clobbers rs-hist_entry and the hole right after
it. Since the function assigns to rs-hist_entry in time, the bug has
no ill effects for me.
Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
readline.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/readline.c b/readline.c
index 6a3160a..a6c0039 100644
--- a/readline.c
+++ b/readline.c
@@ -236,7 +236,7 @@ static void readline_hist_add(ReadLineState *rs, const char
*cmdline)
new_entry = hist_entry;
/* Put this entry at the end of history */
memmove(rs-history[idx], rs-history[idx + 1],
- (READLINE_MAX_CMDS - idx + 1) * sizeof(char *));
+ (READLINE_MAX_CMDS - (idx + 1)) * sizeof(char *));
rs-history[READLINE_MAX_CMDS - 1] = NULL;
for (; idx READLINE_MAX_CMDS; idx++) {
if (rs-history[idx] == NULL)
--
1.7.6.4
Re: [Qemu-devel] [v8 Patch 6/6]Qemu: raw posix implementation of reopen functions
Am 30.10.2011 11:35, schrieb Supriya Kannery:
raw-posix driver changes for bdrv_reopen_xx functions to
safely reopen image files. Reopening of image files while
changing hostcache dynamically, is handled here.
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
Index: qemu/block/raw.c
===
--- qemu.orig/block/raw.c
+++ qemu/block/raw.c
@@ -9,6 +9,24 @@ static int raw_open(BlockDriverState *bs
return 0;
}
+static int raw_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs,
+ int flags)
+{
+return bdrv_reopen_prepare(bs-file, prs, flags);
+}
+
+static void raw_reopen_commit(BlockDriverState *bs, BDRVReopenState *rs,
+ int flags)
+{
+bdrv_reopen_commit(bs-file, rs, flags);
+bs-open_flags = bs-file-open_flags;
I think it should be bs-open_flags = flags, even if the underlying
driver masks something away (which it shouldn't do in the first place,
but using flags here is clearer).
Also I'm wondering if updating bs-open_flags isn't common to all
formats, so could we move it into the block.c function?
+}
+
+static void raw_reopen_abort(BlockDriverState *bs, BDRVReopenState *rs)
+{
+bdrv_reopen_abort(bs-file, rs);
+}
+
static int coroutine_fn raw_co_readv(BlockDriverState *bs, int64_t
sector_num,
int nb_sectors, QEMUIOVector *qiov)
{
@@ -107,7 +125,10 @@ static BlockDriver bdrv_raw = {
/* It's really 0, but we need to make g_malloc() happy */
.instance_size = 1,
-
+.bdrv_reopen_prepare
+= raw_reopen_prepare,
+.bdrv_reopen_commit = raw_reopen_commit,
+.bdrv_reopen_abort = raw_reopen_abort,
.bdrv_open = raw_open,
.bdrv_close = raw_close,
Mostly a matter of taste, but I would prefer open/close to stay first
and having bdrv_reopen_* only after them.
Index: qemu/block/raw-posix.c
===
--- qemu.orig/block/raw-posix.c
+++ qemu/block/raw-posix.c
@@ -279,6 +279,60 @@ static int raw_open(BlockDriverState *bs
return raw_open_common(bs, filename, flags, 0);
}
+static int raw_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs,
+ int flags)
+{
+BDRVReopenState *raw_rs = g_malloc0(sizeof(BDRVReopenState));
+BDRVRawState *s = bs-opaque;
+
+raw_rs-bs = bs;
+raw_rs-reopen_flags = s-open_flags;
+raw_rs-reopen_fd = -1;
+*prs = raw_rs;
+int ret = 0;
+
+/* If only O_DIRECT to be toggled, use fcntl */
+if (!((bs-open_flags ~BDRV_O_NOCACHE) ^
+(flags ~BDRV_O_NOCACHE))) {
Wouldn't it be more readable like this?
/* Use fcntl if all affected flags can be changes this way */
fcntl_flags = BDRV_O_NOCACHE;
if ((bs-open_flags ~fcntl_flags) == (flags ~fcntl_flags)) {
...
+raw_rs-reopen_fd = dup(s-fd);
+if (raw_rs-reopen_fd = 0) {
+return -1;
+}
+if ((flags BDRV_O_NOCACHE)) {
+raw_rs-reopen_flags |= O_DIRECT;
+} else {
+raw_rs-reopen_flags = ~O_DIRECT;
+}
+ret = fcntl_setfl(raw_rs-reopen_fd, raw_rs-reopen_flags);
+}
I think there should be an else branch that returns an error. Currently
requests involving anything but BDRV_O_NOCACHE are completely ignored,
but still success is returned.
+
+/* TBD: Handle O_DSYNC and other flags */
+
+return ret;
+}
Kevin
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent
Am 04.11.2011 10:46, schrieb Paolo Bonzini: On 10/28/2011 02:17 PM, Paolo Bonzini wrote: Yes, it would be better if we could have error output on stderr. Now, simple errors such as a missing image file (or wrong path to the image) are reported to syslog instead. It could be the source of some headaches... Is there a way we could have the child send the error to the parent over a pipe and have the parent print it on stderr? A way could be to change the fork() into a separate thread, so that you can daemonize as soon as you accept the socket rather than having to do it early. I tried implementing this, but in general daemonization (which forks and leave only the children) breaks the threading. So we could either keep this series (which moves all errors to syslog, but doesn't otherwise change behavior), or I can finish and post an alternative series that removes all forking from qemu-nbd *but* changes behavior in that qemu-nbd -c will not daemonize anymore. Since this is 1.0 after all, I'm slightly more inclined towards the latter. Opinions? Kevin, Anthony? I'm surprised that -c is what causes trouble. As far as I understand, the code for implementing -c doesn't use the qemu block layer at all. So why can't we just change the code to fork before it initialises the block layer and opens the image file? Kevin
[Qemu-devel] Windows 7 shutdown causes BSOD
Windows 7 32-bit guest blue screens when I shut it down properly with Start | Shut Down. The blue screen is only displayed for a split second before the guest reboots so I am not able to easily tell what it says. My guess is that Windows is triple-faulting or soft rebooting - note that I told Windows to shut down, not reboot. This issue happens on qemu.git/master (and Debian kvm 0.14.1+dfsg-3). Here is the QEMU command-line: x86_64-softmmu/qemu-system-x86_64 -L pc-bios -cpu qemu32 -enable-kvm -m 1024 -rtc base=localtime -drive file=win7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 Questions: Is anyone else experiencing this? Is anyone fixing this? If not I will play with it. Disabling ACPI might reveal the source of the problem. If that turns up nothing I will try to get the BSOD or WinDbg output. Stefan
Re: [Qemu-devel] [0/7] Remove unnecessary casts introduced by PCI DMA stubs series
Am 04.11.2011 02:03, schrieb David Gibson: As a few people pointed out, my recent patch series introducing a new (stub) PCI DMA API added unnecessary casts in quite a few places. I think this was a hangover from early days of the patchese where the casts were necessary for some reason I've now forgotten. Thanks for applying the series anyway, here is the requested followup series which removes those unnecessary casts. Whole series only removes casts, plus one reindentation in 2/7 at a line touched anyway. Looks okay for 1.0 if it compiles. Reviewed-by: Andreas Färber afaer...@suse.de Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] qmp: report TRAY_STATE_CHANGED events
On 11/01/2011 06:03 AM, ShaoHe Feng wrote:
after the guest startups, then I right click mouse in the UI of the
guest, and select the Eject from the menu.
there comes an event in the qmp-monitor.
{timestamp: {seconds: 1320118137, microseconds: 420150}, event:
TRAY_STATE_CHANGED, data: {device: ide0-cd1, state: open}}
however, if I change the cdrom by this command:
{ execute: change,arguments: { device: ide0-cd1, target:
/home/fsh/image/OCDC-natty-Test-Drive-20110823_010339.iso } }
there is no any event.
and { execute: eject, arguments: { device: ide0-cd1 } },
there is also no any event.
This was by design. The idea was that management can do the following
to change a CD when the guest keeps the medium locked and reacts to
eject requests (like very recent Linux does):
Scenario 1: non-forced media change
1. start looking at TRAY_STATE_CHANGED events
2. execute eject command
3. execute query-block
4. if disk is still shown as closed, check for guest reactions:
4.1. if no TRAY_STATE_CHANGED event has been reported since
step 1, wait until a TRAY_STATE_CHANGED event has arrived
4.2. if the TRAY_STATE_CHANGED event had state == closed, fail
5. execute change command
Scenario 2: forced media change
1. execute eject -f command (with the posted patches that
always unlock the tray upon eject -f)
2. execute change command
3. if it fails, restart
Paolo
Re: [Qemu-devel] [v8 Patch 1/6]Qemu: Enhance info block to display host cache setting
On 11/03/2011 07:25 PM, Luiz Capitulino wrote:
On Sun, 30 Oct 2011 16:03:54 +0530
Supriya Kannerysupri...@linux.vnet.ibm.com wrote:
+if (qdict_haskey(bs_dict, hostcache)) {
+monitor_printf(mon, hostcache=%d,
+ qdict_get_bool(bs_dict, hostcache));
+}
This series needs to be rebased, as the info block command has been
converted to the QAPI. Please, see the following commit for details:
b202381800d81fbff9978abbdea95760dd363bb6.
Also note that if you're adding new commands (I haven't reviewed the
series) you should use the QAPI. A document on how to use it is coming soon.
yes, will rebase and use QAPI
if (qdict_haskey(bs_dict, io-status)) {
monitor_printf(mon, io-status=%s, qdict_get_str(bs_dict,
io-status));
}
Re: [Qemu-devel] [v8 Patch 3/6]Qemu: Cmd block_set_hostcache for dynamic cache change
On 11/04/2011 03:30 PM, Kevin Wolf wrote:
Am 30.10.2011 11:34, schrieb Supriya Kannery:
+
+if (bdrv_is_inserted(bs)) {
+/* Reopen file with changed set of flags */
+return bdrv_reopen(bs, bdrv_flags);
+} else {
+/* Save hostcache change for future use */
+bs-open_flags = bdrv_flags;
+return 0;
+}
Maybe the !bdrv_is_inserted() case should be handled in bdrv_reopen(). I
think it would be the same for changing other flags.
I am yet to look at the conditions specific to other flags. So I can
move this check to bdrv_reopen when implementing one more flag I guess.
Kevin
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i wrote: Paolo: May i ask for the favor that you try to add O_RDWR to the qemu_open() call of passthrough devices ? Paolo Bonzini wrote: I think the problem is that you're passing media=cdrom: Just do not do that when using scsi-generic. The result looks promising, indeed. I disabled my hack but left the first printf active. Now i see at boot time block/raw-posix.c: raw_open_common(/dev/sg2, 1000) block/raw-posix.c: raw_open_common(/dev/sg2, 1002) and still no failing ioctls or sense code B 00 06. Burning to an appendable CD-RW in mode TAO still works. So thanks for this swift fulfilling of my wish. :)) --- Disappointment: CD-RW burning in mode SAO (on a blank medium) gets stuck at this command SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 After 200 seconds, the qemu process begins to use 100 % CPU, and the pacifier messages of xorriso stall. The guest is stuck. --- When i restart qemu and boot the guest without having rebooted the host, then after about 20 seconds, qemu is at 100 % CPU and no login is possible. There is a short time window after boot, where i can log in. The problem seems to sit in the host's drive /dev/sr1 which cannot be ejected or used by any program. They all get stuck. So it is likely that the ungraceful end of drive usage is to blame. I will tomorrow attach an USB drive to the machine and see whether re-powering it spares rebooting. (Linux USB is the best test bed for dangerous drive experiments.) --- So there are still two show stoppers. DVD+RW gets stuck at SET STREAMING. (I will hack libburn to avoid this command and check whether writing is possible then. Chances are good, as writing an already formatted DVD+RW is quite artless.) CD SAO gets stuck at SEND CUE SHEET. (SAO is possible with blank CDs only. It is desirable, because its results do not show the traditional read-ahead bug of Linux, which is caused by the two non-data sectors at the end of TAO tracks.) Do you have any hints where i should dig for the special processing of these commands, which obviously suffer timeout after 200 seconds, and then drive qemu or the guest into a busily unusable state ? There must be something about them in qemu. On the host they work flawlessly. Both send data, but so do SET CD SPEED, MODE SELECT(10), WRITE(10) which work fine on the guest. --- Have a nice day :) Thomas
Re: [Qemu-devel] [v8 Patch 5/6]Qemu: Framework for reopening images safely
On 11/04/2011 03:35 PM, Kevin Wolf wrote:
Am 30.10.2011 11:35, schrieb Supriya Kannery:
+struct BDRVReopenState {
+BlockDriverState *bs;
+int reopen_flags;
+
+/* For raw-posix */
+int reopen_fd;
+};
I think I commented the same on the previous version: BDRVReopenState
shouldn't contain any format specific fields. raw-posix must extend the
struct like this and use container_of() to get it from a BDRVReopenState
pointer:
struct BDRVRawReopenState {
BDRVReopenState common;
int reopen_fd;
};
I don't recall this was suggested in prev version or may be I missed to
notice..
ok, will have raw extending common BDRVReopenState struct.
Kevin
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent
On 11/04/2011 11:31 AM, Kevin Wolf wrote: I tried implementing this, but in general daemonization (which forks and leave only the children) breaks the threading. So we could either keep this series (which moves all errors to syslog, but doesn't otherwise change behavior), or I can finish and post an alternative series that removes all forking from qemu-nbd*but* changes behavior in that qemu-nbd -c will not daemonize anymore. Since this is 1.0 after all, I'm slightly more inclined towards the latter. Opinions? Kevin, Anthony? I'm surprised that -c is what causes trouble. As far as I understand, the code for implementing -c doesn't use the qemu block layer at all. -c causes qemu-nbd to fork (both to run the server in a child process, and to daemonize). The server runs in a child process, but that means that the server process loses the aio threads when the parent forks. So why can't we just change the code to fork before it initialises the block layer and opens the image file? That's exactly what this series did. However, daemonization has also to be done before opening the image file. So the series has to support reporting errors to syslog, and also qemu-nbd will not give a nonzero exit status when errors occur. Exchanging the server and client roles is also possible (i.e. put the server in the parent process and the client in the child). It fixes the problem that the thread pool is lost in the server process. However it still requires daemonization to occur before opening the image file so that errors cannot be reported properly. Paolo
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent
Am 04.11.2011 12:10, schrieb Paolo Bonzini: On 11/04/2011 11:31 AM, Kevin Wolf wrote: I tried implementing this, but in general daemonization (which forks and leave only the children) breaks the threading. So we could either keep this series (which moves all errors to syslog, but doesn't otherwise change behavior), or I can finish and post an alternative series that removes all forking from qemu-nbd*but* changes behavior in that qemu-nbd -c will not daemonize anymore. Since this is 1.0 after all, I'm slightly more inclined towards the latter. Opinions? Kevin, Anthony? I'm surprised that -c is what causes trouble. As far as I understand, the code for implementing -c doesn't use the qemu block layer at all. -c causes qemu-nbd to fork (both to run the server in a child process, and to daemonize). The server runs in a child process, but that means that the server process loses the aio threads when the parent forks. So why can't we just change the code to fork before it initialises the block layer and opens the image file? That's exactly what this series did. However, daemonization has also to be done before opening the image file. So the series has to support reporting errors to syslog, and also qemu-nbd will not give a nonzero exit status when errors occur. The parent could wait until the initialisation is done. As long as it runs, writing to stderr should just work, no? Or if that doesn't work, the child could use a pipe to communicate any errors to the parent in the startup phase and only after the initialisation has completed it would switch to using syslog. Exchanging the server and client roles is also possible (i.e. put the server in the parent process and the client in the child). It fixes the problem that the thread pool is lost in the server process. However it still requires daemonization to occur before opening the image file so that errors cannot be reported properly. Yes, this doesn't solve the problem. Kevin
Re: [Qemu-devel] Windows 7 shutdown causes BSOD
On Fri, Nov 4, 2011 at 10:48 AM, Stefan Hajnoczi stefa...@gmail.com wrote: Windows 7 32-bit guest blue screens when I shut it down properly with Start | Shut Down. The blue screen is only displayed for a split second before the guest reboots so I am not able to easily tell what it says. My guess is that Windows is triple-faulting or soft rebooting - note that I told Windows to shut down, not reboot. This issue happens on qemu.git/master (and Debian kvm 0.14.1+dfsg-3). Here is the QEMU command-line: x86_64-softmmu/qemu-system-x86_64 -L pc-bios -cpu qemu32 -enable-kvm -m 1024 -rtc base=localtime -drive file=win7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 Questions: Is anyone else experiencing this? Is anyone fixing this? If not I will play with it. Disabling ACPI might reveal the source of the problem. If that turns up nothing I will try to get the BSOD or WinDbg output. Thanks to Andreas Faerber and Michael Tokarev I found out the automatic reboot can be disabled in Windows. Here is the BSOD information: IRQL_NOT_LESS_OR_EQUAL STOP: 0x000A (0x,0x00FF,0x0001,0x828B7220) The rest of the BSOD is just generic text explaining there was a problem, not specific driver names are mentioned. Stefan
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent
On 11/04/2011 12:22 PM, Kevin Wolf wrote: That's exactly what this series did. However, daemonization has also to be done before opening the image file. So the series has to support reporting errors to syslog, and also qemu-nbd will not give a nonzero exit status when errors occur. The parent could wait until the initialisation is done. You need to daemonize first, then fork the server. If you fork the server before daemonizing, the server: 1) is not in its own process group, and still has a controlling TTY; 2) is not your child so your process structure is all broken, with the client and server being both child of PID 1; 3) is not your child, so you cannot reliably kill it (because if it has exited and PID 1 has already reaped it, you might kill a random process instead!). Paolo
Re: [Qemu-devel] [PATCH] reenable vm_clock when resuming all vcpus
On Fri, Nov 4, 2011 at 2:26 PM, Wen Congyang we...@cn.fujitsu.com wrote:
At 11/04/2011 10:48 AM, Zhi Yong Wu Write:
On Fri, Nov 4, 2011 at 10:45 AM, Wen Congyang we...@cn.fujitsu.com wrote:
We disable vm_clock when pausing all vcpus, but we forget to
reenable it when resuming all vcpus. It will cause that the
guest can not be rebooted.
Actually i also met this issue when rebooting the guest. When the
guest is rebooted, it will crash.
When I reboot the guest, it will hang.
Does this patch solve your problem?
Next Monday, i will do one simple testing for this.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
cpus.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpus.c b/cpus.c
index 6aff425..82530c4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -891,6 +891,7 @@ void resume_all_vcpus(void)
{
CPUState *penv = first_cpu;
+ qemu_clock_enable(vm_clock, true);
while (penv) {
penv-stop = 0;
penv-stopped = 0;
--
1.7.1
--
Regards,
Zhi Yong Wu
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
On 11/04/2011 12:09 PM, Thomas Schmitt wrote: So there are still two show stoppers. DVD+RW gets stuck at SET STREAMING. (I will hack libburn to avoid this command and check whether writing is possible then. Chances are good, as writing an already formatted DVD+RW is quite artless.) CD SAO gets stuck at SEND CUE SHEET. (SAO is possible with blank CDs only. It is desirable, because its results do not show the traditional read-ahead bug of Linux, which is caused by the two non-data sectors at the end of TAO tracks.) Is this okay to send to a blank CD with no prior command? That is, can I simply change your SEND CUE SHEET dump to sg_raw -s to reproduce? Do you have any hints where i should dig for the special processing of these commands, which obviously suffer timeout after 200 seconds, and then drive qemu or the guest into a busily unusable state ? There must be something about them in qemu. On the host they work flawlessly. Both send data, but so do SET CD SPEED, MODE SELECT(10), WRITE(10) which work fine on the guest. I wouldn't be surprised if they are bugs in either scsi-generic or the LSI emulation code. They seem to occur when commands return less data than the guest driver has asked; with master I get a guest oops in the LSI driver, while the host pads the return data with zeros. Your READ DISC STRUCTURE work for me with my (out-of-tree) vmw_pvscsi emulation. Paolo
Re: [Qemu-devel] GSoC mentor summit QEMU users session
On Fri, Nov 4, 2011 at 9:53 AM, Fabien Chouteau chout...@adacore.com wrote: On 04/11/2011 09:36, Stefan Hajnoczi wrote: On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote: On 03/11/2011 08:44, Stefan Hajnoczi wrote: On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau chout...@adacore.com wrote: On 29/10/2011 15:52, Alexander Graf wrote: I took a quick peak at the qemu-trace.[ch] from couverture and it looks along the lines of the instrumentation that others have been doing too. I hope you have time to propose the coverage instrumentation for upstream QEMU. I don't know much about other instrumentations in Qemu (pointers are welcome :), but what we have in couverture-qemu is not trivial, especially when it comes to MC/DC analysis. You should take a look at 201005-erts2.pdf if you want technical details. My impression was that the QEMU portion of instrumentation was fairly simple - it writes out trace records at various interesting points during guest execution in TCG. It's not rocket science but for MC/DC you have to log history of branches (taken or not), but if you record everything the output will unreasonably grow. I think fancy analysis scripts do not have to be part of QEMU but they could be added to scripts/ or put in a new contrib/ directory. What script are you talking about? GNATcoverage is far more complex than a fancy script :) I'm not up to speed on GNATcoverage or couverture, so apologies if I'm wrong - please let me know. Still, I think we're talking about the same thing here: http://www.adacore.com/home/products/gnatpro/add-on_technologies/gnatcoverage/ Looks like GNATemulator is QEMU with additional instrumentation. GNATcoverage takes the execution traces that the instrumented QEMU produced. So when I said fancy analysis scripts, I meant the tool that analyzes the trace. On the train, can't access the PDF you mentioned right now. Can't you checkout the repository? Sorry, I was reading/replying to mail offline. I now grabbed the git repo and looked at commit b82469c906829865693b4fad0edb0a069604a8d9, which I believe is the main change needed to add couverture tracing to QEMU. I'm trying to see if you want to send QEMU changes upstream? Stefan
Re: [Qemu-devel] [Xen-devel] [PATCH V3 10/13] libxl: libxl_qmp: Introduce libxl__qmp_pci_add.
Anthony PERARD writes ([Xen-devel] [PATCH V3 10/13] libxl: libxl_qmp: Introduce libxl__qmp_pci_add.): This function insert a PCI passthrough device in qemu. Thanks. I have applied 1-9 from this series. 13/13 had a conflict, and I wasn't 100% sure that it was right to apply it without 10,11,12, although it seems to me that it ought to be OK. Can you confirm, and respin the last patch (or the others) as appropriate ? Thanks, Ian.
[Qemu-devel] [Bug 809912] Re: qemu-kvm -m bigger 4096 aborts with 'Bad ram offset'
After updating from the QEMU that came with Ubuntu 11.04 to 070411-1ubuntu2 version, I am seeing the bad ram offset error, also. If I drop the memory for the guest (which is Windows 7 Pro 64-bit) from 4 GB to 3300MB, the error goes away. Host machine has an AMD Opteron 6128 with 32GB RAM and is running the 64 bit version of Ubuntu 11.04 updated to current versions as of November -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/809912 Title: qemu-kvm -m bigger 4096 aborts with 'Bad ram offset' Status in QEMU: New Bug description: When I try to start a virtual machine (x86_64 guest on a x86_64 host that has 32GB memory, using kvm_amd module, both host and guest running linux-2.6.39 kernels) with qemu-system-x86_64 -cpu host -smp 2 -m 4096 ..., shortly after the guest kernel starts, qemu aborts with a message Bad ram offset 11811c000. With e.g. -m 3500 (or lower), the virtual machine runs fine. I experience this both using qemu-kvm 0.14.1 and a recent version from git commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 Merge: d589310 75ef849 Author: Avi Kivity a...@redhat.com Date: Mon Jul 4 13:36:06 2011 +0300 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/809912/+subscriptions
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i wrote: CD SAO gets stuck at SEND CUE SHEET. Paolo Bonzini wrote: I wouldn't be surprised if they are bugs in either scsi-generic or the LSI emulation code. They seem to occur when commands return less data than the guest driver has asked; with master I get a guest oops in the LSI driver, while the host pads the return data with zeros. Your READ DISC STRUCTURE work for me with my (out-of-tree) vmw_pvscsi emulation. Please give me instructions for dummies when it is time to update my current slightly altered git clone, and to repeat my tests. (I have the disk space to create a completely new one, if this is desirable.) Is this okay to send to a blank CD with no prior command? That is, can I simply change your SEND CUE SHEET dump to sg_raw -s to reproduce? You will have to send a mode page 5 at least, which announces write mode SAO. See MMC-3 6.3.5. As usual, there is a 8 byte header, followed by the page. MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Then it should be ok to send SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 What would have come next: Above cue sheet promises to the drive, that 4023 * 2048 bytes will be written by WRITE(10) commands. It will stubbornly wait for all of them to come. (Maybe you know how to talk the host kernel into resetting it without rebooting.) The first write command would have been WRITE(10) 2a 00 ff ff ff 6a 00 00 10 00 with 32 kiB of payload data. The funny LBA -150 is the start of the pause track before the data track which starts at LBA 0. See the notes at the foot of MMC-3 table 281. From then on there would be consequtive WRITE(10) commands up to but not including LBA 3873 decimal. Finally libburn would have sent SYNCHRONIZE CACHE 35 02 00 00 00 00 00 00 00 00 and waited for the drive to become ready again. Just for reference: Below this point are only the complete SCSI logs of the real write run and of the drive inquiry which happend before that write attempt. The attempted write run consisted of these commands. The first mode page 5 (with TAO) is a result of libburn architecture. The second one orders SAO. SET CD SPEED bb 00 ff ff 06 e4 00 00 00 00 00 00 1552 ms MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 41 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 ms READ TRACK INFORMATION 52 01 00 00 00 ff 00 00 14 00 From drive: 20b 00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7 4 ms MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4 ms READ TRACK INFORMATION 52 01 00 00 00 ff 00 00 14 00 From drive: 20b 00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7 0 ms START/STOP UNIT 1b 01 00 00 01 00 64 ms TEST UNIT READY 00 00 00 00 00 00 0 ms START/STOP UNIT 1b 00 00 00 01 00 12 ms SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 This was the last command executed. After the sg_io_hdr.timeout had elapsed, i saw the increase of host CPU from 1 % to 100 %. Before these command there were several commands for drive and media inspection INQUIRY 12 00 00 00 24 00 From drive: 36b 05 80 05 32 5b 00 00 00 54 53 53 54 63 6f 72 70 43 44 44 56 44 57 20 53 48 2d 53 32 32 33 42 20 53 42 30 32 0 ms MODE SENSE 5a 00 2a 00 00 00 00 00 1e 00 From drive: 30b 00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00 08 00 16 0d 00 10 06 e4 06 e4 4 ms MODE SENSE 5a 00 2a 00 00 00 00 00 4c 00 From drive: 76b 00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00 08 00 16 0d 00 10 06 e4 06 e4 00 01 00 00 00 00 06 e4 00 01 00 00 06 e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4 ms GET CONFIGURATION 46 00 00 00 00 00 00 00 08 00 From drive: 8b 00 00 01 64 00 00 00 0a 20 ms GET CONFIGURATION 46 00 00 00 00 00 00 01 68 00 From drive: 360b 00 00 01 64 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00 00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 00 00 00 12 00 00
Re: [Qemu-devel] qemu ARM host support likely to be broken in 1.0
On 4 November 2011 07:53, Paolo Bonzini pbonz...@redhat.com wrote: On 11/04/2011 02:52 AM, Peter Maydell wrote: * the fixed address we mmap the code gen buffer to in system mode tends to overlap the libc heap (at least on Ubuntu oneiric); when this happens you typically get a sysmalloc abort Let's change this to use the .bss code gen buffer Does anybody know why we don't just use the .bss codegen buffer all the time for everything anyway? -- PMM
Re: [Qemu-devel] [PATCH] xen_disk: remove dead code
Am 28.10.2011 18:03, schrieb Paolo Bonzini: Xen_disk.c has support for using synchronous I/O instead of asynchronous, but it is compiled out by default. Remove it. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Thanks, applied for the block branch (for 1.1) Kevin
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi Thomas, Am 03.11.2011 23:30, schrieb Thomas Schmitt: I tried to activate DPRINTF in hw/scsi-generic.c by removing the // before #define DEBUG_SCSI make yields: .../hw/scsi-generic.c: In function 'scsi_send_command': .../hw/scsi-generic.c:286: error: 'lun' undeclared (first use in this function) .../hw/scsi-generic.c:286: error: 'tag' undeclared (first use in this function) We're about to release QEMU 1.0(-rc1) and you've just spotted a compilation issue... So i had to change in scsi_send_command(): - DPRINTF(Command: lun=%d tag=0x%x len %zd data=0x%02x, lun, tag, + DPRINTF(Command: len %zd data=0x%02x, You've solved this issue 50%! What's missing now is for you to put this fix into a self-contained patch (without the enabling of DEBUG_SCSI, etc.) and to submit it using the git-send-email command, so that your fix can be applied. :) http://wiki.qemu.org/Contribute/SubmitAPatch Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] docs: Add writing-qmp-commands.txt
On Thu, Nov 3, 2011 at 6:36 PM, Luiz Capitulino lcapitul...@redhat.com wrote:
+Here's the implementation of the 'hello-world' HMP command:
+
+void hmp_hello_world(Monitor *mon, const QDict *qdict)
+{
+ Error *errp = NULL;
+ const char *message = qdict_get_str(qdict, message);
Since message is optional this should be qdict_get_try_str().
Stefan
Re: [Qemu-devel] GSoC mentor summit QEMU users session
On 04/11/2011 13:04, Stefan Hajnoczi wrote: On Fri, Nov 4, 2011 at 9:53 AM, Fabien Chouteau chout...@adacore.com wrote: On 04/11/2011 09:36, Stefan Hajnoczi wrote: On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote: On 03/11/2011 08:44, Stefan Hajnoczi wrote: On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau chout...@adacore.com wrote: On 29/10/2011 15:52, Alexander Graf wrote: I took a quick peak at the qemu-trace.[ch] from couverture and it looks along the lines of the instrumentation that others have been doing too. I hope you have time to propose the coverage instrumentation for upstream QEMU. I don't know much about other instrumentations in Qemu (pointers are welcome :), but what we have in couverture-qemu is not trivial, especially when it comes to MC/DC analysis. You should take a look at 201005-erts2.pdf if you want technical details. My impression was that the QEMU portion of instrumentation was fairly simple - it writes out trace records at various interesting points during guest execution in TCG. It's not rocket science but for MC/DC you have to log history of branches (taken or not), but if you record everything the output will unreasonably grow. I think fancy analysis scripts do not have to be part of QEMU but they could be added to scripts/ or put in a new contrib/ directory. What script are you talking about? GNATcoverage is far more complex than a fancy script :) I'm not up to speed on GNATcoverage or couverture, so apologies if I'm wrong - please let me know. Still, I think we're talking about the same thing here: http://www.adacore.com/home/products/gnatpro/add-on_technologies/gnatcoverage/ Looks like GNATemulator is QEMU with additional instrumentation. GNATcoverage takes the execution traces that the instrumented QEMU produced. So when I said fancy analysis scripts, I meant the tool that analyzes the trace. In your previous message you seemed to say that GNATcoverage could be included in Qemu. I just wanted to explain that GNATcoverage is a project on its own and will not be a part of Qemu. On the train, can't access the PDF you mentioned right now. Can't you checkout the repository? Sorry, I was reading/replying to mail offline. I now grabbed the git repo and looked at commit b82469c906829865693b4fad0edb0a069604a8d9, which I believe is the main change needed to add couverture tracing to QEMU. Right this is the main commit, there are few others to fix corner cases. I'm trying to see if you want to send QEMU changes upstream? As I said it's in our plan, but we don't have time for now. You are welcome to help if you want to. -- Fabien Chouteau
[Qemu-devel] [Bug 886147] [NEW] Cannot make program Icon on my desktop with rightmouse key
Public bug reported: Howdy Xubuntu users How can I make a starter program Icon on my desktop with the mouse command right key. I do not seen the commands when I hit the right key of my mouse. Hope to see some info in my pigeon-hole. Spidey-Westland ** 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/886147 Title: Cannot make program Icon on my desktop with rightmouse key Status in QEMU: New Bug description: Howdy Xubuntu users How can I make a starter program Icon on my desktop with the mouse command right key. I do not seen the commands when I hit the right key of my mouse. Hope to see some info in my pigeon-hole. Spidey-Westland To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/886147/+subscriptions
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, We're about to release QEMU 1.0(-rc1) and you've just spotted a compilation issue... Maybe one should consider to obtain the missing information rather than crippling the debug message, like i did. You've solved this issue 50%! What's missing now is for you to put this fix into a self-contained patch (without the enabling of DEBUG_SCSI, etc.) and to submit it using the git-send-email command, so that your fix can be applied. :) Please bear with me. I'm a git noob, who does everything by try-and-error. It will be better for everybody, if this patch is generated by someone who knows what she or he is doing. I'm still dizzy from drilling a hole into the entrails of qemu and will have to learn about some compiler tricks which are not mentioned in my german copy of KR. Further, if i learn too much about qemu, then i will lose my naivity skills as unbiased tester. :)) Have a nice day :) Thomas
Re: [Qemu-devel] [Xen-devel] [PATCH V3 11/13] libxl: Use QMP to insert a passthrough device when using upstream QEMU
Anthony PERARD writes ([Xen-devel] [PATCH V3 11/13] libxl: Use QMP to insert a passthrough device when using upstream QEMU): Also move the xenstore specific code to a new function and add a message if sscanf fails. Thanks, following discussion I've applied 10,11 and will wait with 12 for the rebase of 13. Ian.
[Qemu-devel] How QEMU handle self-modifying code?
Hi, all While studying how QEMU handle self-modifying code I took [1] as an example. Running QEMU under GDB I found tb_invalidate_phys_page is called in two different call sequences: 1. do_syscall (linux-user/syscall.c) - target_mprotect (linux-user/mmap.c) - page_set_flags (exec.c) - tb_invalidate_phys_page (exec.c) 2. host_signal_handler (linux-user/signal.c) - cpu_x86_signal_handler (user-exec.c) - handle_cpu_signal (user-exec.c) - page_unprotect (exec.c) - tb_invalidate_phys_page (exec.c) Both eventually call tb_invalidate_phys_page. If a guest page is being modified, I think tb_invalidate_phys_page that page once is sufficient. But it's apparently not in practice. After doing some comparisons bwteen those two call sequences (see below), I can only guess this has something to do with TARGET_HAS_PRECISE_SMC. --- 1st call sequence --- #0 tb_invalidate_phys_page (addr=134512640, pc=0, puc=0x0) #1 page_set_flags (start=134512640, end=134516736, flags=31) --- --- 2nd call sequence --- #0 tb_invalidate_phys_page (addr=134512640, pc=1612947916, puc=0x7fffd080) #1 page_unprotect (address=134514145, pc=1612947916, puc=0x7fffd080) --- But what TARGET_HAS_PRECISE_SMC is? *If* we don't have to support TARGET_HAS_PRECISE_SMC, does it imply there is no need to call tb_invalidate_phys_page twice? Thanks! [1] http://web.archive.org/web/20080618094733/http://public.carnet.hr/~jbrecak/sm.html Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] [PATCH 1/7] nbd: treat EPIPE from NBD_DO_IT as success
This can be seen with qemu-nbd -v -c, which returns 1 instead of 0
when you disconnect with qemu-nbd -d.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
I think this is a bug (because there would be no way to exit
qemu-nbd with zero status!), but the patch can be left out safely.
nbd.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/nbd.c b/nbd.c
index fb5e424..e6c931c 100644
--- a/nbd.c
+++ b/nbd.c
@@ -425,6 +425,13 @@ int nbd_client(int fd)
TRACE(Doing NBD loop);
ret = ioctl(fd, NBD_DO_IT);
+if (ret == -1 errno == EPIPE) {
+/* NBD_DO_IT normally returns EPIPE when someone has disconnected
+ * the socket via NBD_DISCONNECT. We do not want to return 1 in
+ * that case.
+ */
+ret = 0;
+}
serrno = errno;
TRACE(NBD loop returned %d: %s, ret, strerror(serrno));
--
1.7.6.4
[Qemu-devel] [PATCH 2/7] qemu-nbd: trap SIGTERM
The client process right now uses SIGTERM to interrupt the server side.
This does not affect the exit status of qemu-nbd -v -c because the
server is a child process. This will change when both sides will be
in the same process, and anyway cleaning up things nicely upon SIGTERM
is good practice.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 34 +-
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index d8d3e15..d997bb0 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -36,6 +36,7 @@
#define NBD_BUFFER_SIZE (1024*1024)
+static int sigterm_wfd;
static int verbose;
static void usage(const char *name)
@@ -163,6 +164,14 @@ static int find_partition(BlockDriverState *bs, int
partition,
return -1;
}
+static void termsig_handler(int signum)
+{
+static int sigterm_reported;
+if (!sigterm_reported) {
+sigterm_reported = (write(sigterm_wfd, , 1) == 1);
+}
+}
+
static void show_parts(const char *device)
{
if (fork() == 0) {
@@ -231,6 +240,18 @@ int main(int argc, char **argv)
int max_fd;
int persistent = 0;
+/* Set up a SIGTERM handler so that we exit with a nice status code. */
+struct sigaction sa_sigterm;
+int sigterm_fd[2];
+if (qemu_pipe(sigterm_fd) == -1) {
+err(EXIT_FAILURE, Error setting up communication pipe);
+}
+
+sigterm_wfd = sigterm_fd[1];
+memset(sa_sigterm, 0, sizeof(sa_sigterm));
+sa_sigterm.sa_handler = termsig_handler;
+sigaction(SIGTERM, sa_sigterm, NULL);
+
while ((ch = getopt_long(argc, argv, sopt, lopt, opt_ind)) != -1) {
switch (ch) {
case 's':
@@ -423,7 +444,6 @@ int main(int argc, char **argv)
close(fd);
out:
kill(pid, SIGTERM);
-unlink(socket);
return ret;
}
@@ -444,18 +464,22 @@ int main(int argc, char **argv)
nb_fds++;
data = qemu_blockalign(bs, NBD_BUFFER_SIZE);
-if (data == NULL)
+if (data == NULL) {
errx(EXIT_FAILURE, Cannot allocate data buffer);
+}
do {
-
FD_ZERO(fds);
+FD_SET(sigterm_fd[0], fds);
for (i = 0; i nb_fds; i++)
FD_SET(sharing_fds[i], fds);
-ret = select(max_fd + 1, fds, NULL, NULL, NULL);
-if (ret == -1)
+do {
+ret = select(max_fd + 1, fds, NULL, NULL, NULL);
+} while (ret == -1 errno == EINTR);
+if (ret == -1 || FD_ISSET(sigterm_fd[0], fds)) {
break;
+}
if (FD_ISSET(sharing_fds[0], fds))
ret--;
--
1.7.6.4
[Qemu-devel] [PATCH 4/7] qemu-nbd: move client to a thread
This avoids that qemu-nbd uses both forking and threads, which do
not behave well together.
qemu-nbd is already Unix only, and there is no qemu_thread_join,
so for now use pthreads.
Since the parent and child no longer have separate file descriptors,
we can open the NBD device before daemonizing, instead of checking
with access(2) and restricting the open to the client only.
Reported-by: Pierre Riteau pierre.rit...@irisa.fr
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 175
1 files changed, 94 insertions(+), 81 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index ae504ec..515a657 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -31,6 +31,7 @@
#include arpa/inet.h
#include signal.h
#include libgen.h
+#include pthread.h
#define SOCKET_PATH/var/lock/qemu-nbd-%s
@@ -38,6 +39,9 @@
static int sigterm_wfd;
static int verbose;
+static char *device;
+static char *srcpath;
+static char *sockpath;
static void usage(const char *name)
{
@@ -172,21 +176,70 @@ static void termsig_handler(int signum)
}
}
-static void show_parts(const char *device)
+static void *show_parts(void *arg)
{
-if (fork() == 0) {
-int nbd;
+int nbd;
+
+/* linux just needs an open() to trigger
+ * the partition table update
+ * but remember to load the module with max_part != 0 :
+ * modprobe nbd max_part=63
+ */
+nbd = open(device, O_RDWR);
+if (nbd != -1) {
+close(nbd);
+}
+return NULL;
+}
-/* linux just needs an open() to trigger
- * the partition table update
- * but remember to load the module with max_part != 0 :
- * modprobe nbd max_part=63
- */
-nbd = open(device, O_RDWR);
-if (nbd != -1)
- close(nbd);
-exit(0);
+static void *nbd_client_thread(void *arg)
+{
+int fd = *(int *)arg;
+off_t size;
+size_t blocksize;
+uint32_t nbdflags;
+int sock;
+int ret;
+pthread_t show_parts_thread;
+
+do {
+sock = unix_socket_outgoing(sockpath);
+if (sock == -1) {
+if (errno != ENOENT errno != ECONNREFUSED) {
+goto out;
+}
+sleep(1); /* wait parent */
+}
+} while (sock == -1);
+
+ret = nbd_receive_negotiate(sock, NULL, nbdflags,
+size, blocksize);
+if (ret == -1) {
+goto out;
}
+
+ret = nbd_init(fd, sock, nbdflags, size, blocksize);
+if (ret == -1) {
+goto out;
+}
+
+/* update partition table */
+pthread_create(show_parts_thread, NULL, show_parts, NULL);
+
+fprintf(stderr, NBD device %s is now connected to %s\n,
+device, srcpath);
+
+ret = nbd_client(fd);
+if (ret) {
+goto out;
+}
+close(fd);
+kill(getpid(), SIGTERM);
+return (void *) EXIT_SUCCESS;
+
+out:
+kill(getpid(), SIGTERM);
+return (void *) EXIT_FAILURE;
}
int main(int argc, char **argv)
@@ -201,8 +253,6 @@ int main(int argc, char **argv)
struct sockaddr_in addr;
socklen_t addr_len = sizeof(addr);
off_t fd_size;
-char *device = NULL;
-char *sockpath = NULL;
const char *sopt = hVb:o:p:rsnP:c:dvk:e:t;
struct option lopt[] = {
{ help, 0, NULL, 'h' },
@@ -238,8 +288,11 @@ int main(int argc, char **argv)
int nb_fds = 0;
int max_fd;
int persistent = 0;
+pthread_t client_thread;
-/* Set up a SIGTERM handler so that we exit with a nice status code. */
+/* The client thread uses SIGTERM to interrupt the server. A signal
+ * handler ensures that qemu-nbd -v -c exits with a nice status code.
+ */
struct sigaction sa_sigterm;
int sigterm_fd[2];
if (qemu_pipe(sigterm_fd) == -1) {
@@ -356,9 +409,10 @@ int main(int argc, char **argv)
bs = bdrv_new(hda);
-if ((ret = bdrv_open(bs, argv[optind], flags, NULL)) 0) {
+srcpath = argv[optind];
+if ((ret = bdrv_open(bs, srcpath, flags, NULL)) 0) {
errno = -ret;
-err(EXIT_FAILURE, Failed to bdrv_open '%s', argv[optind]);
+err(EXIT_FAILURE, Failed to bdrv_open '%s', srcpath);
}
fd_size = bs-total_sectors * 512;
@@ -368,12 +422,14 @@ int main(int argc, char **argv)
err(EXIT_FAILURE, Could not find partition %d, partition);
if (device) {
-pid_t pid;
-int sock;
+int ret;
-/* want to fail before daemonizing */
-if (access(device, R_OK|W_OK) == -1) {
-err(EXIT_FAILURE, Could not access '%s', device);
+/* Open before spawning new threads. In the future, we may
+ * drop privileges after opening.
+ */
+fd = open(device, O_RDWR);
+if (fd == -1) {
+err(EXIT_FAILURE, Failed to open %s, device);
}
if (!verbose) {
@@ -388,64 +444,14 @@ int main(int argc, char **argv)
[Qemu-devel] [PATCH 7/7] qemu-nbd: open the block device after starting the client thread
This is cleaner, because we do not need to close the block device when
there is an error opening /dev/nbdX. It was done this way only to
print errors before daemonizing.
At the same time, use atexit to ensure that the block device is closed
whenever we exit.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 20fe4b5..c55b66a 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -464,22 +464,6 @@ int main(int argc, char **argv)
}
}
-bdrv_init();
-
-bs = bdrv_new(hda);
-
-srcpath = argv[optind];
-if ((ret = bdrv_open(bs, srcpath, flags, NULL)) 0) {
-errno = -ret;
-err(EXIT_FAILURE, Failed to bdrv_open '%s', srcpath);
-}
-
-fd_size = bs-total_sectors * 512;
-
-if (partition != -1
-find_partition(bs, partition, dev_offset, fd_size))
-err(EXIT_FAILURE, Could not find partition %d, partition);
-
if (device) {
/* Open before spawning new threads. In the future, we may
* drop privileges after opening.
@@ -495,6 +479,23 @@ int main(int argc, char **argv)
}
}
+bdrv_init();
+atexit(bdrv_close_all);
+
+bs = bdrv_new(hda);
+srcpath = argv[optind];
+if ((ret = bdrv_open(bs, srcpath, flags, NULL)) 0) {
+errno = -ret;
+err(EXIT_FAILURE, Failed to bdrv_open '%s', argv[optind]);
+}
+
+fd_size = bs-total_sectors * 512;
+
+if (partition != -1
+find_partition(bs, partition, dev_offset, fd_size)) {
+err(EXIT_FAILURE, Could not find partition %d, partition);
+}
+
sharing_fds = g_malloc((shared + 1) * sizeof(int));
if (sockpath) {
@@ -572,7 +573,6 @@ int main(int argc, char **argv)
qemu_vfree(data);
close(sharing_fds[0]);
-bdrv_close(bs);
g_free(sharing_fds);
if (sockpath) {
unlink(sockpath);
--
1.7.6.4
[Qemu-devel] [PATCH 3/7] qemu-nbd: rename socket variable
It will be moved to a global variable by the next patch, and it
would conflict with the socket function.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index d997bb0..ae504ec 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -202,8 +202,7 @@ int main(int argc, char **argv)
socklen_t addr_len = sizeof(addr);
off_t fd_size;
char *device = NULL;
-char *socket = NULL;
-char sockpath[128];
+char *sockpath = NULL;
const char *sopt = hVb:o:p:rsnP:c:dvk:e:t;
struct option lopt[] = {
{ help, 0, NULL, 'h' },
@@ -294,8 +293,8 @@ int main(int argc, char **argv)
errx(EXIT_FAILURE, Invalid partition %d, partition);
break;
case 'k':
-socket = optarg;
-if (socket[0] != '/')
+sockpath = optarg;
+if (sockpath[0] != '/')
errx(EXIT_FAILURE, socket path must be absolute\n);
break;
case 'd':
@@ -384,10 +383,9 @@ int main(int argc, char **argv)
}
}
-if (socket == NULL) {
-snprintf(sockpath, sizeof(sockpath), SOCKET_PATH,
- basename(device));
-socket = sockpath;
+if (sockpath == NULL) {
+sockpath = g_malloc(128);
+snprintf(sockpath, 128, SOCKET_PATH, basename(device));
}
pid = fork();
@@ -401,7 +399,7 @@ int main(int argc, char **argv)
bdrv_close(bs);
do {
-sock = unix_socket_outgoing(socket);
+sock = unix_socket_outgoing(sockpath);
if (sock == -1) {
if (errno != ENOENT errno != ECONNREFUSED) {
ret = 1;
@@ -452,8 +450,8 @@ int main(int argc, char **argv)
sharing_fds = g_malloc((shared + 1) * sizeof(int));
-if (socket) {
-sharing_fds[0] = unix_socket_incoming(socket);
+if (sockpath) {
+sharing_fds[0] = unix_socket_incoming(sockpath);
} else {
sharing_fds[0] = tcp_socket_incoming(bindto, port);
}
@@ -515,8 +513,9 @@ int main(int argc, char **argv)
close(sharing_fds[0]);
bdrv_close(bs);
g_free(sharing_fds);
-if (socket)
-unlink(socket);
+if (sockpath) {
+unlink(sockpath);
+}
return 0;
}
--
1.7.6.4
[Qemu-devel] [PATCH] xen-platform: Fix IO port read/write functions
Somehow, the read/write functions handle an offset that does not exist anymore.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
hw/xen_platform.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 6e3ba8b..5e792f5 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -113,7 +113,7 @@ static void platform_fixed_ioport_writew(void *opaque,
uint32_t addr, uint32_t v
{
PCIXenPlatformState *s = opaque;
-switch (addr - XEN_PLATFORM_IOPORT) {
+switch (addr) {
case 0:
/* Unplug devices. Value is a bitmask of which devices to
unplug, with bit 0 the IDE devices, bit 1 the network
@@ -152,7 +152,7 @@ static void platform_fixed_ioport_writew(void *opaque,
uint32_t addr, uint32_t v
static void platform_fixed_ioport_writel(void *opaque, uint32_t addr,
uint32_t val)
{
-switch (addr - XEN_PLATFORM_IOPORT) {
+switch (addr) {
case 0:
/* PV driver version */
break;
@@ -163,7 +163,7 @@ static void platform_fixed_ioport_writeb(void *opaque,
uint32_t addr, uint32_t v
{
PCIXenPlatformState *s = opaque;
-switch (addr - XEN_PLATFORM_IOPORT) {
+switch (addr) {
case 0: /* Platform flags */ {
hvmmem_type_t mem_type = (val PFFLAG_ROM_LOCK) ?
HVMMEM_ram_ro : HVMMEM_ram_rw;
@@ -186,7 +186,7 @@ static uint32_t platform_fixed_ioport_readw(void *opaque,
uint32_t addr)
{
PCIXenPlatformState *s = opaque;
-switch (addr - XEN_PLATFORM_IOPORT) {
+switch (addr) {
case 0:
if (s-drivers_blacklisted) {
/* The drivers will recognise this magic number and refuse
@@ -205,7 +205,7 @@ static uint32_t platform_fixed_ioport_readb(void *opaque,
uint32_t addr)
{
PCIXenPlatformState *s = opaque;
-switch (addr - XEN_PLATFORM_IOPORT) {
+switch (addr) {
case 0:
/* Platform flags */
return s-flags;
@@ -221,7 +221,7 @@ static void platform_fixed_ioport_reset(void *opaque)
{
PCIXenPlatformState *s = opaque;
-platform_fixed_ioport_writeb(s, XEN_PLATFORM_IOPORT, 0);
+platform_fixed_ioport_writeb(s, 0, 0);
}
const MemoryRegionPortio xen_platform_ioport[] = {
@@ -251,7 +251,7 @@ static void platform_fixed_ioport_init(PCIXenPlatformState*
s)
static uint32_t xen_platform_ioport_readb(void *opaque, uint32_t addr)
{
if (addr == 0) {
-return platform_fixed_ioport_readb(opaque, XEN_PLATFORM_IOPORT);
+return platform_fixed_ioport_readb(opaque, 0);
} else {
return ~0u;
}
@@ -263,7 +263,7 @@ static void xen_platform_ioport_writeb(void *opaque,
uint32_t addr, uint32_t val
switch (addr) {
case 0: /* Platform flags */
-platform_fixed_ioport_writeb(opaque, XEN_PLATFORM_IOPORT, val);
+platform_fixed_ioport_writeb(opaque, 0, val);
break;
case 8:
log_writeb(s, val);
@@ -321,7 +321,7 @@ static int xen_platform_post_load(void *opaque, int
version_id)
{
PCIXenPlatformState *s = opaque;
-platform_fixed_ioport_writeb(s, XEN_PLATFORM_IOPORT, s-flags);
+platform_fixed_ioport_writeb(s, 0, s-flags);
return 0;
}
--
tg: (47abe9a..) fix/pci-platform (depends on: master)
[Qemu-devel] [PATCH 6/7] qemu-nbd: fix socket creation race
Now that the client and server are in the same process, there is
no need to race on the creation of the socket. We can open the
listening socket before starting the client thread.
This avoids that qemu-nbd -v -c prints this once before connecting
successfully to the socket:
connect(unix:/var/lock/qemu-nbd-nbd0): No such file or directory
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 7490008..20fe4b5 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -204,10 +204,7 @@ static void *nbd_client_thread(void *arg)
do {
sock = unix_socket_outgoing(sockpath);
if (sock == -1) {
-if (errno != ENOENT errno != ECONNREFUSED) {
-goto out;
-}
-sleep(1); /* wait parent */
+goto out;
}
} while (sock == -1);
@@ -484,8 +481,6 @@ int main(int argc, char **argv)
err(EXIT_FAILURE, Could not find partition %d, partition);
if (device) {
-int ret;
-
/* Open before spawning new threads. In the future, we may
* drop privileges after opening.
*/
@@ -498,15 +493,6 @@ int main(int argc, char **argv)
sockpath = g_malloc(128);
snprintf(sockpath, 128, SOCKET_PATH, basename(device));
}
-
-ret = pthread_create(client_thread, NULL, nbd_client_thread, fd);
-if (ret != 0) {
-errx(EXIT_FAILURE, Failed to create client thread: %s,
- strerror(ret));
-}
-} else {
-/* Shut up GCC warnings. */
-memset(client_thread, 0, sizeof(client_thread));
}
sharing_fds = g_malloc((shared + 1) * sizeof(int));
@@ -519,6 +505,20 @@ int main(int argc, char **argv)
if (sharing_fds[0] == -1)
return 1;
+
+if (device) {
+int ret;
+
+ret = pthread_create(client_thread, NULL, nbd_client_thread, fd);
+if (ret != 0) {
+errx(EXIT_FAILURE, Failed to create client thread: %s,
+ strerror(ret));
+}
+} else {
+/* Shut up GCC warnings. */
+memset(client_thread, 0, sizeof(client_thread));
+}
+
max_fd = sharing_fds[0];
nb_fds++;
--
1.7.6.4
[Qemu-devel] [PATCH 0/7] reorganize operation of qemu-nbd -c and fix it
This is another approach to fixing the breakage of qemu-nbd -c due to mixing fork with threads. It switches operation of qemu-nbd to threads completely, with the exception of daemonization which is moved as early as possible to avoid conflicts with threads. Patches 1 and 2 are bugfixes to qemu-nbd, the first more or less unrelated, the second required by the rest of the patch. Patches 3 and 4 change qemu-nbd -c to operate within a single process. They are enough to fix the current breakage of qemu-nbd -c -v, but not enough for qemu-nbd -c. For that you need patch 5 too, which moves the daemonization to before the block layer is initialized. Patches 6 and 7 remove more warts that are now easily fixed. The patches are large, but unfortunately so is the breakage. Paolo Bonzini (7): nbd: treat EPIPE from NBD_DO_IT as success qemu-nbd: trap SIGTERM qemu-nbd: rename socket variable qemu-nbd: move client to a thread qemu-nbd: print error messages from the daemon through a pipe qemu-nbd: fix socket creation race condition qemu-nbd: open the block device after starting the client thread nbd.c |7 ++ qemu-nbd.c | 289 +++ 2 files changed, 194 insertions(+), 102 deletions(-) -- 1.7.6.4
[Qemu-devel] [PATCH 5/7] qemu-nbd: print error messages from the daemon through a pipe
In order to get nice error messages, keep the qemu-nbd process running
until before issuing NBD_DO_IT and connected to the daemon with a pipe.
This lets the qemu-nbd process relay error messages from the daemon and
exit with a nonzero status if appropriate.
Suggested-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-nbd.c | 68 +++---
1 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 515a657..7490008 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -225,8 +225,13 @@ static void *nbd_client_thread(void *arg)
/* update partition table */
pthread_create(show_parts_thread, NULL, show_parts, NULL);
-fprintf(stderr, NBD device %s is now connected to %s\n,
-device, srcpath);
+if (verbose) {
+fprintf(stderr, NBD device %s is now connected to %s\n,
+device, srcpath);
+} else {
+/* Close stderr so that the qemu-nbd process exits. */
+dup2(STDOUT_FILENO, STDERR_FILENO);
+}
ret = nbd_client(fd);
if (ret) {
@@ -405,6 +410,58 @@ int main(int argc, char **argv)
return 0;
}
+if (device !verbose) {
+int stderr_fd[2];
+pid_t pid;
+int ret;
+
+if (qemu_pipe(stderr_fd) == -1) {
+err(EXIT_FAILURE, Error setting up communication pipe);
+}
+
+/* Now daemonize, but keep a communication channel open to
+ * print errors and exit with the proper status code.
+ */
+pid = fork();
+if (pid == 0) {
+close(stderr_fd[0]);
+ret = qemu_daemon(0, 0);
+
+/* Temporarily redirect stderr to the parent's pipe... */
+dup2(stderr_fd[1], STDERR_FILENO);
+if (ret == -1) {
+err(EXIT_FAILURE, Failed to daemonize);
+}
+
+/* ... close the descriptor we inherited and go on. */
+close(stderr_fd[1]);
+} else {
+bool errors = false;
+char *buf;
+
+/* In the parent. Print error messages from the child until
+ * it closes the pipe.
+ */
+close(stderr_fd[1]);
+buf = g_malloc(1024);
+while ((ret = read(stderr_fd[0], buf, 1024)) 0) {
+errors = true;
+ret = qemu_write_full(STDERR_FILENO, buf, ret);
+if (ret == -1) {
+exit(EXIT_FAILURE);
+}
+}
+if (ret == -1) {
+err(EXIT_FAILURE, Cannot read from daemon);
+}
+
+/* Usually the daemon should not print any message.
+ * Exit with zero status in that case.
+ */
+exit(errors);
+}
+}
+
bdrv_init();
bs = bdrv_new(hda);
@@ -432,13 +494,6 @@ int main(int argc, char **argv)
err(EXIT_FAILURE, Failed to open %s, device);
}
-if (!verbose) {
-/* detach client and server */
-if (qemu_daemon(0, 0) == -1) {
-err(EXIT_FAILURE, Failed to daemonize);
-}
-}
-
if (sockpath == NULL) {
sockpath = g_malloc(128);
snprintf(sockpath, 128, SOCKET_PATH, basename(device));
--
1.7.6.4
Re: [Qemu-devel] GSoC mentor summit QEMU users session
On 03.11.2011, at 01:36, Andreas Färber wrote: Am 03.11.2011 08:46, schrieb Markus Armbruster: Anthony Liguori anth...@codemonkey.ws writes: For the record, I'm opposed to ever having a stable plugin API. We aren't a closed source product. If people [don't] want to have to keep up with our changing internal interfaces, they can get their code merged upstream. Seconded. Great. Then let's finally get megasas SCSI merged for 1.1. :) Yeah, and dictzip which was rejected because nobody except for us would use it... Alex
Re: [Qemu-devel] State of KVM guest debugging support on Power
On Thu, Nov 3, 2011 at 2:14 PM, Jan Kiszka jan.kis...@web.de wrote: On 2011-11-03 19:59, Stuart Yoder wrote: On Tue, Nov 1, 2011 at 9:22 AM, Jan Kiszka jan.kis...@web.de wrote: Hi there, I'm generating some slides on guest debugging via kvm. What's the current state for Book-E and Book-S? Works out of box, mostly usable, or to be implemented? Is anyone using it? Are you talking about guest debug using the QEMU stub or using the virtual CPU's debug registers and interrupts? For Freescale Book E we have both approaches working, and patches to be sent upstream soon. It's good to see both features coming into mainline. I'll talk about the former, ie. debugging without guest help/awareness (virtual hardware debugger). Is gdb well prepared for it (all registers available, real-mode support, etc.)? Right now it looks like the basic register set is available, not SPRs but not because of any gdb limitation as far as I know. gdb supports additional registers with the correct target description xml file passed back to it when it connects to the target. In the QEMU monitor, we currently show key SPRs for 'info registers'. As far as real mode goes, don't have direct experience with it as everything we are doing is bookE, which has no real mode. Stuart
[Qemu-devel] [Bug 885213] Re: Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
I forgot to add that my configure flags are
./configure --enable-linux-aio --enable-kvm
and that my CFLAGS are
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized
-Wall -pipe -mtune=native -march=native -fomit-frame-pointer -msse2
-msse -mmmx -mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 -Wpointer-arith
-Wstrict-prototypes -fstack-protector -Wstack-protector -Wextra -Wbad-
function-cast -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-
labels -Wfloat-equal -Wformat-nonliteral -Winline -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wundef -Wformat-
security
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/885213
Title:
Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
Status in QEMU:
New
Bug description:
The latest GIT version (e072ea2fd8fdceef64159b9596d3c15ce01bea91)
fails to compile.
Host: debian x86-64. gcc 4.6.2
...
CCcris-softmmu/pci-stub.o
...
In file included from /home/njh/src/qemu/hw/pci-stub.c:24:0:
./qmp-commands.h: At top level:
./qmp-commands.h:3:1: error: expected identifier or ‘(’ before ‘{’ token
.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/885213/+subscriptions
[Qemu-devel] [PATCH 6/6 v2] vvfat: reorganize computation of disk geometry
First determine FAT12/16/32, then compute geometry from that for both
FDD and HDD. For 1.44MB floppies, and 2.88MB floppies using FAT16,
change to 1 sector/cluster. The default remains 2.88MB with FAT12
and 2 sectors/cluster. Both DOS and mkdosfs by default format a 2.88MB
floppy as FAT12.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v1-v2: do not change default 2.88MB format to FAT16
block/vvfat.c | 38
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index faf2947..8511fe5 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -982,7 +982,6 @@ static int is_consistent(BDRVVVFATState *s);
static int vvfat_open(BlockDriverState *bs, const char* dirname, int flags)
{
BDRVVVFATState *s = bs-opaque;
-int floppy = 0;
int i;
#ifdef DEBUG
@@ -996,11 +995,8 @@ DLOG(if (stderr == NULL) {
s-bs = bs;
-s-fat_type=16;
/* LATER TODO: if FAT32, adjust */
s-sectors_per_cluster=0x10;
-/* 504MB disk*/
-bs-cyls=1024; bs-heads=16; bs-secs=63;
s-current_cluster=0x;
@@ -1015,14 +1011,6 @@ DLOG(if (stderr == NULL) {
if (!strstart(dirname, fat:, NULL))
return -1;
-if (strstr(dirname, :floppy:)) {
- floppy = 1;
- s-fat_type = 12;
- s-first_sectors_number = 1;
- s-sectors_per_cluster=2;
- bs-cyls = 80; bs-heads = 2; bs-secs = 36;
-}
-
if (strstr(dirname, :32:)) {
fprintf(stderr, Big fat greek warning: FAT32 has not been tested. You
are welcome to do so!\n);
s-fat_type = 32;
@@ -1030,7 +1018,27 @@ DLOG(if (stderr == NULL) {
s-fat_type = 16;
} else if (strstr(dirname, :12:)) {
s-fat_type = 12;
- bs-secs = 18;
+}
+
+if (strstr(dirname, :floppy:)) {
+ /* 1.44MB or 2.88MB floppy. 2.88MB can be FAT12 (default) or FAT16. */
+ if (!s-fat_type) {
+ s-fat_type = 12;
+ bs-secs = 36;
+ s-sectors_per_cluster=2;
+ } else {
+ bs-secs=(s-fat_type == 12 ? 18 : 36);
+ s-sectors_per_cluster=1;
+ }
+ s-first_sectors_number = 1;
+ bs-cyls=80; bs-heads=2;
+} else {
+ /* 32MB or 504MB disk*/
+ if (!s-fat_type) {
+ s-fat_type = 16;
+ }
+ bs-cyls=(s-fat_type == 12 ? 64 : 1024);
+ bs-heads=16; bs-secs=63;
}
s-sector_count=bs-cyls*bs-heads*bs-secs-(s-first_sectors_number-1);
@@ -1058,10 +1066,10 @@ DLOG(if (stderr == NULL) {
if(s-first_sectors_number==0x40)
init_mbr(s);
-
-/* for some reason or other, MS-DOS does not like to know about CHS... */
-if (floppy)
+else {
+/* MS-DOS does not like to know about CHS (?). */
bs-heads = bs-cyls = bs-secs = 0;
+}
//assert(is_consistent(s));
qemu_co_mutex_init(s-lock);
--
1.7.6.4
Re: [Qemu-devel] [RFC PATCH 00/11] qemu_fclose() error handling fixes
On Tue, 1 Nov 2011 17:20:19 -0200, Eduardo Habkost ehabk...@redhat.com wrote: Summary of the problem: - qemu_fclose() calls qemu_fflush() - Writes done by qemu_fflush() can fail - Those errors are lost after qemu_fclose() returns So, this series change qemu_fclose() to return last_error. But to do that we need to make sure all involve code use the -errno convention, hence the large series. Michael, probably this will conflict with your ongoing work. I don't want to delay other work, so I can rebase my patches if needed. This is just a RFC. No worries, my stuff is probably a ways off whereas this is likely a candidate for 1.0 or a follow-up stable revision. Plus I've gotten pretty used to working through QEMUFile-related merge conflicts as of late :) Still reviewing, but series looks good so far (other than 6) Juan, maybe you were already working on this. But as I was already fixing this code while auditing the migration handling, I thought it was interesting to send this for review anyway. I hope I didn't duplicate any work. This is still completely untested, I am just using this series as a way to report the issue and get comments so I know I am going through the right path. Detailed description of the changes: Small cleanups: - Always use qemu_file_set_error() to set last_error (patch 1) - Add return value documentation to QEMUFileCloseFunc (patch 2) Actual qemu_fclose() behavior changes are done in 3 steps: - First step: fix qemu_fclose() callers: - exec_close() - Fixed to check for negative values, not -1 (patch 3) - Note: exec_close() is changed in two steps: first on the qemu_fclose() calling code, then on the return value code - migrate_fd_cleanup - Fixed to: - check qemu_fclose() return value for 0 (patch 4) - return -errno, not just -1 (patch 4) - Callers: - migrate_fd_completed: - Error checking is done properly, already. - migrate_fd_error: - It ignores migrated_fd_cleanup() return value. - migrate_fd_cancel: - It ignores migrated_fd_cleanup() return value. - exec_accept_incoming_migration(): no return value check (yet) - fd_accept_incoming_migration(): no return value check (yet) - tcp_accept_incoming_migration(): no return value check (yet) - unix_accept_incoming_migration(): no return value check (yet) - do_savevm(): no return value check (yet) - load_vmstate(): no return value check (yet) - Second step: change qemu_fclose() to return last_error (patch 5) - Made sure to return unchanged (positive) success value on success (required by exec_close()) - Third step: change qemu_fclose() implementations (QEMUFileCloseFunc): - stdio_fclose - Fixed to return -errno (patch 6) - stdio_pclose - Fixed to return -errno (patch 7) - buffered_close - Implemented through QEMUFileBuffered.close: - Only implementation is migrate_fd_close(), that calls the following, through MigrationState.close: - exec_close(): - fixed to return original error value, not -1 (patch 8) - fd_close - Fixed to return -errno on close() errors. (patch 9) - tcp_close - Fixed to return -errno on close() errors. (patch 10) - unix_close - Fixed to return -errno on close() errors. (patch 11) - socket_close - No system call is made, returns always 0. - bdrv_fclose - No system call is made, returns always 0. Eduardo Habkost (11): savevm: use qemu_file_set_error() instead of setting last_error directly QEMUFileCloseFunc: add return value documentation exec_close(): accept any negative value as qemu_fclose() error migrate_fd_cleanup: accept any negative qemu_fclose() value as error qemu_fclose: return last_error if set stdio_pclose: return -errno on error stdio_fclose: return -errno on errors exec_close(): return -errno on errors fd_close(): check for close() errors too tcp_close(): check for close() errors too unix_close(): check for close() errors too hw/hw.h |8 ++- migration-exec.c |9 ++- migration-fd.c |6 +++- migration-tcp.c |6 +++- migration-unix.c |6 +++- migration.c |4 +-- savevm.c | 61 ++ 7 files changed, 75 insertions(+), 25 deletions(-) -- 1.7.3.2 -- Sincerely, Mike Roth IBM Linux Technology Center
Re: [Qemu-devel] [PATCH 6/6 v2] vvfat: reorganize computation of disk geometry
Am 04.11.2011 17:21, schrieb Paolo Bonzini: First determine FAT12/16/32, then compute geometry from that for both FDD and HDD. For 1.44MB floppies, and 2.88MB floppies using FAT16, change to 1 sector/cluster. The default remains 2.88MB with FAT12 and 2 sectors/cluster. Both DOS and mkdosfs by default format a 2.88MB floppy as FAT12. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- v1-v2: do not change default 2.88MB format to FAT16 Thanks, applied all to the block-stable branch (for 1.0). Kevin
[Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
Hi guys,
As we understand that qemu is approaching 1.0, we think it's a good idea
to share the issues we have been seeing on recent qemu.git sanity jobs:
1) Some condition is consistently making a RHEL 6.1 linux guest not able
to bring up the network interface, causing login failures for all linux
guest tests. This very same guest install works perfectly on qemu-kvm,
RHEL 5 and RHEL 6.
2) The floppy regression problem which was reported some days ago on
this mailing list still happens, Kevin did post a patch that resolves it
diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..1d3b6f1 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,13 @@ static void DMA_run (void)
struct dma_cont *d;
int icont, ichan;
int rearm = 0;
+static int running = 0;
+
+if (running) {
+goto out;
+} else {
+running = 1;
+}
d = dma_controllers;
@@ -374,6 +381,8 @@ static void DMA_run (void)
}
}
+out:
+running = 0;
if (rearm)
qemu_bh_schedule_idle(dma_bh);
}
But still wasn't integrated upstream. As I understand, there are doubts
whether this is a proper fix. Works with qemu-kvm.git. RHEL 5 and RHEL 6.
3) With Kevin's patch applied, windows install goes on until the first
reboot. When it gets there, it gets stuck on the BIOS screen. The bios
being used is the bin shipped on qemu.git's repo. So the install does
not complete. Works with qemu-kvm.git, RHEL 5 and RHEL 6.
Those were the issues found on our 'sanity' job, which is the closest to
a smoke test we have with KVM autotest. It simply installs one stable
and recent linux guest, boot, simple migration, reboot, shutdown, rinse
and repeat with the latest windows guest available. All guests use
virtio disks and virtio network cards. It has 100% PASS rate, or very
close to it for the other branches mentioned.
So qemu.git current state is not good, and those bugs need some work
before 1.0 is out.
Please feel free to approach myself and Cleber on irc or email, as we
can give you the details we have available, in case you need them.
Lucas
Re: [Qemu-devel] [RFC] docs: Add writing-qmp-commands.txt
On Thu, 3 Nov 2011 22:50:29 +0200
Alon Levy al...@redhat.com wrote:
On Thu, Nov 03, 2011 at 04:36:03PM -0200, Luiz Capitulino wrote:
Explains how to write QMP commands using the QAPI.
TODO:
- write returning lists chapter
- review it
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
This is incomplete, but I figured I should send it anyway as there are
people
who want to add new QMP commands but are still using the old interface.
Review
is really appreciated.
docs/writing-qmp-commands.txt | 488
+
1 files changed, 488 insertions(+), 0 deletions(-)
create mode 100644 docs/writing-qmp-commands.txt
diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
new file mode 100644
index 000..26c8d15
--- /dev/null
+++ b/docs/writing-qmp-commands.txt
@@ -0,0 +1,488 @@
+= How to write QMP commands using the QAPI framework =
+
+This document is a step-by-step guide on how to write new QMP commands
using
+the QAPI framework. It also shows how to implement new style HMP commands,
+which do QMP calls.
+
+This document doesn't discuss QMP protocol level details, nor does it dive
+into the QAPI framework implementation.
+
+For an in-depth introduction to the QAPI framework, please refer to
+docs/qapi-code-gen.txt. For documentation about the QMP protocol, please
+check the files in QMP/.
+
+== Overview ==
+
+Generally speaking, the following steps should be taken in order to write a
+new QMP command.
+
+1. Write the command and type(s) specification in the QAPI schema file
+ (qapi-schema.json in the root directory)
+
+2. Write the QMP command itself, which is a regular C function. Preferably,
+ the command should be exported by some QEMU subsystem. But it can also
be
+ added to the qmp.c file
+
+3. At this point the command can be tested under the QMP protocol
+
+4. Write the HMP command equivalent. This is not required and should only
be
+ done if it does make sense to have the functionality in HMP. The HMP
command
+ is implemented in terms of the QMP command
+
+The following sections will demonstrate each of the steps above. We will
start
+very simple and get more complex as we progress.
+
+=== Testing ===
+
+For all the commands implementations in the next sections, the test setup
is
+the same and is shown here.
+
+First, QEMU should be started as:
+
+# /path/to/your/source/qemu [...] \
+-chardev socket,id=qmp,port=,host=localhost,server \
+-mon chardev=qmp,mode=control,pretty=on
+
+Then, in a different terminal:
+
+$ telnet localhost
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+{
+QMP: {
+version: {
+qemu: {
+micro: 50,
+minor: 15,
+major: 0
+},
+package:
+},
+capabilities: [
+]
+}
+}
+
+The above output is the QMP server saying you're connected. The server is
+actually in capabilities negotiation mode. To enter in command mode type:
+
+{ execute: qmp_capabilities }
+
+Then the server should respond:
+
+{
+return: {
+}
+}
+
+Which is QMP way of saying the latest command executed OK and didn't
return
+any data. Now you're ready to enter the QMP example commands as suggested
+in the following sections.
+
+== Writing a command that doesn't return data ==
+
+That's the most simple QMP command that can be written. Usually, this kind
of
+command carries some meaningful action in QEMU but here it will just print
+'Hello, world' to the standard output.
+
+Our command will be called 'hello-world'. It takes no arguments, nor does
it
+return any data.
+
+The first step is to add the following line to the bottom of the
+qapi-schema.json file:
+
+{ 'command': 'hello-world' }
+
+This will instruct the QAPI to generate any prototypes and the necessary
code
+to marshal and unmarshal protocol data.
+
+The next step is to write the 'hello-world' implementation. As explained
+earlier, it's preferable for commands to live in QEMU subsystems. But
+'hello-world' doesn't pertain to any, so we add this to qmp.c:
+
+void qmp_hello_world(Error **errp)
+{
+printf(Hello, world!\n);
+}
+
+There are a few things to be noted:
+
+1. QMP command implementation functions must be prefixed with qmp_
+2. qmp_hello_world() returns void, this is in accordance with the fact
that the
+ command doesn't return any data
+3. It takes an 'Error **' argument. This is required. Later we will see
how to
+ return errors and take additional arguments. The Error argument should
not
+ be touched if the command doesn't return errors
+4. We won't add the function's
Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
Am 04.11.2011 17:40, schrieb Lucas Meneghel Rodrigues:
2) The floppy regression problem which was reported some days ago on
this mailing list still happens, Kevin did post a patch that resolves it
[...]
But still wasn't integrated upstream. As I understand, there are doubts
whether this is a proper fix. Works with qemu-kvm.git. RHEL 5 and RHEL 6.
The first patch was buggy (even though it seemed to do the trick in most
cases), but I do have a new version queued for my next pull request.
In case you like to test it before it gets merged, this is the new version:
diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..0a9322d 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,14 @@ static void DMA_run (void)
struct dma_cont *d;
int icont, ichan;
int rearm = 0;
+static int running = 0;
+
+if (running) {
+rearm = 1;
+goto out;
+} else {
+running = 1;
+}
d = dma_controllers;
@@ -374,6 +382,8 @@ static void DMA_run (void)
}
}
+running = 0;
+out:
if (rearm)
qemu_bh_schedule_idle(dma_bh);
}
Kevin
Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
On Fri 04 Nov 2011 02:50:53 PM BRST, Kevin Wolf wrote:
Am 04.11.2011 17:40, schrieb Lucas Meneghel Rodrigues:
2) The floppy regression problem which was reported some days ago on
this mailing list still happens, Kevin did post a patch that resolves it
[...]
But still wasn't integrated upstream. As I understand, there are doubts
whether this is a proper fix. Works with qemu-kvm.git. RHEL 5 and RHEL 6.
The first patch was buggy (even though it seemed to do the trick in most
cases), but I do have a new version queued for my next pull request.
In case you like to test it before it gets merged, this is the new version:
diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..0a9322d 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,14 @@ static void DMA_run (void)
struct dma_cont *d;
int icont, ichan;
int rearm = 0;
+static int running = 0;
+
+if (running) {
+rearm = 1;
+goto out;
+} else {
+running = 1;
+}
d = dma_controllers;
@@ -374,6 +382,8 @@ static void DMA_run (void)
}
}
+running = 0;
+out:
if (rearm)
qemu_bh_schedule_idle(dma_bh);
}
Kevin
Ok, we'll put it on our off tree patch stash for the next upstream jobs
[1], thanks. We still have the bios problem to finally get a working
windows install, I hope people might look into this.
[1] Well, currently this is the only patch on our 'stash', we only
resort to external patches on blockers like this one.
Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
On 11/04/2011 11:40 AM, Lucas Meneghel Rodrigues wrote: Hi guys, As we understand that qemu is approaching 1.0, we think it's a good idea to share the issues we have been seeing on recent qemu.git sanity jobs: 1) Some condition is consistently making a RHEL 6.1 linux guest not able to bring up the network interface, causing login failures for all linux guest tests. This very same guest install works perfectly on qemu-kvm, RHEL 5 and RHEL 6. Can you file a bug report with specific information about how the guest is being launched? Specifically, what NIC are we talking about? Do other types of guests work? Regards, Anthony Liguori
Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
On Fri 04 Nov 2011 02:56:30 PM BRST, Anthony Liguori wrote: On 11/04/2011 11:40 AM, Lucas Meneghel Rodrigues wrote: Hi guys, As we understand that qemu is approaching 1.0, we think it's a good idea to share the issues we have been seeing on recent qemu.git sanity jobs: 1) Some condition is consistently making a RHEL 6.1 linux guest not able to bring up the network interface, causing login failures for all linux guest tests. This very same guest install works perfectly on qemu-kvm, RHEL 5 and RHEL 6. Can you file a bug report with specific information about how the guest is being launched? Specifically, what NIC are we talking about? Do other types of guests work? Ok, I will. Just FYI, it's a virtio nic. As on sanity jobs we only test RHEL 6.1 64 bit and Windows 7 SP1 64 bit, and Windows is blocked due to the other bug mentioned, I still have no idea whether other guests do work.
Re: [Qemu-devel] [RFC] docs: Add writing-qmp-commands.txt
On Thu, 03 Nov 2011 16:25:58 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
On 11/03/2011 01:36 PM, Luiz Capitulino wrote:
Explains how to write QMP commands using the QAPI.
TODO:
- write returning lists chapter
- review it
Signed-off-by: Luiz Capitulinolcapitul...@redhat.com
---
This is incomplete, but I figured I should send it anyway as there are
people
who want to add new QMP commands but are still using the old interface.
Review
is really appreciated.
docs/writing-qmp-commands.txt | 488
+
1 files changed, 488 insertions(+), 0 deletions(-)
create mode 100644 docs/writing-qmp-commands.txt
diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
new file mode 100644
index 000..26c8d15
--- /dev/null
+++ b/docs/writing-qmp-commands.txt
@@ -0,0 +1,488 @@
+= How to write QMP commands using the QAPI framework =
+
+This document is a step-by-step guide on how to write new QMP commands
using
+the QAPI framework. It also shows how to implement new style HMP commands,
+which do QMP calls.
+
+This document doesn't discuss QMP protocol level details, nor does it dive
+into the QAPI framework implementation.
+
+For an in-depth introduction to the QAPI framework, please refer to
+docs/qapi-code-gen.txt. For documentation about the QMP protocol, please
+check the files in QMP/.
+
+== Overview ==
+
+Generally speaking, the following steps should be taken in order to write a
+new QMP command.
+
+1. Write the command and type(s) specification in the QAPI schema file
+ (qapi-schema.json in the root directory)
+
+2. Write the QMP command itself, which is a regular C function. Preferably,
+ the command should be exported by some QEMU subsystem. But it can also
be
+ added to the qmp.c file
+
+3. At this point the command can be tested under the QMP protocol
+
+4. Write the HMP command equivalent. This is not required and should only
be
+ done if it does make sense to have the functionality in HMP. The HMP
command
+ is implemented in terms of the QMP command
+
+The following sections will demonstrate each of the steps above. We will
start
+very simple and get more complex as we progress.
+
+=== Testing ===
+
+For all the commands implementations in the next sections, the test setup
is
+the same and is shown here.
+
+First, QEMU should be started as:
+
+# /path/to/your/source/qemu [...] \
+-chardev socket,id=qmp,port=,host=localhost,server \
+-mon chardev=qmp,mode=control,pretty=on
+
+Then, in a different terminal:
+
+$ telnet localhost
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+{
+QMP: {
+version: {
+qemu: {
+micro: 50,
+minor: 15,
+major: 0
+},
+package:
+},
+capabilities: [
+]
+}
+}
+
+The above output is the QMP server saying you're connected. The server is
+actually in capabilities negotiation mode. To enter in command mode type:
+
+{ execute: qmp_capabilities }
+
+Then the server should respond:
+
+{
+return: {
+}
+}
+
+Which is QMP way of saying the latest command executed OK and didn't
return
+any data. Now you're ready to enter the QMP example commands as suggested
+in the following sections.
+
+== Writing a command that doesn't return data ==
+
+That's the most simple QMP command that can be written. Usually, this kind
of
+command carries some meaningful action in QEMU but here it will just print
+'Hello, world' to the standard output.
+
+Our command will be called 'hello-world'. It takes no arguments, nor does
it
+return any data.
+
+The first step is to add the following line to the bottom of the
+qapi-schema.json file:
+
+{ 'command': 'hello-world' }
+
+This will instruct the QAPI to generate any prototypes and the necessary
code
+to marshal and unmarshal protocol data.
+
+The next step is to write the 'hello-world' implementation. As explained
+earlier, it's preferable for commands to live in QEMU subsystems. But
+'hello-world' doesn't pertain to any, so we add this to qmp.c:
+
+void qmp_hello_world(Error **errp)
+{
+printf(Hello, world!\n);
+}
+
+There are a few things to be noted:
+
+1. QMP command implementation functions must be prefixed with qmp_
+2. qmp_hello_world() returns void, this is in accordance with the fact
that the
+ command doesn't return any data
+3. It takes an 'Error **' argument. This is required. Later we will see
how to
+ return errors and take additional arguments. The Error argument should
not
+ be touched if the command doesn't return errors
+4. We won't add the function's prototype.
Re: [Qemu-devel] [RFC] docs: Add writing-qmp-commands.txt
On Fri, 4 Nov 2011 14:03:47 +
Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Nov 3, 2011 at 6:36 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
+Here's the implementation of the 'hello-world' HMP command:
+
+void hmp_hello_world(Monitor *mon, const QDict *qdict)
+{
+ Error *errp = NULL;
+ const char *message = qdict_get_str(qdict, message);
Since message is optional this should be qdict_get_try_str().
Good catch. That was my first version (and I did get an abort() there),
but forgot to fix it in the doc.
Thanks.
Re: [Qemu-devel] [PATCH] qmp: report TRAY_STATE_CHANGED events
On Fri, 04 Nov 2011 11:53:53 +0100
Paolo Bonzini pbonz...@redhat.com wrote:
On 11/01/2011 06:03 AM, ShaoHe Feng wrote:
after the guest startups, then I right click mouse in the UI of the
guest, and select the Eject from the menu.
there comes an event in the qmp-monitor.
{timestamp: {seconds: 1320118137, microseconds: 420150}, event:
TRAY_STATE_CHANGED, data: {device: ide0-cd1, state: open}}
however, if I change the cdrom by this command:
{ execute: change,arguments: { device: ide0-cd1, target:
/home/fsh/image/OCDC-natty-Test-Drive-20110823_010339.iso } }
there is no any event.
and { execute: eject, arguments: { device: ide0-cd1 } },
there is also no any event.
This was by design. The idea was that management can do the following
to change a CD when the guest keeps the medium locked and reacts to
eject requests (like very recent Linux does):
Just a note: this didn't make 1.0... I replied to it but didn't get
feedback:
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg03096.html
Scenario 1: non-forced media change
1. start looking at TRAY_STATE_CHANGED events
2. execute eject command
3. execute query-block
4. if disk is still shown as closed, check for guest reactions:
4.1. if no TRAY_STATE_CHANGED event has been reported since
step 1, wait until a TRAY_STATE_CHANGED event has arrived
4.2. if the TRAY_STATE_CHANGED event had state == closed, fail
5. execute change command
Scenario 2: forced media change
1. execute eject -f command (with the posted patches that
always unlock the tray upon eject -f)
2. execute change command
3. if it fails, restart
Paolo
[Qemu-devel] [Bug 885213] Re: Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
Did you try compilation in a tree with old generated files from previous
compilations? If there are several qmp-commands.h in subdirectories,
you have such old files. There must be only one qmp-commands.h
in the build root.
The old files start with {, the new files start with comment lines.
The compiler error which you got comes from an old file.
Create a new QEMU source tree and try compilation there.
Regards,
Stefan Weil
** Changed in: qemu
Assignee: (unassigned) = Stefan Weil (ubuntu-weilnetz)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/885213
Title:
Latest GIT version fails to compile on Linux cris-softmmu/pci-stub.c
Status in QEMU:
New
Bug description:
The latest GIT version (e072ea2fd8fdceef64159b9596d3c15ce01bea91)
fails to compile.
Host: debian x86-64. gcc 4.6.2
...
CCcris-softmmu/pci-stub.o
...
In file included from /home/njh/src/qemu/hw/pci-stub.c:24:0:
./qmp-commands.h: At top level:
./qmp-commands.h:3:1: error: expected identifier or ‘(’ before ‘{’ token
.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/885213/+subscriptions
[Qemu-devel] [Bug 760060] Re: Open Solaris 2009 Assertion `size' failed
** Changed in: qemu Assignee: (unassigned) = Stefan Weil (ubuntu-weilnetz) ** Changed in: qemu Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/760060 Title: Open Solaris 2009 Assertion `size' failed Status in QEMU: Fix Released Bug description: The latest git version of qemu (commit 9df38c47d01eb1fd7eb9d60ac70a4170e638b4a2) fails to boot the OpenSolaris image from http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso. qemu-img create opensolaris 3G qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d -redir tcp:2232::22 -k en-us -m 256 gives: qemu-system-sparc: /home/njh/src/qemu/exec.c:2614: cpu_register_physical_memory_offset: Assertion `size' failed. Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-thread --enable-kvm To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/760060/+subscriptions
Re: [Qemu-devel] [Xen-devel] [PATCH V3 02/10] Introduce HostPCIDevice to access a pci device on the host.
+static unsigned long get_value(HostPCIDevice *d, const char *name)
+{
+char path[PATH_MAX];
+FILE *f;
+unsigned long value;
+
+path_to(d, name, path, sizeof (path));
+f = fopen(path, r);
+if (!f) {
+fprintf(stderr, Error: Can't open %s: %s\n, path, strerror(errno));
+return -1;
So the decleration is 'unsigned long' but you return -1 here.
Should the decleration be 'signed long' ?
Or perhaps return the value as parameter and return zero for success
and = 0 for failure?
+}
+if (fscanf(f, %lx\n, value) != 1) {
+fprintf(stderr, Error: Syntax error in %s\n, path);
+value = -1;
+}
+fclose(f);
+return value;
+}
+
+static int pci_dev_is_virtfn(HostPCIDevice *d)
+{
+int rc;
+char path[PATH_MAX];
+struct stat buf;
+
+path_to(d, physfn, path, sizeof (path));
+rc = !stat(path, buf);
+
+return rc;
Seems like this could be a 'bool'?
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+char path[PATH_MAX];
+
+if (d-config_fd 0) {
+path_to(d, config, path, sizeof (path));
+d-config_fd = open(path, O_RDWR);
+if (d-config_fd 0) {
+fprintf(stderr, HostPCIDevice: Can not open '%s': %s\n,
+path, strerror(errno));
+}
+}
+return d-config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int
len)
+{
+int fd = host_pci_config_fd(d);
+int res = 0;
+
+res = pread(fd, buf, len, pos);
+if (res 0) {
+fprintf(stderr, host_pci_config: read failed: %s (fd: %i)\n,
+strerror(errno), fd);
+return -1;
+}
+return res;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+ int pos, const void *buf, int len)
+{
+int fd = host_pci_config_fd(d);
+int res = 0;
+
+res = pwrite(fd, buf, len, pos);
+if (res 0) {
+fprintf(stderr, host_pci_config: write failed: %s\n,
+strerror(errno));
+return -1;
+}
+return res;
+}
+
+uint8_t host_pci_get_byte(HostPCIDevice *d, int pos)
+{
+ uint8_t buf;
+ host_pci_config_read(d, pos, buf, 1);
Not checking the return value?
+ return buf;
+}
+uint16_t host_pci_get_word(HostPCIDevice *d, int pos)
+{
+ uint16_t buf;
+ host_pci_config_read(d, pos, buf, 2);
Here as well?
+ return le16_to_cpu(buf);
So if we can't read those buffers, won't that mean we end up with
garbage in buf? As we haven't actually written anything to it?
Perhaps we should do:
if (host_pci..() 0)
return 0;
... normal case?
+}
+uint32_t host_pci_get_long(HostPCIDevice *d, int pos)
+{
+ uint32_t buf;
+ host_pci_config_read(d, pos, buf, 4);
+ return le32_to_cpu(buf);
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+ return host_pci_config_read(d, pos, buf, len);
Oh, so that is called.. Hm, not much chance of returning an error there is.
Can we propage the errors in case there is some fundamental failure
when reading/writting the data stream? Say the PCI device gets
unplugged by the user.. won't pread return -EXIO?
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+ return host_pci_config_write(d, pos, data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+ data = cpu_to_le16(data);
+ return host_pci_config_write(d, pos, data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+ data = cpu_to_le32(data);
+ return host_pci_config_write(d, pos, data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+ return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+uint32_t header = 0;
+int max_cap = PCI_MAX_EXT_CAP;
+int pos = PCI_CONFIG_SPACE_SIZE;
+
+do {
+header = host_pci_get_long(d, pos);
+/*
+ * If we have no capabilities, this is indicated by cap ID,
+ * cap version and next pointer all being 0.
+ */
+if (header == 0) {
+break;
+}
+
+if (PCI_EXT_CAP_ID(header) == cap) {
+return pos;
+}
+
+pos = PCI_EXT_CAP_NEXT(header);
+if (pos PCI_CONFIG_SPACE_SIZE) {
+break;
+}
+
+max_cap--;
+} while (max_cap 0);
+
+return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+HostPCIDevice *d = NULL;
+
+d = g_new0(HostPCIDevice, 1);
+
+d-config_fd = -1;
+d-domain = 0;
+d-bus = bus;
+d-dev = dev;
+d-func = func;
+
+if (host_pci_config_fd(d) == -1) {
+goto error;
+}
+if (get_resource(d) != 0) {
+goto error;
+}
+
+d-vendor_id = get_value(d,
Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs
On 11/04/2011 02:56 PM, Anthony Liguori wrote: On 11/04/2011 11:40 AM, Lucas Meneghel Rodrigues wrote: Hi guys, As we understand that qemu is approaching 1.0, we think it's a good idea to share the issues we have been seeing on recent qemu.git sanity jobs: 1) Some condition is consistently making a RHEL 6.1 linux guest not able to bring up the network interface, causing login failures for all linux guest tests. This very same guest install works perfectly on qemu-kvm, RHEL 5 and RHEL 6. Can you file a bug report with specific information about how the guest is being launched? Specifically, what NIC are we talking about? Do other types of guests work? https://bugs.launchpad.net/qemu/+bug/886255 I believe relevant info is there. Command lines, screenshots, kernel versions, qemu commit hashes... If you need something else, let me know. Regards, Anthony Liguori
[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network
** Attachment added: screenshot showing nw initialization failure https://bugs.launchpad.net/bugs/886255/+attachment/2585413/+files/vm1_2011-11-04_00-45-19.jpg -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/886255 Title: Qemu master branch - RHEL 6.1 guest failing to start network Status in QEMU: New Bug description: Guest: RHEL 6.1 64 bit DVD Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 qemu version: 11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git 11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master 11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] 11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] - /usr/local/autotest/tests/kvm/src/qemu 11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' 11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) On guest boot screenshots (one of them attached), you can see the message Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization Network card info 11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap 11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio Commented excerpt of the test log: 11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm 11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' 11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827 11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread 11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) ... here it starts booting ... 11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 ... here it gets an IP from the DHCP server ... 11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 --- 192.168.122.195 ... ok, let's try to login ... 11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' ... ouch, not possible to login ... 11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') ... message above repeats until ... 11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') 11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' 11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM 11/04 00:56:59 DEBUG|kvm_vm:0885| Destroying VM
[Qemu-devel] [Bug 886255] [NEW] Qemu master branch - RHEL 6.1 guest failing to start network
Public bug reported: Guest: RHEL 6.1 64 bit DVD Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 qemu version: 11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git 11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master 11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] 11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] - /usr/local/autotest/tests/kvm/src/qemu 11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' 11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) On guest boot screenshots (one of them attached), you can see the message Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization Network card info 11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap 11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio Commented excerpt of the test log: 11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm 11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' 11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827 11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread 11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) ... here it starts booting ... 11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 ... here it gets an IP from the DHCP server ... 11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 --- 192.168.122.195 ... ok, let's try to login ... 11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' ... ouch, not possible to login ... 11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') ... message above repeats until ... 11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') 11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' 11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM 11/04 00:56:59 DEBUG|kvm_vm:0885| Destroying VM with PID 9827 11/04 00:56:59 DEBUG|kvm_vm:0889| Trying to shutdown VM with shell command 11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' 11/04 00:56:59 DEBUG|kvm_vm:0893| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') 11/04 00:56:59 DEBUG|kvm_vm:0908| Trying to kill VM with monitor command 11/04 00:56:59 INFO
[Qemu-devel] [PATCH RFC for-1.0] Update copyright info
Judging by -version output, one could get the impression that QEMU was
last modified in 2008. Therefore extend the copyright statement to
cover other contributors so that it can be updated to the current year.
Signed-off-by: Andreas Färber afaer...@suse.de
---
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 624da0f..47e0ae0 100644
--- a/vl.c
+++ b/vl.c
@@ -1484,7 +1484,7 @@ static void main_loop(void)
static void version(void)
{
-printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION , Copyright
(c) 2003-2008 Fabrice Bellard\n);
+printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION , Copyright
(c) 2003-2011 Fabrice Bellard and contributors\n);
}
static void help(int exitcode)
--
1.7.7
Re: [Qemu-devel] [PATCH RFC for-1.0] Update copyright info
On 4 November 2011 17:56, Andreas Färber afaer...@suse.de wrote:
--- a/vl.c
+++ b/vl.c
@@ -1484,7 +1484,7 @@ static void main_loop(void)
static void version(void)
{
- printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION ,
Copyright (c) 2003-2008 Fabrice Bellard\n);
+ printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION ,
Copyright (c) 2003-2011 Fabrice Bellard and contributors\n);
}
linux-user/main.c:handle_arg_version() needs to be updated too.
(Perhaps we should have a QEMU_COPYRIGHT_DATE autoupdated by
configure based on the commit date of HEAD? :-))
-- PMM
[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network
We are currently investigating the failure. One of our suspects is that on kvm autotest, each new qemu process instance might have a new NIC mac address, and that might be triggering some condition in qemu in conjunction to the guest init scripts. It is important to note that this problem does not affect qemu-kvm.git, or RHEL based branches for that matter. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/886255 Title: Qemu master branch - RHEL 6.1 guest failing to start network Status in QEMU: New Bug description: Guest: RHEL 6.1 64 bit DVD Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 qemu version: 11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git 11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master 11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] 11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] - /usr/local/autotest/tests/kvm/src/qemu 11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' 11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) On guest boot screenshots (one of them attached), you can see the message Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization Network card info 11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap 11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio Commented excerpt of the test log: 11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm 11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' 11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827 11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread 11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) ... here it starts booting ... 11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 ... here it gets an IP from the DHCP server ... 11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 --- 192.168.122.195 ... ok, let's try to login ... 11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' ... ouch, not possible to login ... 11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') ... message above repeats until ... 11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n
[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network
I can't reproduce this with an Ubuntu guest. I suspect it has something to do with how you're configuring networking. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/886255 Title: Qemu master branch - RHEL 6.1 guest failing to start network Status in QEMU: New Bug description: Guest: RHEL 6.1 64 bit DVD Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 qemu version: 11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git 11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master 11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] 11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] - /usr/local/autotest/tests/kvm/src/qemu 11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' 11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) On guest boot screenshots (one of them attached), you can see the message Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization Network card info 11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap 11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio Commented excerpt of the test log: 11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm 11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' 11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827 11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread 11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) ... here it starts booting ... 11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 ... here it gets an IP from the DHCP server ... 11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 --- 192.168.122.195 ... ok, let's try to login ... 11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' ... ouch, not possible to login ... 11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') ... message above repeats until ... 11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') 11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' 11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM 11/04 00:56:59 DEBUG|kvm_vm:0885| Destroying VM with PID 9827 11/04 00:56:59 DEBUG|kvm_vm
Re: [Qemu-devel] GSoC mentor summit QEMU users session
Stefan Hajnoczi writes: On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote: On 03/11/2011 08:44, Stefan Hajnoczi wrote: On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau chout...@adacore.com wrote: On 29/10/2011 15:52, Alexander Graf wrote: I took a quick peak at the qemu-trace.[ch] from couverture and it looks along the lines of the instrumentation that others have been doing too. I hope you have time to propose the coverage instrumentation for upstream QEMU. I don't know much about other instrumentations in Qemu (pointers are welcome :), but what we have in couverture-qemu is not trivial, especially when it comes to MC/DC analysis. You should take a look at 201005-erts2.pdf if you want technical details. My impression was that the QEMU portion of instrumentation was fairly simple - it writes out trace records at various interesting points during guest execution in TCG. I think fancy analysis scripts do not have to be part of QEMU but they could be added to scripts/ or put in a new contrib/ directory. I've only had a brief look into the changes, but I think the mechanism I implemented has a cleaner fit into QEMU, thanks to previous feedback from this list. It explicitly separates the tracing mechanism (in QEMU itself) from the specific trace analysis (which resides in a separate library specified by the user at compile time, where most of couverture would go). On the other hand, I have a complementary set of events, so we can definitely join the efforts on that side (e.g., I haven't yet went into the trouble of adding the begin/end TB or branch events). I have only managed to send the most general changes that are needed before having the full-fledged instrumentation, but if there's no opposition on having this kind of feature I will start sending the rest once mainline opens up again (which I believe won't take much more time). Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH RFC for-1.0] Update copyright info
Am 04.11.2011 18:59, schrieb Peter Maydell:
On 4 November 2011 17:56, Andreas Färber afaer...@suse.de wrote:
--- a/vl.c
+++ b/vl.c
@@ -1484,7 +1484,7 @@ static void main_loop(void)
static void version(void)
{
-printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION ,
Copyright (c) 2003-2008 Fabrice Bellard\n);
+printf(QEMU emulator version QEMU_VERSION QEMU_PKGVERSION ,
Copyright (c) 2003-2011 Fabrice Bellard and contributors\n);
}
linux-user/main.c:handle_arg_version() needs to be updated too.
Thanks for noticing.
Me, I'm rather wondering about whether the formulation is right. (IANAL)
An alternative would be to leave Copyright (c) 2003-08 Fabrice and to
add , Copyright (c) 200x-11 whatever.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] QEMU 0.15.1 Linux
First of all, thanks to Jernej Simon for the response which pointed out my mistake regards qemu vs qemu-kvm, and the pointer to the correct version. This solved my problem. I have another question regards graphics driver for the Win7 client. I would like to use the VMware SVGA 3D (WDDM) driver on the client, which would give me Windows Aero and potentially better graphics performance, but when I install it in Windows I get the bang symbol in the device manager, and the message that the driver has been turned off. Is this driver supported in QEMU 0.15.1, and if so how do I get it to work? If not, is there some alternative with the capability I mention? Thx, Gus
[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network
A little more investigation shows that empty ssh keys are being generated on the first boot, so now it doesn't look like a network problem anymore. now we are trying to figure out just on qemu this phenomenon is happening. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/886255 Title: Qemu master branch - RHEL 6.1 guest failing to start network Status in QEMU: New Bug description: Guest: RHEL 6.1 64 bit DVD Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 qemu version: 11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git 11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master 11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] 11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] - /usr/local/autotest/tests/kvm/src/qemu 11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' 11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) On guest boot screenshots (one of them attached), you can see the message Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization Network card info 11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap 11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio Commented excerpt of the test log: 11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm 11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' 11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827 11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread 11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) ... here it starts booting ... 11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 ... here it gets an IP from the DHCP server ... 11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 --- 192.168.122.195 ... ok, let's try to login ... 11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' ... ouch, not possible to login ... 11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') ... message above repeats until ... 11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') 11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' 11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, another showstopper appeared for DVD+RW. After i disabled SET STREAMING, i was able to write a thoroughly formatted DVD+RW. But when i inserted one that was never written up to its end, the attempt failed to (re-)start background formatting (Format Type = 26h): FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 01 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) I cannot spot an occurence of this sense code in the qemu sources. There are B 00 06 , B 29 07 , B 3E 01. No failed ioctl is reported by my printf. But the failure happened twice. After shutdown of the guest (to get access to the drive), i could format (de-ice) the medium by the host system. Afterwards it was usable on the booted-again guest. Currently i suspect that the sense code stems from the guest kernel. (But caused by some problem with qemu.) This command can be performed without other preparations. But its parameters depend on the media state. The one above is for a partially formatted (i.e. partly written) DVD+RW. With a completely formatted DVD+RW, the attempt to re-format fails, too: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) The same command is appropriate for a new, unformatted DVD+RW. It fails exactly the same way on such a medium. The commands here have the Immed bit set (byte 1, bit1 of payload), so that they should return early. One would watch the drive by TEST UNIT READY for becomming ready again. REQUEST SENSE with DESC bit delivers progress information on some drives. But this is not necessary if FORMAT UNIT already ends with failure indication. Have a nice day :) Thomas
[Qemu-devel] [PATCH] arm: Fix CP15 FSR (C5) domain setting
During Xvisor development, it was noted that qemu did not return
the correct domain value in the Cp15 [Data] FSR register (C5).
This patch is a proposal to fix it.
Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---
--- qemu-0.15.1.org/target-arm/helper.c2011-10-12 18:41:43.0
+0200
+++ qemu-0.15.1/target-arm/helper.c2011-11-04 00:49:03.247062518 +0100
@@ -924,12 +924,12 @@
/* Check section/page access permissions.
Returns the page protection flags, or zero if the access is not
permitted. */
-static inline int check_ap(CPUState *env, int ap, int domain, int
access_type,
+static inline int check_ap(CPUState *env, int ap, int domain_prot, int
access_type,
int is_user)
{
int prot_ro;
- if (domain == 3)
+ if (domain_prot == 3)
return PAGE_READ | PAGE_WRITE;
if (access_type == 1)
@@ -996,6 +996,7 @@
int type;
int ap;
int domain;
+int domain_prot;
uint32_t phys_addr;
/* Pagetable walk. */
@@ -1003,13 +1004,14 @@
table = get_level1_table_address(env, address);
desc = ldl_phys(table);
type = (desc 3);
-domain = (env-cp15.c3 ((desc 4) 0x1e)) 3;
+domain = (desc 5) 0x0f;
+domain_prot = (env-cp15.c3 (domain * 2)) 3;
if (type == 0) {
/* Section translation fault. */
code = 5;
goto do_fault;
}
-if (domain == 0 || domain == 2) {
+if (domain_prot == 0 || domain_prot == 2) {
if (type == 2)
code = 9; /* Section domain fault. */
else
@@ -1067,7 +1069,7 @@
}
code = 15;
}
-*prot = check_ap(env, ap, domain, access_type, is_user);
+*prot = check_ap(env, ap, domain_prot, access_type, is_user);
if (!*prot) {
/* Access permission fault. */
goto do_fault;
@@ -1090,6 +1092,7 @@
int type;
int ap;
int domain;
+int domain_prot;
uint32_t phys_addr;
/* Pagetable walk. */
@@ -1107,10 +1110,10 @@
domain = 0;
} else {
/* Section or page. */
-domain = (desc 4) 0x1e;
+domain = (desc 5) 0x0f;
}
-domain = (env-cp15.c3 domain) 3;
-if (domain == 0 || domain == 2) {
+domain_prot = (env-cp15.c3 (domain * 2)) 3;
+if (domain_prot == 0 || domain_prot == 2) {
if (type == 2)
code = 9; /* Section domain fault. */
else
@@ -1155,7 +1158,7 @@
}
code = 15;
}
-if (domain == 3) {
+if (domain_prot == 3) {
*prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
} else {
if (xn access_type == 2)
@@ -1167,7 +1170,7 @@
code = (code == 15) ? 6 : 3;
goto do_fault;
}
-*prot = check_ap(env, ap, domain, access_type, is_user);
+*prot = check_ap(env, ap, domain_prot, access_type, is_user);
if (!*prot) {
/* Access permission fault. */
goto do_fault;
Re: [Qemu-devel] [PATCH] arm: Fix CP15 FSR (C5) domain setting
On 4 November 2011 20:50, Jean-Christophe DUBOIS j...@tribudubois.net wrote: During Xvisor development, it was noted that qemu did not return the correct domain value in the Cp15 [Data] FSR register (C5). This patch is a proposal to fix it. --- qemu-0.15.1.org/target-arm/helper.c 2011-10-12 18:41:43.0 +0200 +++ qemu-0.15.1/target-arm/helper.c 2011-11-04 00:49:03.247062518 +0100 @@ -924,12 +924,12 @@ This is on my todo list to review. In the meantime: * you should submit patches against current qemu git master, not an old released version, please * if you can send emails via a path that doesn't line wrap long lines this makes life much easier on the receiving end * this is definitely not a trivial patch * it's worth running patches through ./scripts/checkpatch.pl to catch minor coding style issues * if you resend a patch please include a note about what has changed since the previous version and put a 'v2/v3/...' note in the email subject. thanks -- PMM
Re: [Qemu-devel] [spam] QEMU 0.15.1 Linux
On Friday, November 4, 2011, 20:56:05, Gus Zernial wrote: Is this driver supported in QEMU 0.15.1, and if so how do I get it to work? If not, is there some alternative with the capability I mention? The VMWare SVGA driver is reverse-engineered from the Linux/X VMWare driver, and as such only supports what the X driver does. There's no 3D acceleration, and while at least the VMWare SVGA driver for XP does load, it has graphical glitches, and is in my experience actually slower than plain VESA driver. -- Jernej Simončič http://eternallybored.org/ Seven eighths of everything can't be seen. -- Marshall's Generalized Iceberg Theorem
[Qemu-devel] [PATCH] Fix reset bit for realview platform.
According to realview documentation [1], the bit used to reset the board
is bit 2 and not bit 8.
This is also in sync with Linux source code [2].
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0417d/BBACIGAD.html
[2]
http://lxr.free-electrons.com/source/arch/arm/mach-realview/realview_pba8.c#L274
Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---
hw/arm_sysctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/arm_sysctl.c b/hw/arm_sysctl.c
index 17cf6f7..aef271e 100644
--- a/hw/arm_sysctl.c
+++ b/hw/arm_sysctl.c
@@ -237,7 +237,7 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
}
if (s-lockval == LOCK_VALUE) {
s-resetlevel = val;
-if (val 0x100)
+if (val 0x04)
qemu_system_reset_request ();
}
break;
--
1.7.5.4
Re: [Qemu-devel] [PATCH] Fix reset bit for realview platform.
On 4 November 2011 23:22, Jean-Christophe DUBOIS j...@tribudubois.net wrote: According to realview documentation [1], the bit used to reset the board is bit 2 and not bit 8. True for PBA8 and PBXA9, but not true for PB1176, PB926 (where it is bit 8) or Emulation Baseboard (which doesn't implement this register at all). You need to make this all into a switch() on board_id() (combine this with the existing 'RAZ/WI on vexpress' if()). -- PMM
[Qemu-devel] [Bug 886408] Re: Windows 64 bits install BSOD : UNSUPPORTED_PROCESSOR (only without kvm)
I was using Windows 7 x86_64 DVD image: Ultimate N edition (french) b89f76c3a1f9a15f2f583ce38d9740ea fr_windows_7_ultimate_n_with_sp1_x64_dvd_u_677548.iso -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/886408 Title: Windows 64 bits install BSOD : UNSUPPORTED_PROCESSOR (only without kvm) Status in QEMU: New Bug description: Windows DVD starts loading and then stops with error 0x5d MSDN tells us that 0x5d means unsupported_processor The guest CPU is 64 bits though, the DVD fails early if booted on a 32bits CPU Tested versions: 0.14.1, git (932eacc158) qemu-system-x86_64 -m 1024 -boot d -cdrom win7.iso -hda win7.hdd Tried various -cpu options: Nehalem, core2duo, Penryn, Conroe, Opteron_G3 x86_64 host, without vx-t Same iso is reported to install fine with kvm Other similar reports: http://virtuallyfun.superglobalmegacorp.com/?p=386 http://comments.gmane.org/gmane.comp.emulators.qemu/92457 http://xen.1045712.n5.nabble.com/64bit-Windows-Guest-Blue-Screens-on-install-td4505715.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/886408/+subscriptions
[Qemu-devel] [Bug 886408] [NEW] Windows 64 bits install BSOD : UNSUPPORTED_PROCESSOR (only without kvm)
Public bug reported: Windows DVD starts loading and then stops with error 0x5d MSDN tells us that 0x5d means unsupported_processor The guest CPU is 64 bits though, the DVD fails early if booted on a 32bits CPU Tested versions: 0.14.1, git (932eacc158) qemu-system-x86_64 -m 1024 -boot d -cdrom win7.iso -hda win7.hdd Tried various -cpu options: Nehalem, core2duo, Penryn, Conroe, Opteron_G3 x86_64 host, without vx-t Same iso is reported to install fine with kvm Other similar reports: http://virtuallyfun.superglobalmegacorp.com/?p=386 http://comments.gmane.org/gmane.comp.emulators.qemu/92457 http://xen.1045712.n5.nabble.com/64bit-Windows-Guest-Blue-Screens-on-install-td4505715.html ** 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/886408 Title: Windows 64 bits install BSOD : UNSUPPORTED_PROCESSOR (only without kvm) Status in QEMU: New Bug description: Windows DVD starts loading and then stops with error 0x5d MSDN tells us that 0x5d means unsupported_processor The guest CPU is 64 bits though, the DVD fails early if booted on a 32bits CPU Tested versions: 0.14.1, git (932eacc158) qemu-system-x86_64 -m 1024 -boot d -cdrom win7.iso -hda win7.hdd Tried various -cpu options: Nehalem, core2duo, Penryn, Conroe, Opteron_G3 x86_64 host, without vx-t Same iso is reported to install fine with kvm Other similar reports: http://virtuallyfun.superglobalmegacorp.com/?p=386 http://comments.gmane.org/gmane.comp.emulators.qemu/92457 http://xen.1045712.n5.nabble.com/64bit-Windows-Guest-Blue-Screens-on-install-td4505715.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/886408/+subscriptions
[Qemu-devel] qemu-kvm crashes doing migration with disks + blkdebug files (does not happen with qemu)
Hi folks, qemu-kvm is segfaulting when executing migration with blkdebug files. 19:50:02 DEBUG| Git repo qemu_kvm uri: git://github.com/avikivity/qemu.git 19:50:02 DEBUG| Git repo qemu_kvm branch: master 19:50:30 INFO | Commit hash for qemu_kvm is 7879db7e9c09b92d9af1c143fbe2cc212ec89e4b (no tag found) How to reproduce: 1) create a origin vm like: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-200902-95j0',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-200902-95j0',server,nowait -serial unix:'/tmp/serial-2004-200902-95j0',server,nowait -drive file=blkdebug:/usr/local/autotest/virt/blkdebug/default.conf:/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2,index=0,if=virtio,cache=none,rerror=stop,werror=stop -device virtio-net-pci,netdev=idtzhBVb,mac='9a:d0:7b:07:18:72',id='id9JW3ZV' -netdev tap,id=idtzhBVb,fd=23 -m 2048 -smp 2 -vnc :0 2) create a destination vm like: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-201329-Ia9o',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-201329-Ia9o',server,nowait -serial unix:'/tmp/serial-2004-201329-Ia9o',server,nowait -drive file=blkdebug:/usr/local/autotest/virt/blkdebug/default.conf:/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2,index=0,if=virtio,cache=none,rerror=stop,werror=stop -device virtio-net-pci,netdev=idup1xAf,mac='9a:d0:7b:07:18:72',id='idyvOQf3' -netdev tap,id=idup1xAf,fd=19 -m 2048 -smp 2 -vnc :1 -S -incoming exec:nc -l 5200 Note that blkdebug file contains: [inject-error] state = 2 event = read_aio errno = 7 immediately = off once = on [set-state] state = 1 event = read_aio new_state = 2 [set-state] state = 2 event = read_aio new_state = 3 Start the migration (on this example, using exec, but it reproduces with tcp and unix sockets): 11/04 20:13:30 DEBUG|kvm_monito:0254| (monitor humanmonitor1) Sending command 'migrate -d exec:nc localhost 5200' Then you will have: 11/04 20:13:33 INFO | aexpect:0783| [qemu output] invalid runstate transition 11/04 20:13:36 INFO | aexpect:0783| [qemu output] /bin/sh: line 1: 14695 Aborted (core dumped) /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-2004-200902-95j0',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-2004-200902-95j0',server,nowait -serial unix:'/tmp/serial-2004-200902-95j0',server,nowait -drive file=blkdebug:/usr/local/autotest/virt/blkdebug/default.conf:/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2,index=0,if=virtio,cache=none,rerror=stop,werror=stop -device virtio-net-pci,netdev=idtzhBVb,mac='9a:d0:7b:07:18:72',id='id9JW3ZV' -netdev tap,id=idtzhBVb,fd=23 -m 2048 -smp 2 -vnc :0 We do have the core dumps available in case someone is interested in debugging the issue. It is important to note that this problem is not happening with qemu.git master.
