Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 22.08.2012, at 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
I can only guess, but the code looks to me as if it wants to be a nop on ROM
pages, while basically doing cpu_physical_memory_rw for RAM pages. Usually in
QEMU, every non-RAM page gets treated as MMIO which might eventually lead to
machine checks.
Alex
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On Wed, Aug 22, 2012 at 08:02:11AM +0200, Alexander Graf wrote:
On 22.08.2012, at 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we
loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
I can only guess, but the code looks to me as if it wants to be a
nop on ROM pages, while basically doing cpu_physical_memory_rw for
RAM pages. Usually in QEMU, every non-RAM page gets treated as MMIO
which might eventually lead to machine checks.
Maybe. Anthony, can you make a ruling on this, or tell me who can. I
don't really care how I fix it, but it's definitely broken right now.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 22.08.2012, at 08:10, David Gibson wrote:
On Wed, Aug 22, 2012 at 08:02:11AM +0200, Alexander Graf wrote:
On 22.08.2012, at 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we
loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
I can only guess, but the code looks to me as if it wants to be a
nop on ROM pages, while basically doing cpu_physical_memory_rw for
RAM pages. Usually in QEMU, every non-RAM page gets treated as MMIO
which might eventually lead to machine checks.
Maybe. Anthony, can you make a ruling on this, or tell me who can. I
don't really care how I fix it, but it's definitely broken right now.
Yeah, and for a 1.2 quick fix your original patch should be perfectly fine too.
Alex
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
At 08/15/2012 04:53 AM, Marcelo Tosatti Wrote:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
How about searching for the Kernel panic - not syncing string
in the guests serial output? Say libvirtd could take an action upon
that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
Please don't forget Windows guests, there is no console and no Kernel
Panic string ;)
What I used for debugging purposes on Windows guest is to register a
bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
register.
Yan.
Considering whether a panic-device should cover other OSes is also \
something to consider. Even for Linux, is panic the only case which
should be reported via the mechanism? What about oopses without panic?
Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:
- reboot
- blink
Not sure the semantics of blink but that might be a good place for a
pvops hook.
None are paravirtual interfaces however.
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
My concern is that you end up with state that is dependant on x86.
Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
Having the ability to stop/restart the guest (and even introducing a
new VM runstate) is more than a status LED analogy.
I must admit, I don't know why a new runstate is necessary/useful. The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest. That level of information belongs in userspace IMHO.
Can this new infrastructure be used by other architectures?
I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.
From the patch description:
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
Wen, auto dump means dump of guest memory?
Yes.
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
Yes, the guest is stopped while auto dumping.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
It can be easily done in management app.
Thanks
Wen Congyang
Do you consider allowing support for Windows as overengineering?
I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But Windows has configurable
memory dump/reset/reboot, so yes it should not necessary.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Well, we have more than a single serial port, even when leaving
virtio-serial aside...
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 22.08.2012, at 08:10, David Gibson wrote:
On Wed, Aug 22, 2012 at 08:02:11AM +0200, Alexander Graf wrote:
On 22.08.2012, at 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we
loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
I can only guess, but the code looks to me as if it wants to be a
nop on ROM pages, while basically doing cpu_physical_memory_rw for
RAM pages. Usually in QEMU, every non-RAM page gets treated as MMIO
which might eventually lead to machine checks.
Maybe. Anthony, can you make a ruling on this, or tell me who can. I
don't really care how I fix it, but it's definitely broken right now.
Also, does tb_invalidate_phys_page_range() do an icache flush on KVM?
Alex
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 2012-08-22 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
write_rom ignores write protection - that you usually find on ROMs. That
makes no difference under KVM so far as there we lack read-only
sections. But that will be fixed soon, patches are on the list.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 2012-08-22 08:47, Jan Kiszka wrote:
On 2012-08-22 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
write_rom ignores write protection - that you usually find on ROMs. That
makes no difference under KVM so far as there we lack read-only
sections. But that will be fixed soon, patches are on the list.
In fact, it does make a difference also for KVM mode as
cpu_physical_memory_rw works from userspace while the limitation only
affects guest code running under KVM control.
Jan
PS: I'm still facing a bogus Mail-Followup-To tag in your postings,
David, thus you easily fall from the To list on reply.
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH] xen-all.c: fix multiply issue for int and uint types
If the two multiply operands are int and uint types separately,
the int type will be transformed to uint firstly, which is not the
intent in our code piece. The fix is to add (int64_t) transform
for the uint type before the multiply.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
xen-all.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 61def2e..f76b051 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -712,7 +712,8 @@ static void cpu_ioreq_pio(ioreq_t *req)
for (i = 0; i req-count; i++) {
tmp = do_inp(req-addr, req-size);
-cpu_physical_memory_write(req-data + (sign * i * req-size),
+cpu_physical_memory_write(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t *) tmp, req-size);
}
}
@@ -723,7 +724,8 @@ static void cpu_ioreq_pio(ioreq_t *req)
for (i = 0; i req-count; i++) {
uint32_t tmp = 0;
-cpu_physical_memory_read(req-data + (sign * i * req-size),
+cpu_physical_memory_read(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
do_outp(req-addr, req-size, tmp);
}
@@ -740,12 +742,14 @@ static void cpu_ioreq_move(ioreq_t *req)
if (!req-data_is_ptr) {
if (req-dir == IOREQ_READ) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-addr + (sign * i * req-size),
+cpu_physical_memory_read(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t *) req-data, req-size);
}
} else if (req-dir == IOREQ_WRITE) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_write(req-addr + (sign * i * req-size),
+cpu_physical_memory_write(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t *) req-data, req-size);
}
}
@@ -754,16 +758,20 @@ static void cpu_ioreq_move(ioreq_t *req)
if (req-dir == IOREQ_READ) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-addr + (sign * i * req-size),
+cpu_physical_memory_read(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
-cpu_physical_memory_write(req-data + (sign * i * req-size),
+cpu_physical_memory_write(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
}
} else if (req-dir == IOREQ_WRITE) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-data + (sign * i * req-size),
+cpu_physical_memory_read(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
-cpu_physical_memory_write(req-addr + (sign * i * req-size),
+cpu_physical_memory_write(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
}
}
--
1.7.1
Re: [Qemu-devel] [PATCH v8 5/6] introduce a new qom device to deal with panicked event
At 08/09/2012 03:01 AM, Blue Swirl Wrote:
On Wed, Aug 8, 2012 at 2:47 AM, Wen Congyang we...@cn.fujitsu.com wrote:
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
event according to panicked_action's value. The possible actions are:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause the guest
3. emit QEVENT_GUEST_PANICKED and poweroff the guest
4. emit QEVENT_GUEST_PANICKED and reset the guest
I/O ports does not work for some targets(for example: s390). And you
can implement another qom device, and include it's code into pv_event.c
for such target.
Note: if we emit QEVENT_GUEST_PANICKED only, and the management
application does not receive this event(the management may not
run when the event is emitted), the management won't know the
guest is panicked.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
hw/kvm/Makefile.objs |2 +-
hw/kvm/pv_event.c| 109
++
hw/kvm/pv_ioport.c | 93 ++
hw/pc_piix.c |9
kvm.h|2 +
5 files changed, 214 insertions(+), 1 deletions(-)
create mode 100644 hw/kvm/pv_event.c
create mode 100644 hw/kvm/pv_ioport.c
diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
index 226497a..23e3b30 100644
--- a/hw/kvm/Makefile.objs
+++ b/hw/kvm/Makefile.objs
@@ -1 +1 @@
-obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o
+obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pv_event.o
diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
new file mode 100644
index 000..8897237
--- /dev/null
+++ b/hw/kvm/pv_event.c
@@ -0,0 +1,109 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ * Wen Congyang we...@cn.fujitsu.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include linux/kvm_para.h
+#include asm/kvm_para.h
+#include qobject.h
+#include qjson.h
+#include monitor.h
+#include sysemu.h
+#include kvm.h
+
+/* Possible values for action parameter. */
+#define PANICKED_REPORT 1 /* emit QEVENT_GUEST_PANICKED only */
+#define PANICKED_PAUSE 2 /* emit QEVENT_GUEST_PANICKED and pause VM
*/
+#define PANICKED_POWEROFF 3 /* emit QEVENT_GUEST_PANICKED and quit VM */
+#define PANICKED_RESET 4 /* emit QEVENT_GUEST_PANICKED and reset VM
*/
+
+#define PV_EVENT_DRIVER kvm_pv_event
+
+struct pv_event_action {
PVEventAction
+char *panicked_action;
+int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf) \
+DEFINE_PROP_STRING(panicked_action, _state, _conf.panicked_action)
+
+static void panicked_mon_event(const char *action)
+{
+QObject *data;
+
+data = qobject_from_jsonf({ 'action': %s }, action);
+monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
+qobject_decref(data);
+}
+
+static void panicked_perform_action(uint32_t panicked_action)
+{
+switch (panicked_action) {
+case PANICKED_REPORT:
+panicked_mon_event(report);
+break;
+
+case PANICKED_PAUSE:
+panicked_mon_event(pause);
+vm_stop(RUN_STATE_GUEST_PANICKED);
+break;
+
+case PANICKED_POWEROFF:
+panicked_mon_event(poweroff);
+qemu_system_shutdown_request();
+break;
Misses a line break unlike other cases.
+case PANICKED_RESET:
+panicked_mon_event(reset);
+qemu_system_reset_request();
+break;
+}
+}
+
+static uint64_t supported_event(void)
+{
+return 1 KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct pv_event_action *conf)
+{
+if (event == KVM_PV_EVENT_PANICKED) {
+panicked_perform_action(conf-panicked_action_value);
+}
+}
+
+static int pv_event_init(struct pv_event_action *conf)
+{
+if (!conf-panicked_action) {
+conf-panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf-panicked_action, none) == 0) {
+conf-panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf-panicked_action, pause) == 0) {
+conf-panicked_action_value = PANICKED_PAUSE;
+} else if (strcasecmp(conf-panicked_action, poweroff) == 0) {
+conf-panicked_action_value = PANICKED_POWEROFF;
+} else if (strcasecmp(conf-panicked_action, reset) == 0) {
+conf-panicked_action_value = PANICKED_RESET;
+} else {
+return -1;
+}
+
+return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include pv_ioport.c
I'd rather not include any .c files but insert the contents here directly.
+
+#else
Re: [Qemu-devel] [PATCH] Correct computation of bytes per pixel from bits per pixel
Can you use this free space to provide a scenario where the missing
round-up caused a problem?
On 2012-08-21 23:32, BALATON Zoltan wrote:
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
console.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/console.c b/console.c
index 4525cc7..f698b77 100644
--- a/console.c
+++ b/console.c
@@ -1612,7 +1612,7 @@ PixelFormat
qemu_different_endianness_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = (bpp + 7) 3;
Compilers are smart enough to substitute such divisions by shift
operations but for humans the explicit form is easier to read. So please
keep it.
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
@@ -1661,7 +1661,7 @@ PixelFormat qemu_default_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = (bpp + 7) 3;
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] vmware_vga: Cleanup and allow simple drivers to work without the fifo
On 2012-08-21 23:33, BALATON Zoltan wrote:
Detailed changes: Removing info available elsewhere from vmsvga_state.
Fix mixup between depth and bits per pixel. Return a value for FB_SIZE
even before enabled (according to the documentation, drivers should
read this value before enabling the device). Postpone stopping the
dirty log to the point where the command fifo is configured to allow
drivers which don't use the fifo to work too. (Without this the
picture rendered into the vram never got to the screen but the
DIRECT_VRAM option meant to support this case was removed a year ago.)
This is a rather big patch. I strongly suspect you can break it up into
smaller pieces that address separate aspects one-by-one. Also, it is
definitely to heavy for qemu-trivial.
Jan
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
console.h | 20 +
hw/vga.c|2 +-
hw/vga_int.h|1 +
hw/vmware_vga.c | 243
++-
4 files changed, 137 insertions(+), 129 deletions(-)
diff --git a/console.h b/console.h
index 4334db5..00baf5b 100644
--- a/console.h
+++ b/console.h
@@ -328,6 +328,26 @@ static inline int
ds_get_bytes_per_pixel(DisplayState *ds)
return ds-surface-pf.bytes_per_pixel;
}
+static inline int ds_get_depth(DisplayState *ds)
+{
+return ds-surface-pf.depth;
+}
+
+static inline int ds_get_rmask(DisplayState *ds)
+{
+return ds-surface-pf.rmask;
+}
+
+static inline int ds_get_gmask(DisplayState *ds)
+{
+return ds-surface-pf.gmask;
+}
+
+static inline int ds_get_bmask(DisplayState *ds)
+{
+return ds-surface-pf.bmask;
+}
+
#ifdef CONFIG_CURSES
#include curses.h
typedef chtype console_ch_t;
diff --git a/hw/vga.c b/hw/vga.c
index f82ced8..7e6dc41 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1611,7 +1611,7 @@ void vga_invalidate_scanlines(VGACommonState *s,
int y1, int y2)
}
}
-static void vga_sync_dirty_bitmap(VGACommonState *s)
+void vga_sync_dirty_bitmap(VGACommonState *s)
{
memory_region_sync_dirty_bitmap(s-vram);
}
diff --git a/hw/vga_int.h b/hw/vga_int.h
index 8938093..16d53ef 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -195,6 +195,7 @@ MemoryRegion *vga_init_io(VGACommonState *s,
const MemoryRegionPortio **vbe_ports);
void vga_common_reset(VGACommonState *s);
+void vga_sync_dirty_bitmap(VGACommonState *s);
void vga_dirty_log_start(VGACommonState *s);
void vga_dirty_log_stop(VGACommonState *s);
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index f5e4f44..2b77766 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -32,16 +32,19 @@
#define HW_FILL_ACCEL
#define HW_MOUSE_ACCEL
-# include vga_int.h
+#include vga_int.h
+
+/* See http://vmware-svga.sf.net/ for some documentation on VMWare SVGA */
struct vmsvga_state_s {
VGACommonState vga;
-int width;
-int height;
+/* -*- The members marked are now unused and could be removed but they are
+ * contained in the VMState thus need special handling. Maybe they
could
+ * be removed the next time a new machine type is added.
+ */
int invalidated;
-int depth;
-int bypp;
+int depth; /* -*- */
int enable;
int config;
struct {
@@ -58,11 +61,8 @@ struct vmsvga_state_s {
int new_height;
uint32_t guest;
uint32_t svgaid;
-uint32_t wred;
-uint32_t wgreen;
-uint32_t wblue;
int syncing;
-int fb_size;
+int fb_size; /* -*- */
MemoryRegion fifo_ram;
uint8_t *fifo_ptr;
@@ -298,40 +298,33 @@ static inline void vmsvga_update_rect(struct
vmsvga_state_s *s,
uint8_t *src;
uint8_t *dst;
-if (x + w s-width) {
+if (x + w ds_get_width(s-vga.ds)) {
fprintf(stderr, %s: update width too large x: %d, w: %d\n,
-__FUNCTION__, x, w);
-x = MIN(x, s-width);
-w = s-width - x;
+__func__, x, w);
+x = MIN(x, ds_get_width(s-vga.ds));
+w = ds_get_width(s-vga.ds) - x;
}
-if (y + h s-height) {
+if (y + h ds_get_height(s-vga.ds)) {
fprintf(stderr, %s: update height too large y: %d, h: %d\n,
-__FUNCTION__, y, h);
-y = MIN(y, s-height);
-h = s-height - y;
+__func__, y, h);
+y = MIN(y, ds_get_height(s-vga.ds));
+h = ds_get_height(s-vga.ds) - y;
}
-line = h;
-bypl = s-bypp * s-width;
-width = s-bypp * w;
-start = s-bypp * x + bypl * y;
+bypl = ds_get_linesize(s-vga.ds);
+width = ds_get_bytes_per_pixel(s-vga.ds) * w;
+start = ds_get_bytes_per_pixel(s-vga.ds) * x + bypl * y;
src = s-vga.vram_ptr + start;
dst = ds_get_data(s-vga.ds) + start;
-for (; line 0; line --, src += bypl, dst += bypl)
+for (line = h; line 0; line--, src += bypl, dst += bypl)
Re: [Qemu-devel] [PATCH] Add guest-get-hostname to retrieve the guests current hostname
On Tue, Aug 21, 2012 at 07:31:17PM +0100, Daniel P. Berrange wrote: On Tue, Aug 21, 2012 at 01:57:54PM +0200, Guido Günther wrote: [..snip..] Why no impl ? Winsock has the gethostname() API too $ grep gethostname /usr/i686-w64-mingw32/sys-root/mingw/include/*.h /usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h: WINSOCK_API_LINKAGE int WSAAPI gethostname(char *name,int namelen); This was mostly due to the lack of a test system. Are there any pointers on how to cross compile qemu-qa for Windows? Cheers, -- Guido Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] ivshmem assertion failure with EventNotifier
On 2012-08-22 06:29, Cam Macdonell wrote: Hi Paolo, I've noticed an assertion error when sending interrupts via ivshmem. I bisected to this patch. commit 563027cc0c94aa4846c18f9d665a4c90f8c42ba8 Author: Paolo Bonzini pbonz...@redhat.com Date: Thu Jul 5 17:16:25 2012 +0200 ivshmem: use EventNotifier and memory API All of ivshmem's usage of eventfd now has a corresponding API in EventNotifier. Simplify the code by using it, and also use the memory API consistently to set up and tear down the ioeventfds. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com qemu-system-x86_64: /home/cam/src/git/qemu/memory.c:1244: memory_region_del_even tfd: Assertion `i != mr-ioeventfd_nb' failed. This assertion failure occurs when the eventfd is triggered. I'll continue to dig around, but can you explain what this assertion is catching. Is there an initialization that might be missing? Possibly a double-release of the eventfd. The assertion checks if the parameters provided on del_eventfd match an existing one. Or that matching is broken. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] setting up breakpoints - kernel debugging help wit gdb in qemu-kvm
I am running a linux guest like this - which I wish to debug - but the breakpoint gets set but I am not able to stop the guest execution at the set breakpoint - it just hangs after I do continue. Can you please provide me some clues - # ./qemu-system-x86_64 -m 2048 -smp 4 -vga std -vnc :5 -drive file=/sda4/bin/disk/disk0.img,cache=writeback -S -s # gdb GNU gdb (GDB) Fedora (7.2-52.fc14) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. The target architecture is assumed to be i386:x86-64:intel (gdb) symbol-file /sda4/kvm/vmlinux Reading symbols from /sda4/kvm/vmlinux...done. (gdb) target remote :1234 Remote debugging using :1234 0x in ?? () (gdb) b kmem_cache_alloc Breakpoint 1 at 0x81121adb: file mm/slub.c, line 2375. (2 locations) (gdb) c Continuing. Thanks, Onkar
[Qemu-devel] [PATCH v12 2/2] configure: print spice-protocol and spice-server versions
Signed-off-by: Alon Levy al...@redhat.com --- configure | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 84fa2c6..02c06aa 100755 --- a/configure +++ b/configure @@ -2657,6 +2657,8 @@ EOF spice=yes libs_softmmu=$libs_softmmu $spice_libs QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags +spice_protocol_version=$($pkg_config --modversion spice-protocol) +spice_server_version=$($pkg_config --modversion spice-server) if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21; then spice_qxl_io_monitors_config_async=yes fi @@ -3114,7 +3116,7 @@ echo libcap-ng support $cap_ng echo vhost-net support $vhost_net echo Trace backend $trace_backend echo Trace output file $trace_file-pid -echo spice support $spice +echo spice support $spice ($spice_protocol_version/$spice_server_version) echo rbd support $rbd echo xfsctl support$xfs echo nss used $smartcard_nss -- 1.7.11.2
[Qemu-devel] [PATCH v12 1/2] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC
Revision bumped to 4 for new IO support, enabled for spice-server =
0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
defaults to 4, iff spice-server = 0.11.1 spice-protocol =
0.12.0.
This io calls the corresponding new spice api
spice_qxl_monitors_config_async to let spice-server read a new guest set
monitors config and notify the client.
On migration reissue spice_qxl_monitors_config_async.
RHBZ: 770842
Signed-off-by: Alon Levy al...@redhat.com
---
v11-v12:
fix build with older spice server (Gerd).
configure | 7
hw/qxl.c | 97 +++---
hw/qxl.h | 8 +
trace-events | 1 +
ui/spice-display.h | 1 +
5 files changed, 110 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index cc774b5..84fa2c6 100755
--- a/configure
+++ b/configure
@@ -2657,6 +2657,9 @@ EOF
spice=yes
libs_softmmu=$libs_softmmu $spice_libs
QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags
+if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21;
then
+spice_qxl_io_monitors_config_async=yes
+fi
else
if test $spice = yes ; then
feature_not_found spice
@@ -3392,6 +3395,10 @@ if test $spice = yes ; then
echo CONFIG_SPICE=y $config_host_mak
fi
+if test $spice_qxl_io_monitors_config_async = yes ; then
+ echo CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC=y $config_host_mak
+fi
+
if test $smartcard = yes ; then
echo CONFIG_SMARTCARD=y $config_host_mak
fi
diff --git a/hw/qxl.c b/hw/qxl.c
index c978f5e..45be2ba 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -27,6 +27,11 @@
#include qxl.h
+#ifndef CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC
+/* spice-protocol is too old, add missing definitions */
+#define QXL_IO_MONITORS_CONFIG_ASYNC (QXL_IO_FLUSH_RELEASE + 1)
+#endif
+
/*
* NOTE: SPICE_RING_PROD_ITEM accesses memory on the pci bar and as
* such can be changed by the guest, so to avoid a guest trigerrable
@@ -249,6 +254,39 @@ static void qxl_spice_destroy_surfaces(PCIQXLDevice *qxl,
qxl_async_io async)
}
}
+static void qxl_spice_monitors_config_async(PCIQXLDevice *qxl, int replay)
+{
+trace_qxl_spice_monitors_config(qxl-id);
+/* 0x000b01 == 0.11.1 */
+#if SPICE_SERVER_VERSION = 0x000b01 \
+defined(CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC)
+if (replay) {
+/*
+ * don't use QXL_COOKIE_TYPE_IO:
+ * - we are not running yet (post_load), we will assert
+ *in send_events
+ * - this is not a guest io, but a reply, so async_io isn't set.
+ */
+spice_qxl_monitors_config_async(qxl-ssd.qxl,
+qxl-guest_monitors_config,
+MEMSLOT_GROUP_GUEST,
+(uintptr_t)qxl_cookie_new(
+QXL_COOKIE_TYPE_POST_LOAD_MONITORS_CONFIG,
+0));
+} else {
+qxl-guest_monitors_config = qxl-ram-monitors_config;
+spice_qxl_monitors_config_async(qxl-ssd.qxl,
+qxl-ram-monitors_config,
+MEMSLOT_GROUP_GUEST,
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+ QXL_IO_MONITORS_CONFIG_ASYNC));
+}
+#else
+fprintf(stderr, qxl: too old spice-protocol/spice-server for
+QXL_IO_MONITORS_CONFIG_ASYNC\n);
+#endif
+}
+
void qxl_spice_reset_image_cache(PCIQXLDevice *qxl)
{
trace_qxl_spice_reset_image_cache(qxl-id);
@@ -538,6 +576,7 @@ static const char *io_port_to_string(uint32_t io_port)
= QXL_IO_DESTROY_ALL_SURFACES_ASYNC,
[QXL_IO_FLUSH_SURFACES_ASYNC] = QXL_IO_FLUSH_SURFACES_ASYNC,
[QXL_IO_FLUSH_RELEASE] = QXL_IO_FLUSH_RELEASE,
+[QXL_IO_MONITORS_CONFIG_ASYNC] = QXL_IO_MONITORS_CONFIG_ASYNC,
};
return io_port_to_string[io_port];
}
@@ -819,6 +858,7 @@ static void interface_async_complete_io(PCIQXLDevice *qxl,
QXLCookie *cookie)
case QXL_IO_DESTROY_PRIMARY_ASYNC:
case QXL_IO_UPDATE_AREA_ASYNC:
case QXL_IO_FLUSH_SURFACES_ASYNC:
+case QXL_IO_MONITORS_CONFIG_ASYNC:
break;
case QXL_IO_CREATE_PRIMARY_ASYNC:
qxl_create_guest_primary_complete(qxl);
@@ -894,6 +934,8 @@ static void interface_async_complete(QXLInstance *sin,
uint64_t cookie_token)
case QXL_COOKIE_TYPE_RENDER_UPDATE_AREA:
qxl_render_update_area_done(qxl, cookie);
break;
+case QXL_COOKIE_TYPE_POST_LOAD_MONITORS_CONFIG:
+break;
default:
fprintf(stderr, qxl: %s: unexpected cookie type %d\n,
__func__, cookie-type);
@@ -1314,6 +1356,13 @@ static void ioport_write(void *opaque,
target_phys_addr_t addr,
return;
}
+if (d-revision = QXL_REVISION_STABLE_V10
+io_port = QXL_IO_FLUSH_SURFACES_ASYNC) {
+qxl_set_guest_bug(d, unsupported io %d for revision %d\n,
+io_port, d-revision);
+return;
+}
+
switch (io_port) {
case
Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
On Tue, Aug 21, 2012 at 7:31 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Aug 21, 2012 at 8:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
diff --git a/block_int.h b/block_int.h
index d72317f..a9d07a2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -333,6 +333,10 @@ struct BlockDriverState {
/* long-running background operation */
BlockJob *job;
+
+unsigned int max_sectors;
With 32 bit ints and even with 4k sector size, the maximum disk size
would be 16TB which may be soon exceeded by disks on the market.
Please use 64 bit values, probably also for segment values below.
This doesn't specify device size, it specifies max sectors per I/O
request. When reviewing, I checked that the Linux kernel also uses
unsigned int for these fields.
Stefan
Re: [Qemu-devel] [PATCH] Correct computation of bytes per pixel from bits per pixel
On 21 August 2012 22:32, BALATON Zoltan bala...@eik.bme.hu wrote: If you make the Subject console: Correct computation of bytes per pixel from bits per pixel it's easier to tell what bit of qemu the patch is dealing with. Signed-off-by: BALATON Zoltan bala...@eik.bme.hu --- console.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/console.c b/console.c index 4525cc7..f698b77 100644 --- a/console.c +++ b/console.c @@ -1612,7 +1612,7 @@ PixelFormat qemu_different_endianness_pixelformat(int bpp) memset(pf, 0x00, sizeof(PixelFormat)); pf.bits_per_pixel = bpp; -pf.bytes_per_pixel = bpp / 8; +pf.bytes_per_pixel = (bpp + 7) 3; You could write this as pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8); -- PMM
Re: [Qemu-devel] [PATCH] Add guest-get-hostname to retrieve the guests current hostname
On Wed, Aug 22, 2012 at 10:04:33AM +0200, Guido Günther wrote: On Tue, Aug 21, 2012 at 07:31:17PM +0100, Daniel P. Berrange wrote: On Tue, Aug 21, 2012 at 01:57:54PM +0200, Guido Günther wrote: [..snip..] Why no impl ? Winsock has the gethostname() API too $ grep gethostname /usr/i686-w64-mingw32/sys-root/mingw/include/*.h /usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h: WINSOCK_API_LINKAGE int WSAAPI gethostname(char *name,int namelen); This was mostly due to the lack of a test system. Are there any pointers on how to cross compile qemu-qa for Windows? Assuming you have the Mingw64 toolchain installed, then compilation is just a case of passing the --cross-prefix arg to configure. eg on Fedora 17 I would do: ./configure --target-list=x86_64-softmmu --cross-prefix=i686-w64-mingw32- which causes it to use i686-w64-mingw32-gcc as the compiler Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH 0/5] trace-cmd: Add a recorder readable feature for virtio-trace
Hi Steven,
The following patch set provides a feature which can read trace data of a guest
using virtio-trace (https://lkml.org/lkml/2012/8/9/210) for a recorder
function of trace-cmd. This patch set depends on the trace-agent running on a
guest in the virtio-trace system.
To translate raw data of a guest to text data on a host, information of debugfs
in the guest is also needed on the host. In other words, the guest's debugfs
must be exposed (mounted) on the host via other serial line (we don't like to
depend on network connection). For this purpose, we'll use DIOD 9pfs server
(http://code.google.com/p/diod/) as below.
***HOW TO USE***
We explain about how to translate raw data to text data on a host using
trace-cmd applied this patch set and virtio-trace.
- Preparation
1. Make FIFO in a host
virtio-trace uses virtio-serial pipe as trace data paths as to the number
of CPUs and a control path, so FIFO (named pipe) should be created as follows:
# mkdir /tmp/virtio-trace/
# mkfifo /tmp/virtio-trace/trace-path-cpu{0,1,2,...,X}.{in,out}
# mkfifo /tmp/virtio-trace/agent-ctl-path.{in,out}
Here, if we assign 1VCPU for a guest, then we set as follows:
trace-path-cpu0.{in.out}
and
agent-ctl-path.{in,out}.
2. Set up of virtio-serial pipe and unix in a host
Add qemu option to use virtio-serial pipe for tracing and unix for debugfs.
##virtio-serial device##
-device virtio-serial-pci,id=virtio-serial0\
##control path##
-chardev pipe,id=charchannel0,path=/tmp/virtio-trace/agent-ctl-path\
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,\
id=channel0,name=agent-ctl-path\
##data path##
-chardev pipe,id=charchannel1,path=/tmp/virtio-trace/trace-path-cpu0\
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,\
id=channel1,name=trace-path-cpu0\
##9pfs path##
-device virtio-serial \
-chardev socket,path=/tmp/virtio-trace/trace-9pfs,server,nowait, \
id=trace-9pfs \
-device virtserialport,chardev=trace-9pfs,name=virtioserial
If you manage guests with libvirt, add the following tags to domain XML files.
Then, libvirt passes the same command option to qemu.
channel type='pipe'
source path='/tmp/virtio-trace/agent-ctl-path'/
target type='virtio' name='agent-ctl-path'/
address type='virtio-serial' controller='0' bus='0' port='0'/
/channel
channel type='pipe'
source path='/tmp/virtio-trace/trace-path-cpu0'/
target type='virtio' name='trace-path-cpu0'/
address type='virtio-serial' controller='0' bus='0' port='1'/
/channel
channel type='unix'
source mode='bind' path='/tmp/virtio-trace/trace-9pfs'/
target type='virtio' name='trace-9pfs'/
address type='virtio-serial' controller='0' bus='0' port='2'/
/channel
Here, chardev names are restricted to trace-path-cpu0 and agent-ctl-path. UNIX
domain socket is automatically created on a host.
3. Boot the guest
You can find some chardev in /dev/virtio-ports/ in the guest.
4. Create symbolic link for trace-cmd on the host
# ln -s /tmp/virtio-trace/trace-path-cpu0.out \
/tmp/virtio-tracing/tracing/per_cpu/cpu0/trace_pipe_raw
5. Wait for 9pfs server on the host
# mount -t 9p -o trans=unix,access=any,uname=root, \
aname=/sys/kernel/debug,version=9p2000.L \
/tmp/virtio-trace/trace-9pfs /tmp/virtio-trace/debugfs
6. Run DIOD on the guest
# diod -E -Nn -u 0
7. Connect DIOD to virtio-console on the guest
# socat TCP4:127.0.0.1:564 /dev/virtio-ports/trace-9pfs
- Execution
1. Run trace-agent on the guest
# ./trace-agent
2. Execute trace-cmd on the host
# AGENT_READ_DIR=/tmp/virtio-trace/tracing \
AGENT_CTL=/tmp/virtio-trace/agent-ctl-path.in \
TRACE_DIR=/tmp/virtio-trace/debugfs/tracing \
./trace-cmd record -e sched:*
3. Translate raw data to text data on the host
# ./trace-cmd report trace.dat
***Just enhancement ideas***
- Support for trace-cmd = done
- Support for 9pfs protocol
- Support for non-blocking mode in QEMU
Thank you,
---
Masami Hiramatsu (2):
trace-cmd: Use tracing directory to count CPUs
trace-cmd: Use TRACE_DIR envrionment variable if defined
Yoshihiro YUNOMAE (3):
trace-cmd: Use polling function
trace-cmd: Add non-blocking option for open() and splice_read()
trace-cmd: Support trace-agent of virtio-trace
trace-cmd.h |1
trace-record.c | 41
trace-recorder.c | 112 --
trace-util.c | 27 +
4 files changed, 169 insertions(+), 12 deletions(-)
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
[Qemu-devel] [PATCH 1/5] trace-cmd: Use TRACE_DIR envrionment variable if defined
From: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Use TRACE_DIR environment variable for setting
debugfs/tracing directory if defined. This is
for controlling guest(or remote) ftrace.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-util.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/trace-util.c b/trace-util.c
index e128188..d5a3eb4 100644
--- a/trace-util.c
+++ b/trace-util.c
@@ -311,6 +311,15 @@ char *tracecmd_find_tracing_dir(void)
char type[100];
FILE *fp;
+ tracing_dir = getenv(TRACE_DIR);
+ if (tracing_dir) {
+ tracing_dir = strdup(tracing_dir);
+ if (!tracing_dir)
+ die(malloc);
+ warning(Use environmental tracing directory: %s\n,
tracing_dir);
+ return tracing_dir;
+ }
+
if ((fp = fopen(/proc/mounts,r)) == NULL) {
warning(Can't open /proc/mounts for read);
return NULL;
[Qemu-devel] [PATCH 2/5] trace-cmd: Use tracing directory to count CPUs
From: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Count debugfs/tracing/per_cpu/cpu* to determine the
number of CPUs.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-record.c | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/trace-record.c b/trace-record.c
index 9dc18a9..ed18951 100644
--- a/trace-record.c
+++ b/trace-record.c
@@ -1179,6 +1179,41 @@ static void expand_event_list(void)
}
}
+static int count_tracingdir_cpus(void)
+{
+ char *tracing_dir = NULL;
+ char *percpu_dir = NULL;
+ struct dirent **namelist;
+ int count = 0, n;
+
+ /* Count cpus in per_cpu directory */
+ tracing_dir = tracecmd_find_tracing_dir();
+ if (!tracing_dir)
+ return 0;
+ percpu_dir = malloc_or_die(strlen(tracing_dir) + 9);
+ if (!percpu_dir)
+ goto err;
+
+ sprintf(percpu_dir, %s/per_cpu, tracing_dir);
+
+ n = scandir(percpu_dir, namelist, NULL, alphasort);
+ if (n 0) {
+ while (n--) {
+ if (strncmp(cpu, namelist[n]-d_name, 3) == 0)
+ count++;
+ free(namelist[n]);
+ }
+ free(namelist);
+ }
+
+ if (percpu_dir)
+ free(percpu_dir);
+err:
+ if (tracing_dir)
+ free(tracing_dir);
+ return count;
+}
+
static int count_cpus(void)
{
FILE *fp;
@@ -1189,6 +1224,12 @@ static int count_cpus(void)
size_t n;
int r;
+ cpus = count_tracingdir_cpus();
+ if (cpus 0)
+ return cpus;
+
+ warning(failed to use tracing_dir to determine number of CPUS);
+
cpus = sysconf(_SC_NPROCESSORS_CONF);
if (cpus 0)
return cpus;
[Qemu-devel] [PATCH 5/5] trace-cmd: Use polling function
Use poll() for avoiding a busy loop to read trace data of a guest from FIFO.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-recorder.c | 42 --
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/trace-recorder.c b/trace-recorder.c
index 6577fe8..bdf9798 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -34,9 +34,12 @@
#include ctype.h
#include errno.h
#include stdbool.h
+#include poll.h
#include trace-cmd.h
+#define WAIT_MSEC 1
+
struct tracecmd_recorder {
int fd;
int trace_fd;
@@ -235,9 +238,37 @@ static void stop_operation_to_trace_agent(int ctl_fd)
operation_to_trace_agent(ctl_fd, false);
}
-int tracecmd_start_recording(struct tracecmd_recorder *recorder, unsigned long
sleep)
+static int wait_data(struct tracecmd_recorder *recorder, unsigned long sleep)
{
+ struct pollfd poll_fd;
struct timespec req;
+ int ret = 0;
+
+ if (recorder-agent_existing) {
+ poll_fd.fd = recorder-trace_fd;
+ poll_fd.events = POLLIN;
+ while (1) {
+ ret = poll(poll_fd, 1, WAIT_MSEC);
+
+ if(ret 0) {
+ warning(polling error);
+ return ret;
+ }
+
+ if (ret)
+ break;
+ }
+ } else if (sleep) {
+ req.tv_sec = sleep / 100;
+ req.tv_nsec = (sleep % 100) * 1000;
+ nanosleep(req, NULL);
+ }
+
+ return ret;
+}
+
+int tracecmd_start_recording(struct tracecmd_recorder *recorder, unsigned long
sleep)
+{
long ret;
recorder-stop = 0;
@@ -246,11 +277,10 @@ int tracecmd_start_recording(struct tracecmd_recorder
*recorder, unsigned long s
run_operation_to_trace_agent(recorder-ctl_fd);
do {
- if (sleep) {
- req.tv_sec = sleep / 100;
- req.tv_nsec = (sleep % 100) * 1000;
- nanosleep(req, NULL);
- }
+ ret = wait_data(recorder, sleep);
+ if (ret 0)
+ return ret;
+
ret = splice_data(recorder);
if (ret 0)
return ret;
[Qemu-devel] [PATCH 4/5] trace-cmd: Add non-blocking option for open() and splice_read()
Add non-blocking option for open() and splice_read() for avoiding block to read
trace data of a guest from FIFO.
If SIGINT comes to read/write processes from the parent process in the case
where FIFO as a read I/F is assigned, then reading is normally blocked for
splice_read(). So, we added nonblock option to open() and splice_read().
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-recorder.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/trace-recorder.c b/trace-recorder.c
index 3b750e9..6577fe8 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -124,7 +124,7 @@ struct tracecmd_recorder *tracecmd_create_recorder_fd(int
fd, int cpu)
goto out_free;
sprintf(path, %s/per_cpu/cpu%d/trace_pipe_raw, tracing, cpu);
- recorder-trace_fd = open(path, O_RDONLY);
+ recorder-trace_fd = open(path, O_RDONLY | O_NONBLOCK);
if (recorder-trace_fd 0)
goto out_free;
@@ -172,14 +172,17 @@ static long splice_data(struct tracecmd_recorder
*recorder)
long ret;
ret = splice(recorder-trace_fd, NULL, recorder-brass[1], NULL,
-recorder-page_size, 1 /* SPLICE_F_MOVE */);
+recorder-page_size, SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
if (ret 0) {
- warning(recorder error in splice input);
- return -1;
+ if (errno != EAGAIN) {
+ warning(recorder error in splice input);
+ return -1;
+ }
+ return 0; /* Buffer is empty */
}
ret = splice(recorder-brass[0], NULL, recorder-fd, NULL,
-recorder-page_size, 3 /* and NON_BLOCK */);
+recorder-page_size, SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
if (ret 0) {
if (errno != EAGAIN) {
warning(recorder error in splice output);
[Qemu-devel] [PATCH 3/5] trace-cmd: Support trace-agent of virtio-trace
Add read path and control path to use trace-agent of virtio-trace.
When we use trace-agent, trace-cmd will be used as follows:
# AGENT_READ_DIR=/tmp/virtio-trace/tracing \
AGENT_CTL=/tmp/virtio-trace/agent-ctl-path.in \
TRACING_DIR=/tmp/virtio-trace/debugfs/tracing \
trace-cmd record -e sched:*
Here, AGENT_READ_DIR is the path for a reading directory of virtio-trace,
AGENT_CTL is a control path of trace-agent, and TRACING_DIR is a debugfs path
of a guest.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-cmd.h |1 +
trace-recorder.c | 57 +-
trace-util.c | 18 +
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/trace-cmd.h b/trace-cmd.h
index f904dc5..75506ed 100644
--- a/trace-cmd.h
+++ b/trace-cmd.h
@@ -72,6 +72,7 @@ static inline int tracecmd_host_bigendian(void)
}
char *tracecmd_find_tracing_dir(void);
+char *guest_agent_tracing_read_dir(void);
/* --- Opening and Reading the trace.dat file --- */
diff --git a/trace-recorder.c b/trace-recorder.c
index 215affc..3b750e9 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -33,6 +33,7 @@
#include unistd.h
#include ctype.h
#include errno.h
+#include stdbool.h
#include trace-cmd.h
@@ -43,6 +44,8 @@ struct tracecmd_recorder {
int page_size;
int cpu;
int stop;
+ int ctl_fd;
+ boolagent_existing;
};
void tracecmd_free_recorder(struct tracecmd_recorder *recorder)
@@ -59,11 +62,29 @@ void tracecmd_free_recorder(struct tracecmd_recorder
*recorder)
free(recorder);
}
+static char *use_trace_agent_dir(char *ctl_path,
+ struct tracecmd_recorder *recorder)
+{
+ ctl_path = strdup(ctl_path);
+ if (!ctl_path)
+ die(malloc);
+ warning(Use environmental control path: %s\n, ctl_path);
+
+ recorder-ctl_fd = open(ctl_path, O_WRONLY);
+ if (recorder-ctl_fd 0)
+ return NULL;
+
+ recorder-agent_existing = true;
+
+ return guest_agent_tracing_read_dir();
+}
+
struct tracecmd_recorder *tracecmd_create_recorder_fd(int fd, int cpu)
{
struct tracecmd_recorder *recorder;
char *tracing = NULL;
char *path = NULL;
+ char *ctl_path = NULL;
int ret;
recorder = malloc_or_die(sizeof(*recorder));
@@ -76,12 +97,23 @@ struct tracecmd_recorder *tracecmd_create_recorder_fd(int
fd, int cpu)
recorder-trace_fd = -1;
recorder-brass[0] = -1;
recorder-brass[1] = -1;
+ recorder-ctl_fd = -1;
+ recorder-agent_existing = false;
recorder-page_size = getpagesize();
recorder-fd = fd;
- tracing = tracecmd_find_tracing_dir();
+ /*
+* The trace-agent on a guest is controlled to run or stop by a host,
+* so we need to assign the control path of the trace-agent to use
+* virtio-trace.
+*/
+ ctl_path = getenv(AGENT_CTL);
+ if (ctl_path)
+ tracing = use_trace_agent_dir(ctl_path, recorder);
+ else
+ tracing = tracecmd_find_tracing_dir();
if (!tracing) {
errno = ENODEV;
goto out_free;
@@ -182,6 +214,24 @@ long tracecmd_flush_recording(struct tracecmd_recorder
*recorder)
return total;
}
+static void operation_to_trace_agent(int ctl_fd, bool run_agent)
+{
+ if (run_agent == true)
+ write(ctl_fd, 1, 2);
+ else
+ write(ctl_fd, 0, 2);
+}
+
+static void run_operation_to_trace_agent(int ctl_fd)
+{
+ operation_to_trace_agent(ctl_fd, true);
+}
+
+static void stop_operation_to_trace_agent(int ctl_fd)
+{
+ operation_to_trace_agent(ctl_fd, false);
+}
+
int tracecmd_start_recording(struct tracecmd_recorder *recorder, unsigned long
sleep)
{
struct timespec req;
@@ -189,6 +239,9 @@ int tracecmd_start_recording(struct tracecmd_recorder
*recorder, unsigned long s
recorder-stop = 0;
+ if (recorder-agent_existing)
+ run_operation_to_trace_agent(recorder-ctl_fd);
+
do {
if (sleep) {
req.tv_sec = sleep / 100;
@@ -214,6 +267,8 @@ void tracecmd_stop_recording(struct tracecmd_recorder
*recorder)
if (!recorder)
return;
+ if (recorder-agent_existing)
+ stop_operation_to_trace_agent(recorder-ctl_fd);
recorder-stop = 1;
}
diff --git a/trace-util.c b/trace-util.c
index d5a3eb4..ff639be 100644
--- a/trace-util.c
+++ b/trace-util.c
@@ -304,6 +304,24 @@ static int mount_debugfs(void)
return ret;
}
+char *guest_agent_tracing_read_dir(void)
+{
+ char *tracing_read_dir;
+
+ tracing_read_dir = getenv(AGENT_READ_DIR);
+ if (tracing_read_dir) {
+
Re: [Qemu-devel] [RFC 0/8] include qdev core in *-user, make CPU child of DeviceState
On 08/21/2012 06:42 PM, Eduardo Habkost wrote:
So, here's a third suggestion to the CPU/DeviceState problem. Basically I
split
the qdev code into a core (that can be easily compiled into *-user), and a
part
specific to qemu-system-*.
I'm barging in late here, so sorry if this has been suggested and shot
down: is it not possible to use composition here?
typedef ... CPU;
typedef struct CPUState {
DeviceState qdev;
CPU cpu;
} CPUState;
But I guess bringing qdev to -user is inevitable.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/21/2012 06:21 PM, Richard Davies wrote: Avi Kivity wrote: Richard Davies wrote: We're running host kernel 3.5.1 and qemu-kvm 1.1.1. I hadn't though about it, but I agree this is related to cpu overcommit. The slow boots are intermittent (and infrequent) with cpu overcommit whereas I don't think it occurs without cpu overcommit. In addition, if there is a slow boot ongoing, and you kill some other VMs to reduce cpu overcommit then this will sometimes speed it up. I guess the question is why even with overcommit most boots are fine, but some small fraction then go slow? Could be a bug. The scheduler and the spin-loop handling code fight each other instead of working well. Please provide snapshots of 'perf top' while a slow boot is in progress. Below are two 'perf top' snapshots during a slow boot, which appear to me to support your idea of a spin-lock problem. There are a lot more unprocessable samples recorded messages at the end of each snapshot which I haven't included. I think these may be from the guest OS - the kernel is listed, and qemu-kvm itself is listed on some other traces which I did, although not these. Richard. PerfTop: 62249 irqs/sec kernel:96.9% exact: 0.0% [4000Hz cycles], (all, 16 CPUs) 35.80% [kernel] [k] _raw_spin_lock_irqsave 21.64% [kernel] [k] isolate_freepages_block Please disable ksm, and if this function persists in the profile, reduce some memory from the guests. 5.91% [kernel] [k] yield_to 4.95% [kernel] [k] _raw_spin_lock 3.37% [kernel] [k] kvm_vcpu_on_spin Except for isolate_freepages_block, all functions up to here have to do with dealing with cpu overcommit. But let's deal with them after we see a profile with isolate_freepages_block removed. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2 1/3] net: asynchronous send/receive infrastructure for net/socket.c
On Tue, Aug 21, 2012 at 5:39 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote: In net_socket_update_fd_handler() shouldnt you call qemu_notify_event() if any of the handlers have changed from NULL to non-NULL ? or else it might take a while before the change takes effect. In this case it's not necessary: net_socket_send()/net_socket_send_dgram()/net_socket_writable() are called as fd handlers and therefore we know the event loop isn't stuck in select(2). Stefan
[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler
OK, I'll re-read the documentation maybe I am wrong!
It does say synchronous in the description and I don't understand how it can
work if it is asynchronous because for Cortex the SVC argument is not
transfered to a register and the only way the exception code can access it is
by reading it from the opcode. If the exception is asynchonous the PC may have
moved on and the code won't be able to find the SVC opcode?!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
New
Bug description:
The svc instruction doesn't work as expected.
- qemu 0.13.0 rc1 (git)
Test : demo with freeRTOS (for example
FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
If we start the scheduler, it will call that function (__attribute__
(( naked ))) :
void vPortStartFirstTask( void )
{
__asm volatile(
ldr r0, =0xE000ED08 \n /*
Use the NVIC offset register to locate the stack. */
ldr r0, [r0]
\n
ldr r0, [r0]
\n
msr msp, r0
\n /* Set the msp back to the start of the stack. */
svc 0
\n /* System call to start first task. */
);
}
The 4 first lines in asm work fine. The scv 0 call will rise the right
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will
never call the PendSV Handler (xPortPendSVHandler here). This function is
recorded in the nvic vector.
Next, (after the svc), the processor will execute the line after in code
(this is a naked function) so the next function written after
vPortStartFirstTask in the code.
command line :
console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
console 2 : arm-none-eabi-gdb -ex target remote localhost:1234
gcc/RTOSDemo.axf
arm-none-eabi from
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
Same error with another project with arm-elf
processor : arm cortex m3
host : gentoo (2.6.35-r9) (without kqemu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/657006/+subscriptions
[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler
In particular table 2-16 of DUI0552A_Cortex_m3_dgug.pdf states that the
Activation of the SVC exception is Synchronous.
And after the table it states For an asynchronous exception, other than reset,
the processor can execute another instruction
between when the exception is triggered and when the processor enters the
exception handler. which sort of implies that for a Synchronous exception
another opcode can not be executed before the exception?!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
New
Bug description:
The svc instruction doesn't work as expected.
- qemu 0.13.0 rc1 (git)
Test : demo with freeRTOS (for example
FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
If we start the scheduler, it will call that function (__attribute__
(( naked ))) :
void vPortStartFirstTask( void )
{
__asm volatile(
ldr r0, =0xE000ED08 \n /*
Use the NVIC offset register to locate the stack. */
ldr r0, [r0]
\n
ldr r0, [r0]
\n
msr msp, r0
\n /* Set the msp back to the start of the stack. */
svc 0
\n /* System call to start first task. */
);
}
The 4 first lines in asm work fine. The scv 0 call will rise the right
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will
never call the PendSV Handler (xPortPendSVHandler here). This function is
recorded in the nvic vector.
Next, (after the svc), the processor will execute the line after in code
(this is a naked function) so the next function written after
vPortStartFirstTask in the code.
command line :
console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
console 2 : arm-none-eabi-gdb -ex target remote localhost:1234
gcc/RTOSDemo.axf
arm-none-eabi from
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
Same error with another project with arm-elf
processor : arm cortex m3
host : gentoo (2.6.35-r9) (without kqemu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/657006/+subscriptions
[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler
Yes, I'm not disputing that the SVC exception should be handled
synchronously, I'm asking you to provide a test case demonstrating the
wrong behaviour.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
New
Bug description:
The svc instruction doesn't work as expected.
- qemu 0.13.0 rc1 (git)
Test : demo with freeRTOS (for example
FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
If we start the scheduler, it will call that function (__attribute__
(( naked ))) :
void vPortStartFirstTask( void )
{
__asm volatile(
ldr r0, =0xE000ED08 \n /*
Use the NVIC offset register to locate the stack. */
ldr r0, [r0]
\n
ldr r0, [r0]
\n
msr msp, r0
\n /* Set the msp back to the start of the stack. */
svc 0
\n /* System call to start first task. */
);
}
The 4 first lines in asm work fine. The scv 0 call will rise the right
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will
never call the PendSV Handler (xPortPendSVHandler here). This function is
recorded in the nvic vector.
Next, (after the svc), the processor will execute the line after in code
(this is a naked function) so the next function written after
vPortStartFirstTask in the code.
command line :
console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
console 2 : arm-none-eabi-gdb -ex target remote localhost:1234
gcc/RTOSDemo.axf
arm-none-eabi from
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
Same error with another project with arm-elf
processor : arm cortex m3
host : gentoo (2.6.35-r9) (without kqemu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/657006/+subscriptions
Re: [Qemu-devel] setting up breakpoints - kernel debugging help wit gdb in qemu-kvm
Hi... On Wed, Aug 22, 2012 at 6:53 AM, Onkar kern...@gmail.com wrote: # ./qemu-system-x86_64 -m 2048 -smp 4 -vga std -vnc :5 -drive file=/sda4/bin/disk/disk0.img,cache=writeback -S -s (gdb) symbol-file /sda4/kvm/vmlinux Reading symbols from /sda4/kvm/vmlinux...done. (gdb) target remote :1234 Remote debugging using :1234 0x in ?? () (gdb) b kmem_cache_alloc Breakpoint 1 at 0x81121adb: file mm/slub.c, line 2375. (2 locations) (gdb) c can you re run with out using -smp (IOW, just use one CPU)? Also, which qemu version do you use? is this with or without KVM? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Re: [Qemu-devel] x86, nops settings result in kernel crash
On 08/21/2012 12:28 PM, Tomas Racek wrote:
http://fi.muni.cz/~xracek/debian2.img.bz2
Other things are the same.
The runtest.sh sets environment for xfstests and runs test 285 which I wrote
and and which should test if FS sends discard requests only on free sectors:
285:
1. Create loop device and FS on it.
2. Populate it with some garbage.
3. Get free sectors from FS.
4. Run fstrim and look for discard requests via blk tracer.
5. Compare free sectors to discard requests.
The test itself can have some issues but I'm pretty sure it shouldn't crash
the system. ;-)
Does the following patch help?
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index afb7ff7..ced4534 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -165,7 +165,7 @@ static int __init setup_noreplace_paravirt(char *str)
#endif
#ifdef P6_NOP1
-static const unsigned char __initconst_or_module p6nops[] =
+static const unsigned char p6nops[] =
{
P6_NOP1,
P6_NOP2,
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] x86, alternative: fix p6 nops on non-modular kernels
On 08/22/2012 12:54 PM, Avi Kivity wrote:
On 08/21/2012 12:28 PM, Tomas Racek wrote:
http://fi.muni.cz/~xracek/debian2.img.bz2
Other things are the same.
The runtest.sh sets environment for xfstests and runs test 285 which I wrote
and and which should test if FS sends discard requests only on free sectors:
285:
1. Create loop device and FS on it.
2. Populate it with some garbage.
3. Get free sectors from FS.
4. Run fstrim and look for discard requests via blk tracer.
5. Compare free sectors to discard requests.
The test itself can have some issues but I'm pretty sure it shouldn't crash
the system. ;-)
Does the following patch help?
It's obvious that it should. You're running a non-modular kernel, and those
nops are discarded (probably a leftover from the days patching was a boot-only
activity), so the kernel patched garbage over its own code.
---8cut-here-8---
From: Avi Kivity a...@redhat.com
Date: Wed, 22 Aug 2012 12:58:18 +0300
Subject: [PATCH] x86, alternative: fix p6 nops on non-modular kernels
Probably a leftover from the early days of self-patching, p6nops are
marked __initconst_or_module, which causes them to be discarded in a
non-modular kernel. If something later triggers patching, it will
overwrite kernel code with garbage.
Reported-by: Tomas Racek tra...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index afb7ff7..ced4534 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -165,7 +165,7 @@ static int __init setup_noreplace_paravirt(char *str)
#endif
#ifdef P6_NOP1
-static const unsigned char __initconst_or_module p6nops[] =
+static const unsigned char p6nops[] =
{
P6_NOP1,
P6_NOP2,
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] xen-all.c: fix multiply issue for int and uint types
On Wed, 22 Aug 2012, Dongxiao Xu wrote:
If the two multiply operands are int and uint types separately,
the int type will be transformed to uint firstly, which is not the
intent in our code piece. The fix is to add (int64_t) transform
for the uint type before the multiply.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
xen-all.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 61def2e..f76b051 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -712,7 +712,8 @@ static void cpu_ioreq_pio(ioreq_t *req)
for (i = 0; i req-count; i++) {
tmp = do_inp(req-addr, req-size);
-cpu_physical_memory_write(req-data + (sign * i * req-size),
+cpu_physical_memory_write(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t *) tmp, req-size);
}
}
@@ -723,7 +724,8 @@ static void cpu_ioreq_pio(ioreq_t *req)
for (i = 0; i req-count; i++) {
uint32_t tmp = 0;
-cpu_physical_memory_read(req-data + (sign * i * req-size),
+cpu_physical_memory_read(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
do_outp(req-addr, req-size, tmp);
}
@@ -740,12 +742,14 @@ static void cpu_ioreq_move(ioreq_t *req)
if (!req-data_is_ptr) {
if (req-dir == IOREQ_READ) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-addr + (sign * i * req-size),
+cpu_physical_memory_read(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t *) req-data, req-size);
}
} else if (req-dir == IOREQ_WRITE) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_write(req-addr + (sign * i * req-size),
+cpu_physical_memory_write(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t *) req-data, req-size);
}
}
@@ -754,16 +758,20 @@ static void cpu_ioreq_move(ioreq_t *req)
if (req-dir == IOREQ_READ) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-addr + (sign * i * req-size),
+cpu_physical_memory_read(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
-cpu_physical_memory_write(req-data + (sign * i * req-size),
+cpu_physical_memory_write(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
}
} else if (req-dir == IOREQ_WRITE) {
for (i = 0; i req-count; i++) {
-cpu_physical_memory_read(req-data + (sign * i * req-size),
+cpu_physical_memory_read(
+req-data + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
-cpu_physical_memory_write(req-addr + (sign * i * req-size),
+cpu_physical_memory_write(
+req-addr + (sign * i * (int64_t)req-size),
(uint8_t*) tmp, req-size);
}
}
--
1.7.1
Re: [Qemu-devel] [PATCH] vmware_vga: Cleanup and allow simple drivers to work without the fifo
On Wed, 22 Aug 2012, Jan Kiszka wrote: This is a rather big patch. I strongly suspect you can break it up into smaller pieces that address separate aspects one-by-one. Also, it is definitely to heavy for qemu-trivial. Despite its size the changes included are fairly simple but I can try to break it up. I've sent it to qemu-trivial because it may meet the Do not fall under an actively maintained subsystem. category as I've found no maintainer for this part. Should I send the revisions only to qemu-devel then? Thanks, BALATON Zoltan
[Qemu-devel] [PULL] Xen fixes 2012-08-22
Hi Anthony, please pull two fixes to xen-all.c: git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-fixes-20120822 Dongxiao Xu (1): xen-all.c: fix multiply issue for int and uint types Frediano Ziglio (1): Fix invalidate if memory requested was not bucket aligned xen-all.c | 24 xen-mapcache.c |9 + 2 files changed, 21 insertions(+), 12 deletions(-) Cheers, Stefano
Re: [Qemu-devel] setting up breakpoints - kernel debugging help wit gdb in qemu-kvm
On 2012-08-22 01:53, Onkar wrote: I am running a linux guest like this - which I wish to debug - but the breakpoint gets set but I am not able to stop the guest execution at the set breakpoint - it just hangs after I do continue. Can you please provide me some clues - # ./qemu-system-x86_64 -m 2048 -smp 4 -vga std -vnc :5 -drive file=/sda4/bin/disk/disk0.img,cache=writeback -S -s # gdb GNU gdb (GDB) Fedora (7.2-52.fc14) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. The target architecture is assumed to be i386:x86-64:intel (gdb) symbol-file /sda4/kvm/vmlinux Reading symbols from /sda4/kvm/vmlinux...done. (gdb) target remote :1234 Remote debugging using :1234 0x in ?? () (gdb) b kmem_cache_alloc Breakpoint 1 at 0x81121adb: file mm/slub.c, line 2375. (2 locations) (gdb) c Continuing. In KVM mode, soft-breakpoints can only be set when the kernel is already loaded. The reason is that it injects a trap instruction in the guest code, and that instruction will be overwritten during boot. Use a hardware breakpoint instead, or interrupt the guest before the interesting code is executed but after the kernel is loaded. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
[Qemu-devel] [Qemu-ppc][PATCH v9 1/1] Add USB option in machine options
When -usb option is used, global varible usb_enabled is set.
And all the plafrom will create one USB controller according
to this variable. In fact, global varibles make code hard
to read.
So this patch is to remove global variable usb_enabled and
add USB option in machine options. All the plaforms will get
USB option value from machine options.
USB option of machine options will be set either by:
* -usb
* -machine type=pseries,usb=on
Both these ways can work now. They both set USB option in
machine options. In the future, the first way will be removed.
Signed-off-by: Li Zhang zhlci...@linux.vnet.ibm.com
---
v7-v8 :
* Declare usb_enabled() and set_usb_option() in sysemu.h
* Separate USB enablement on sPAPR platform.
v8-v9:
* Fix usb_enable() default value on sPAPR and MAC99
Signed-off-by: Li Zhang zhlci...@linux.vnet.ibm.com
diff --git a/hw/nseries.c b/hw/nseries.c
index 4df2670..c67e95a 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1322,7 +1322,7 @@ static void n8x0_init(ram_addr_t ram_size, const char
*boot_device,
n8x0_dss_setup(s);
n8x0_cbus_setup(s);
n8x0_uart_setup(s);
-if (usb_enabled)
+if (usb_enabled(false))
n8x0_usb_setup(s);
if (kernel_filename) {
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0c0096f..b662192 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -267,7 +267,7 @@ static void pc_init1(MemoryRegion *system_memory,
pc_cmos_init(below_4g_mem_size, above_4g_mem_size, boot_device,
floppy, idebus[0], idebus[1], rtc_state);
-if (pci_enabled usb_enabled) {
+if (pci_enabled usb_enabled(false)) {
pci_create_simple(pci_bus, piix3_devfn + 2, piix3-usb-uhci);
}
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index e95cfe8..1d4f494 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -348,10 +348,6 @@ static void ppc_core99_init (ram_addr_t ram_size,
ide_mem[1] = pmac_ide_init(hd, pic[0x0d], dbdma, 0x16, pic[0x02]);
ide_mem[2] = pmac_ide_init(hd[MAX_IDE_DEVS], pic[0x0e], dbdma, 0x1a,
pic[0x02]);
-/* cuda also initialize ADB */
-if (machine_arch == ARCH_MAC99_U3) {
-usb_enabled = 1;
-}
cuda_init(cuda_mem, pic[0x19]);
adb_kbd_init(adb_bus);
@@ -360,15 +356,14 @@ static void ppc_core99_init (ram_addr_t ram_size,
macio_init(pci_bus, PCI_DEVICE_ID_APPLE_UNI_N_KEYL, 0, pic_mem,
dbdma_mem, cuda_mem, NULL, 3, ide_mem, escc_bar);
-if (usb_enabled) {
+if (usb_enabled(machine_arch == ARCH_MAC99_U3)) {
pci_create_simple(pci_bus, -1, pci-ohci);
-}
-
-/* U3 needs to use USB for input because Linux doesn't support via-cuda
- on PPC64 */
-if (machine_arch == ARCH_MAC99_U3) {
-usbdevice_create(keyboard);
-usbdevice_create(mouse);
+/* U3 needs to use USB for input because Linux doesn't support via-cuda
+on PPC64 */
+if (machine_arch == ARCH_MAC99_U3) {
+usbdevice_create(keyboard);
+usbdevice_create(mouse);
+}
}
if (graphic_depth != 15 graphic_depth != 32 graphic_depth != 8)
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 1dcd8a6..1468a32 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -286,7 +286,7 @@ static void ppc_heathrow_init (ram_addr_t ram_size,
macio_init(pci_bus, PCI_DEVICE_ID_APPLE_343S1201, 1, pic_mem,
dbdma_mem, cuda_mem, nvr, 2, ide_mem, escc_bar);
-if (usb_enabled) {
+if (usb_enabled(false)) {
pci_create_simple(pci_bus, -1, pci-ohci);
}
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 7a87616..feeb903 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -662,7 +662,7 @@ static void ppc_prep_init (ram_addr_t ram_size,
memory_region_add_subregion(sysmem, 0xFEFF, xcsr);
#endif
-if (usb_enabled) {
+if (usb_enabled(false)) {
pci_create_simple(pci_bus, -1, pci-ohci);
}
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index d5f1420..4787279 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -2108,7 +2108,7 @@ PXA2xxState *pxa270_init(MemoryRegion *address_space,
s-ssp[i] = (SSIBus *)qdev_get_child_bus(dev, ssi);
}
-if (usb_enabled) {
+if (usb_enabled(false)) {
sysbus_create_simple(sysbus-ohci, 0x4c00,
qdev_get_gpio_in(s-pic, PXA2XX_PIC_USBH1));
}
@@ -2239,7 +2239,7 @@ PXA2xxState *pxa255_init(MemoryRegion *address_space,
unsigned int sdram_size)
s-ssp[i] = (SSIBus *)qdev_get_child_bus(dev, ssi);
}
-if (usb_enabled) {
+if (usb_enabled(false)) {
sysbus_create_simple(sysbus-ohci, 0x4c00,
qdev_get_gpio_in(s-pic, PXA2XX_PIC_USBH1));
}
diff --git a/hw/realview.c b/hw/realview.c
index 19db4d0..a8d6f97 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -227,7 +227,7 @@ static void realview_init(ram_addr_t ram_size,
sysbus_connect_irq(busdev, 2, pic[50]);
sysbus_connect_irq(busdev,
Re: [Qemu-devel] [PATCH] x86, alternative: fix p6 nops on non-modular kernels
- Original Message -
On 08/22/2012 12:54 PM, Avi Kivity wrote:
On 08/21/2012 12:28 PM, Tomas Racek wrote:
http://fi.muni.cz/~xracek/debian2.img.bz2
Other things are the same.
The runtest.sh sets environment for xfstests and runs test 285
which I wrote and and which should test if FS sends discard
requests only on free sectors:
285:
1. Create loop device and FS on it.
2. Populate it with some garbage.
3. Get free sectors from FS.
4. Run fstrim and look for discard requests via blk tracer.
5. Compare free sectors to discard requests.
The test itself can have some issues but I'm pretty sure it
shouldn't crash the system. ;-)
Does the following patch help?
It's obvious that it should. You're running a non-modular kernel,
and those nops are discarded (probably a leftover from the days
patching was a boot-only activity), so the kernel patched garbage
over its own code.
Works fine. Thank you!
Tom
---8cut-here-8---
From: Avi Kivity a...@redhat.com
Date: Wed, 22 Aug 2012 12:58:18 +0300
Subject: [PATCH] x86, alternative: fix p6 nops on non-modular kernels
Probably a leftover from the early days of self-patching, p6nops are
marked __initconst_or_module, which causes them to be discarded in a
non-modular kernel. If something later triggers patching, it will
overwrite kernel code with garbage.
Reported-by: Tomas Racek tra...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kernel/alternative.c
b/arch/x86/kernel/alternative.c
index afb7ff7..ced4534 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -165,7 +165,7 @@ static int __init setup_noreplace_paravirt(char
*str)
#endif
#ifdef P6_NOP1
-static const unsigned char __initconst_or_module p6nops[] =
+static const unsigned char p6nops[] =
{
P6_NOP1,
P6_NOP2,
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 988291] Re: virsh -c qemu+ssh://root@source/system migrate --domain client --desturi qemu+ssh://root@destination/system fails
*** This bug is a duplicate of bug 989452 *** https://bugs.launchpad.net/bugs/989452 He means disabling kerberos authentication in your SSH client config, whether it be globally in /etc/ssh/ssh_config or ~/.ssh/config, assuming you're using qemu+ssh:// to migrate your VMs. Either way, this does not work for me. I can reproduce this error with: # virsh migrate --live --verbose --persistent --copy-storage-all vm1 qemu+ssh://aa...@kvm1.example.com/system -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/988291 Title: virsh -c qemu+ssh://root@source/system migrate --domain client --desturi qemu+ssh://root@destination/system fails Status in QEMU: New Status in “libvirt” package in Ubuntu: Confirmed Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: After upgrading from Ubuntu 11.10 to 12.04 migrating a VM from a not migrated host (Ubuntu 11.10) to a migrated host (Ubuntu 12.04) fails: Only error message found: qemuMigrationUpdateJobStatus:890 : operation failed: migration job: unexpectedly failed Ubuntu 11.10 uses: libvirt-bin 0.9.2 Ubuntu 12.04 uses: libvirt-bin 0.9.8 ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libvirt-bin 0.9.8-2ubuntu17 Uname: Linux 3.2.16 x86_64 ApportVersion: 2.0.1-0ubuntu5 Architecture: amd64 Date: Wed Apr 25 14:12:29 2012 InstallationMedia: Ubuntu-Server 10.10 Maverick Meerkat - Release amd64 (20101007) ProcEnviron: TERM=screen-bce SHELL=/bin/bash PATH=(custom, user) LANG=de_DE.UTF-8 SourcePackage: libvirt UpgradeStatus: Upgraded to precise on 2012-04-25 (0 days ago) mtime.conffile..etc.apparmor.d.usr.lib.libvirt.virt.aa.helper: 2012-04-25T12:40:42.878700 mtime.conffile..etc.default.libvirt.bin: 2011-01-25T16:19:29.769778 mtime.conffile..etc.libvirt.libvirtd.conf: 2012-04-25T13:57:06.138857 mtime.conffile..etc.libvirt.lxc.conf: 2011-01-25T16:11:34.670971 mtime.conffile..etc.libvirt.qemu.conf: 2012-04-25T12:18:38.835193 mtime.conffile..etc.sasl2.libvirt.conf: 2011-01-26T17:57:01 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/988291/+subscriptions
Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
On 08/21/2012 06:14 PM, Paolo Bonzini wrote: Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto: Using /sys/dev/block or /sys/dev/char seems easier, and lets you retrieve the parameters for block devices too. what do you mean with block devices? Using /dev/sda instead of /dev/sg0? Yes. However, I'm worried of the consequences this has for migration. You could have the same physical disk accessed with two different HBAs, with different limits. So I don't know if this can really be solved at all. I know little about qemu migration now. The pending scsi commands will be saved and transfered to remote machine when starting migration? Passthrough is already a migration blocker if both hosts do not have access to the same LUNs. Yes, but requiring the exact same hardware may be too much. I'm trying to understand the problem better before committing to a threefold spec/qemu/kernel change. Cong, what is the limit that the host HBA enforces (and what is the HBA)? What commands see a problem? Is it fixed by using scsi-block instead of scsi-generic (if you can use scsi-block at all, i.e. it's not a tape or similar device)? I don't see real problem caused by the the queue limits actually. It's a bug which Stefan told me. With scsi-generic, QEMU uses a bounce buffer for non-I/O commands to a SCSI passthrough device, so the only problem in that case should be the maximum segment size. This could change in the future, but max_segments and max_sectors should not yet be a problem. about bounce buffer, do you meat the buffer allocated in scsi_send_command() of hw/scsi-generic.c? Cong. With scsi-block, QEMU will use read/write on the block device and the host kernel will then obey the host HBA's block limits. QEMU will still use a bounce buffer for non-I/O commands to a scsi-block device, but the payload is usually small for non-I/O commands. Paolo When both hosts do have access to the same LUNs it's possible to extract the block queue limits (using sysfs) and compare them. Today you can start QEMU with different image files on both hosts. Migration will appear to work but the disk image on the destination host could be junk. This is a similar case, I don't see a problem except that there should be a safety check (maybe at the libvirt level) to make this safe.
[Qemu-devel] [PATCH v4] configure: properly check if -lrt and -lm is needed
Fixes build against uClibc.
uClibc provides 2 versions of clock_gettime(), one with realtime
support and one without (this is so you can avoid linking in -lrt
unless actually needed). This means that the clock_gettime() don't
need -lrt. We still need it for timer_create() so we check for this
function in addition.
We also need check if -lm is needed for isnan().
Both -lm and -lrt are needed for libs_qga.
Signed-off-by: Natanael Copa nc...@alpinelinux.org
---
Changes v3-v4:
- Use $pthread_lib from previous pthread test
We don't need to add it to $LIBS since it should be there already
configure | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index edf9da4..31eee91 100755
--- a/configure
+++ b/configure
@@ -2624,17 +2624,49 @@ fi
##
+# Do we need libm
+cat $TMPC EOF
+#include math.h
+int main(void) { return isnan(sin(0.0)); }
+EOF
+if compile_prog ; then
+ :
+elif compile_prog -lm ; then
+ LIBS=-lm $LIBS
+ libs_qga=-lm $libs_qga
+else
+ echo
+ echo Error: libm check failed
+ echo
+ exit 1
+fi
+
+##
# Do we need librt
+# uClibc provides 2 versions of clock_gettime(), one with realtime
+# support and one without. This means that the clock_gettime() don't
+# need -lrt. We still need it for timer_create() so we check for this
+# function in addition.
cat $TMPC EOF
#include signal.h
#include time.h
-int main(void) { return clock_gettime(CLOCK_REALTIME, NULL); }
+int main(void) {
+ timer_create(CLOCK_REALTIME, NULL, NULL);
+ return clock_gettime(CLOCK_REALTIME, NULL);
+}
EOF
if compile_prog ; then
:
-elif compile_prog -lrt ; then
+# we need pthread for static linking. use previous pthread test result
+elif compile_prog -lrt $pthread_lib ; then
LIBS=-lrt $LIBS
+ libs_qga=-lrt $libs_qga
+else
+ echo
+ echo Error: librt check failed
+ echo
+ exit 1
fi
if test $darwin != yes -a $mingw32 != yes -a $solaris != yes -a \
--
1.7.12
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On Wed, Aug 22, 2012 at 09:05:52AM +0200, Jan Kiszka wrote:
On 2012-08-22 08:47, Jan Kiszka wrote:
On 2012-08-22 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we
loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
write_rom ignores write protection - that you usually find on ROMs. That
makes no difference under KVM so far as there we lack read-only
sections. But that will be fixed soon, patches are on the list.
In fact, it does make a difference also for KVM mode as
cpu_physical_memory_rw works from userspace while the limitation only
affects guest code running under KVM control.
Ok, so IIUC, that means we do need the cpu_physical_memory_write_rom()
version for load_image_targphys(), and so my original patch is
basically the right fix.
Jan
PS: I'm still facing a bogus Mail-Followup-To tag in your postings,
David, thus you easily fall from the To list on reply.
Ah, yes, thanks for the reminder. I think I finally found the right
option to stop mutt from doing that.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 22.08.2012, at 13:38, David Gibson wrote:
On Wed, Aug 22, 2012 at 09:05:52AM +0200, Jan Kiszka wrote:
On 2012-08-22 08:47, Jan Kiszka wrote:
On 2012-08-22 07:57, David Gibson wrote:
On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
On 22.08.2012, at 06:59, David Gibson wrote:
cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.
However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
does invalidate any cached TBs which might be affected by the region
written.
This was breaking reset (under full emu) on the pseries machine - we
loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh). When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.
This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
exec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/exec.c b/exec.c
index 5834766..eff40d7 100644
--- a/exec.c
+++ b/exec.c
@@ -3523,6 +3523,13 @@ void
cpu_physical_memory_write_rom(target_phys_addr_t addr,
/* ROM/RAM case */
ptr = qemu_get_ram_ptr(addr1);
memcpy(ptr, buf, l);
+if (!cpu_physical_memory_is_dirty(addr1)) {
+/* invalidate code */
+tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+/* set dirty bit */
+cpu_physical_memory_set_dirty_flags(
+addr1, (0xff ~CODE_DIRTY_FLAG));
+}
Can't we just call cpu_physical_memory_rw in the RAM case? The
function only tries to not do MMIO accesses on ROM pages, right?
Maybe. It's not clear at all to me what cases
cpu_physical_memory_write_rom() is supposed to be for, as opposed to
just using cpu_physical_memory_rw().
write_rom ignores write protection - that you usually find on ROMs. That
makes no difference under KVM so far as there we lack read-only
sections. But that will be fixed soon, patches are on the list.
In fact, it does make a difference also for KVM mode as
cpu_physical_memory_rw works from userspace while the limitation only
affects guest code running under KVM control.
Ok, so IIUC, that means we do need the cpu_physical_memory_write_rom()
version for load_image_targphys(), and so my original patch is
basically the right fix.
Sure it is, I don't think anyone argued about that :). But it's duplicating
code in a slow path. So my proposal was instead of doing the write manually in
the this is read-write RAM case, just fall back to the known-to-work
cpu_physical_memory_rw for those pages. That would make the rom function
smaller, more obvious and duplicate less code.
Alex
[Qemu-devel] [PATCH] s390: use sync regs for register transfer
From: Christian Borntraeger borntrae...@de.ibm.com
Newer kernels provide the guest registers in kvm_run. Lets use
those if available. This avoids ioctls on cpu_synchronize_state
making intercepts faster.
In addition, we have now the prefix register, the access registers
the control registers up to date. This helps in certain cases,
e.g. for resolving kernel module addresses with gdb on a guest.
On return, we only update the gprs, since qemu does not change
prefix, crs and acrs. Blindly updating those might cause some
expensive flushing in the kernel.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
---
target-s390x/kvm.c | 75 +-
1 file changed, 51 insertions(+), 24 deletions(-)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 07edf93..4598923 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -88,50 +88,77 @@ void kvm_arch_reset_vcpu(CPUS390XState *env)
/* FIXME: add code to reset vcpu. */
}
+/* we want to have the prefix, the GPRS, the ACRS and the CRS up to date */
+#define QEMU_NEEDED_REGS (KVM_SYNC_PREFIX | KVM_SYNC_GPRS | \
+ KVM_SYNC_ACRS | KVM_SYNC_CRS)
+
+/* But qemu only changes the GPRS */
+#define QEMU_DIRTY_REGS (KVM_SYNC_GPRS)
+
int kvm_arch_put_registers(CPUS390XState *env, int level)
{
struct kvm_regs regs;
int ret;
int i;
-ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, regs);
-if (ret 0) {
-return ret;
-}
-
-for (i = 0; i 16; i++) {
-regs.gprs[i] = env-regs[i];
-}
-
-ret = kvm_vcpu_ioctl(env, KVM_SET_REGS, regs);
-if (ret 0) {
-return ret;
-}
-
env-kvm_run-psw_addr = env-psw.addr;
env-kvm_run-psw_mask = env-psw.mask;
-return ret;
+if ((env-kvm_run-kvm_valid_regs QEMU_NEEDED_REGS) == QEMU_NEEDED_REGS)
{
+env-kvm_run-s.regs.prefix = env-psa;
+for (i = 0; i 16; i++) {
+env-kvm_run-s.regs.gprs[i] = env-regs[i];
+env-kvm_run-kvm_dirty_regs |= QEMU_DIRTY_REGS;
+}
+} else {
+for (i = 0; i 16; i++) {
+regs.gprs[i] = env-regs[i];
+}
+ret = kvm_vcpu_ioctl(env, KVM_SET_REGS, regs);
+if (ret 0) {
+return ret;
+}
+/* no prefix available */
+}
+/* sregs unchanged */
+
+return 0;
}
int kvm_arch_get_registers(CPUS390XState *env)
{
int ret;
struct kvm_regs regs;
+struct kvm_sregs sregs;
int i;
-ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, regs);
-if (ret 0) {
-return ret;
-}
-
-for (i = 0; i 16; i++) {
-env-regs[i] = regs.gprs[i];
-}
-
env-psw.addr = env-kvm_run-psw_addr;
env-psw.mask = env-kvm_run-psw_mask;
+if ((env-kvm_run-kvm_valid_regs QEMU_NEEDED_REGS) == QEMU_NEEDED_REGS)
{
+env-psa = env-kvm_run-s.regs.prefix;
+for (i = 0; i 16; i++) {
+env-regs[i] = env-kvm_run-s.regs.gprs[i];
+env-cregs[i] = env-kvm_run-s.regs.crs[i];
+env-aregs[i] = env-kvm_run-s.regs.acrs[i];
+}
+} else {
+ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, regs);
+if (ret 0) {
+return ret;
+}
+ret = kvm_vcpu_ioctl(env, KVM_GET_SREGS, sregs);
+if (ret 0) {
+return ret;
+}
+for (i = 0; i 16; i++) {
+env-regs[i] = regs.gprs[i];
+env-cregs[i] = sregs.crs[i];
+env-aregs[i] = sregs.acrs[i];
+}
+/* no prefix available */
+}
+
return 0;
}
--
1.7.11.5
[Qemu-devel] [PATCHv3 1/5] qemu-ga: don't leak a file descriptor upon failed lockf
From: Jim Meyering meyer...@redhat.com
Signed-off-by: Jim Meyering meyer...@redhat.com
---
qemu-ga.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-ga.c b/qemu-ga.c
index 8f87621..26671fe 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -247,6 +247,9 @@ static bool ga_open_pidfile(const char *pidfile)
pidfd = open(pidfile, O_CREAT|O_WRONLY, S_IRUSR|S_IWUSR);
if (pidfd == -1 || lockf(pidfd, F_TLOCK, 0)) {
g_critical(Cannot lock pid file, %s, strerror(errno));
+if (pidfd != -1) {
+close(pidfd);
+}
return false;
}
--
1.7.12
[Qemu-devel] [PATCHv3 2/5] linux-user: do_msgrcv: don't leak host_mb upon TARGET_EFAULT failure
From: Jim Meyering meyer...@redhat.com
Also, use g_malloc to avoid NULL-deref upon OOM.
Signed-off-by: Jim Meyering meyer...@redhat.com
---
linux-user/syscall.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 41c869b..1174306 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2848,7 +2848,7 @@ static inline abi_long do_msgrcv(int msqid, abi_long msgp,
if (!lock_user_struct(VERIFY_WRITE, target_mb, msgp, 0))
return -TARGET_EFAULT;
-host_mb = malloc(msgsz+sizeof(long));
+host_mb = g_malloc(msgsz+sizeof(long));
ret = get_errno(msgrcv(msqid, host_mb, msgsz, tswapal(msgtyp), msgflg));
if (ret 0) {
@@ -2863,11 +2863,11 @@ static inline abi_long do_msgrcv(int msqid, abi_long
msgp,
}
target_mb-mtype = tswapal(host_mb-mtype);
-free(host_mb);
end:
if (target_mb)
unlock_user_struct(target_mb, msgp, 1);
+g_free(host_mb);
return ret;
}
--
1.7.12
[Qemu-devel] [PATCHv3 0/5] plug memory and file-descriptor leaks
From: Jim Meyering meyer...@redhat.com Hi Anthony, I posted this series back in May, got some good feedback leading to a pair of v2 patches. Since then one of the 6 patches was applied. I'm calling this v3, but it is merely a trivial rebase of the v1 and v2 patches. Hoping it's not too late for 1.2, here are the remaining five: Jim Meyering (5): qemu-ga: don't leak a file descriptor upon failed lockf linux-user: do_msgrcv: don't leak host_mb upon TARGET_EFAULT failure sheepdog: don't leak socket file descriptor upon connection failure arm-semi: don't leak 1KB user string lock buffer upon TARGET_SYS_OPEN softmmu-semi: fix lock_user* functions not to deref NULL upon OOM block/sheepdog.c | 1 + linux-user/syscall.c | 4 ++-- qemu-ga.c | 3 +++ softmmu-semi.h| 5 - target-arm/arm-semi.c | 13 +++-- 5 files changed, 17 insertions(+), 9 deletions(-) -- 1.7.12
[Qemu-devel] [PATCHv3 4/5] arm-semi: don't leak 1KB user string lock buffer upon TARGET_SYS_OPEN
From: Jim Meyering meyer...@redhat.com
Always call unlock_user before returning.
Signed-off-by: Jim Meyering meyer...@redhat.com
---
target-arm/arm-semi.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/target-arm/arm-semi.c b/target-arm/arm-semi.c
index 2495206..73bde58 100644
--- a/target-arm/arm-semi.c
+++ b/target-arm/arm-semi.c
@@ -194,18 +194,19 @@ uint32_t do_arm_semihosting(CPUARMState *env)
if (!(s = lock_user_string(ARG(0
/* FIXME - should this error code be -TARGET_EFAULT ? */
return (uint32_t)-1;
-if (ARG(1) = 12)
+if (ARG(1) = 12) {
+unlock_user(s, ARG(0), 0);
return (uint32_t)-1;
+}
if (strcmp(s, :tt) == 0) {
-if (ARG(1) 4)
-return STDIN_FILENO;
-else
-return STDOUT_FILENO;
+int result_fileno = ARG(1) 4 ? STDIN_FILENO : STDOUT_FILENO;
+unlock_user(s, ARG(0), 0);
+return result_fileno;
}
if (use_gdb_syscalls()) {
gdb_do_syscall(arm_semi_cb, open,%s,%x,1a4, ARG(0),
(int)ARG(2)+1, gdb_open_modeflags[ARG(1)]);
-return env-regs[0];
+ret = env-regs[0];
} else {
ret = set_swi_errno(ts, open(s, open_modeflags[ARG(1)], 0644));
}
--
1.7.12
[Qemu-devel] [PATCHv3 3/5] sheepdog: don't leak socket file descriptor upon connection failure
From: Jim Meyering meyer...@redhat.com
Signed-off-by: Jim Meyering meyer...@redhat.com
---
block/sheepdog.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index a04ad99..df4f441 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -485,6 +485,7 @@ static int connect_to_sdog(const char *addr, const char
*port)
if (errno == EINTR) {
goto reconnect;
}
+close(fd);
break;
}
--
1.7.12
[Qemu-devel] [PATCHv3 5/5] softmmu-semi: fix lock_user* functions not to deref NULL upon OOM
From: Jim Meyering meyer...@redhat.com
Return NULL upon malloc failure.
Signed-off-by: Jim Meyering meyer...@redhat.com
---
softmmu-semi.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/softmmu-semi.h b/softmmu-semi.h
index 648cb95..bcb979a 100644
--- a/softmmu-semi.h
+++ b/softmmu-semi.h
@@ -40,7 +40,7 @@ static void *softmmu_lock_user(CPUArchState *env, uint32_t
addr, uint32_t len,
uint8_t *p;
/* TODO: Make this something that isn't fixed size. */
p = malloc(len);
-if (copy)
+if (p copy)
cpu_memory_rw_debug(env, addr, p, len, 0);
return p;
}
@@ -52,6 +52,9 @@ static char *softmmu_lock_user_string(CPUArchState *env,
uint32_t addr)
uint8_t c;
/* TODO: Make this something that isn't fixed size. */
s = p = malloc(1024);
+if (!s) {
+return NULL;
+}
do {
cpu_memory_rw_debug(env, addr, c, 1, 0);
addr++;
--
1.7.12
Re: [Qemu-devel] ivshmem assertion failure with EventNotifier
Il 22/08/2012 06:29, Cam Macdonell ha scritto:
Hi Paolo,
I've noticed an assertion error when sending interrupts via ivshmem.
I bisected to this patch.
Does this help?
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index b4d65a6..47f2a16 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -366,6 +366,10 @@ static void close_guest_eventfds(IVShmemState *s,
int posn)
{
int i, guest_curr_max;
+if (!ivshmem_has_feature(s, IVSHMEM_IOEVENTFD)) {
+return;
+}
+
guest_curr_max = s-peers[posn].nb_eventfds;
memory_region_transaction_begin();
Paolo
Re: [Qemu-devel] [PATCH] qom: removal of link property need to release its target
Il 22/08/2012 05:02, Liu Ping Fan ha scritto:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Currently, link property's target is only managed by
object_set_link_property(). This will raise such issue that when
the property is finalized, its target has no opportunity to release.
Fix this issue by introduce object_finalize_link_property()
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Paolo
---
qom/object.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index a552be2..76b3d34 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -957,6 +957,16 @@ static void object_set_link_property(Object *obj,
Visitor *v, void *opaque,
}
}
+static void object_finalize_link_property(Object *obj, const char *name,
+ void *opaque)
+{
+Object **child = opaque;
+
+if (*child != NULL) {
+object_unref(*child);
+}
+}
+
void object_property_add_link(Object *obj, const char *name,
const char *type, Object **child,
Error **errp)
@@ -968,7 +978,7 @@ void object_property_add_link(Object *obj, const char
*name,
object_property_add(obj, name, full_type,
object_get_link_property,
object_set_link_property,
-NULL, child, errp);
+object_finalize_link_property, child, errp);
g_free(full_type);
}
Re: [Qemu-devel] Dump guest page table inside QEMU makes system hang
On Tue, Aug 21, 2012 at 10:19 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Aug 21, 2012 at 7:21 AM, 陳韋任 (Wei-Ren Chen)
che...@iis.sinica.edu.tw wrote:
Hi all,
I want to dump guest page table when guest writes to cr3,
the code snipt below,
---
uint32_t pgd[1024][1024]; // guest page table
static void dump_guest_pgtable(target_ulong cr3)
{
int i, j;
uint32_t phyaddr = cr3;
uint32_t val;
for (i = 0; i NUM_ENTRY; ++i)
{
phyaddr += i * 4;
for (j = 0; j NUM_ENTRY; ++j)
{
cpu_physical_memory_read(phyaddr, val, 4);
pgd[i][j] = val;
}
}
}
void cpu_x86_update_cr3(CPUX86State *env, target_ulong new_cr3)
{
env-cr[3] = new_cr3; // guest cr3
if (env-cr[0] CR0_PG_MASK) {
tlb_flush(env, 0);
// dump guest page table by using guest cr3
dump_guest_pgtable(new_cr3);
}
}
---
The system will hang while booting. However, if I comment
cpu_physical_memory_read in function dump_guest_pgtable, there
is no problem. What I am missing here? Thanks.
cpu_physical_memory_read() can cause faults or other side effects like
MMIO. Using cpu_get_phys_page_debug() may help.
Maybe you just need to avoid accessing unsuitable physical addresses?
Or maybe 'if (env-cr[0] CR0_PG_MASK)' is not strong enough, may
(CR0_PG_MASK | CR0_PE_MASK) be better?
At what stage does it hang? What CR3 value changes are observed before
the hang?
--
Thanks.
-- Max
Re: [Qemu-devel] [PATCH V3 2/2] qemu-img: Add json output option to the info command.
Le Thursday 16 Aug 2012 à 11:13:05 (+0800), Wenchao Xia a écrit :
I was busy in coding libqblock so forgot to move forward on qemu json
info patches, thanks for your advance.
one suggestion:
how about folder all human printf into function:
dump_human_image_info(image_info), and at the end, make the final
output functions as mirror:
if (human) {
dump_human_image_info(image_info);
} else {
dump_json_image_info(image_info);
}
I will post a patch looking like this.
Benoît
With this, information collecting and output generating were
separated, it will be easy to do more modification if we want.
for eg, if we want to get the string generated and write it to
another place or pipe, we would only need to modify
dump_human_image_info()
This additionnal --machine=json option make qemu-img info output on
stdout a JSON formated representation of the image informations.
--machine=json was choosen instead of --format=json because the
info command already have a -f parameter.
example:
{
backing-filename-format: raw,
snapshots: [
{
vm-clock-nsec: 4647590161,
name: truc,
date-sec: 1345034924,
date-nsec: 870405000,
id: 1,
vm-state-size: 80805256
},
{
vm-clock-nsec: 7065282574,
name: onx,
date-sec: 1345034927,
date-nsec: 914633000,
id: 2,
vm-state-size: 75927370
},
{
vm-clock-nsec: 10108695046,
name: list,
date-sec: 1345034939,
date-nsec: 39119000,
id: 3,
vm-state-size: 75890567
}
],
virtual-size: 1073741824,
filename: ./snapshot.img,
cluster-size: 65536,
format: qcow2,
actual-size: 242614272,
backing-filename: truc5.raw,
dirty-flag: false
}
Signed-off-by: Benoit Canet ben...@irqsave.net
---
Makefile |3 +-
qemu-img.c | 133
+++-
2 files changed, 124 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index ab82ef3..9ba064b 100644
--- a/Makefile
+++ b/Makefile
@@ -160,7 +160,8 @@ tools-obj-y = $(oslib-obj-y) $(trace-obj-y) qemu-tool.o
qemu-timer.o \
iohandler.o cutils.o iov.o async.o
tools-obj-$(CONFIG_POSIX) += compatfd.o
-qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y)
+qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) $(qapi-obj-y) \
+ qapi-visit.o qapi-types.o
qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y)
qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y)
diff --git a/qemu-img.c b/qemu-img.c
index 80cfb9b..5e20f5d 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -21,12 +21,16 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN
* THE SOFTWARE.
*/
+#include qapi-visit.h
+#include qapi/qmp-output-visitor.h
+#include qjson.h
#include qemu-common.h
#include qemu-option.h
#include qemu-error.h
#include osdep.h
#include sysemu.h
#include block_int.h
+#include getopt.h
#include stdio.h
#ifdef _WIN32
@@ -84,6 +88,7 @@ static void help(void)
'-p' show progress of command (only certain commands)\n
'-S' indicates the consecutive number of bytes that must
contain only zeros\n
for qemu-img to create a sparse image during
conversion\n
+ '-m' or '--machine' takes the format in which the output must
be done (json)\n
\n
Parameters to check subcommand:\n
'-r' tries to repair any inconsistencies that are found
during the check.\n
@@ -1102,21 +1107,86 @@ static void dump_snapshots(BlockDriverState *bs)
g_free(sn_tab);
}
+static void collect_snapshots(BlockDriverState *bs , ImageInfo *image_info)
+{
+int i, sn_count;
+QEMUSnapshotInfo *sn_tab = NULL;
+SnapshotInfoList *sn_info_list, *cur_item = NULL;
+sn_count = bdrv_snapshot_list(bs, sn_tab);
+
+for (i = 0; i sn_count; i++) {
+image_info-has_snapshots = true;
+sn_info_list = g_new0(SnapshotInfoList, 1);
+
+sn_info_list-value = g_new0(SnapshotInfo, 1);
+sn_info_list-value-id = g_strdup(sn_tab[i].id_str);
+sn_info_list-value-name = g_strdup(sn_tab[i].name);
+sn_info_list-value-vm_state_size = sn_tab[i].vm_state_size;
+sn_info_list-value-date_sec = sn_tab[i].date_sec;
+sn_info_list-value-date_nsec = sn_tab[i].date_nsec;
+sn_info_list-value-vm_clock_nsec = sn_tab[i].vm_clock_nsec;
+
+/* XXX: waiting for the qapi to support GSList */
+if (!cur_item) {
+image_info-snapshots = cur_item = sn_info_list;
+} else {
+
Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
Il 22/08/2012 13:04, Cong Meng ha scritto: Cong, what is the limit that the host HBA enforces (and what is the HBA)? What commands see a problem? Is it fixed by using scsi-block instead of scsi-generic (if you can use scsi-block at all, i.e. it's not a tape or similar device)? I don't see real problem caused by the the queue limits actually. It's a bug which Stefan told me. I'd rather avoid patching the specification if not to solve real (rather than known-but-theoretical) problems. With scsi-generic, QEMU uses a bounce buffer for non-I/O commands to a SCSI passthrough device, so the only problem in that case should be the maximum segment size. This could change in the future, but max_segments and max_sectors should not yet be a problem. about bounce buffer, do you meat the buffer allocated in scsi_send_command() of hw/scsi-generic.c? Yes. Paolo
[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler
ok, I'll double check that backing out the local patches doesn't make a
difference. If it still happens I will try and come up with a reduced
test case.
What do you expect to happen?
Should the SVC exception 11 run immediately?
What should happen if a clock tick interrupt is also pending at level 15 with a
higher (numerically lower) priority?
What I currently see happening is neither interrupts happen immediately, the
code continues to execute. Then one or more clock tick interrupts occur, before
finally I see the SVC interrupt code running.
Cheers
Mark
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
New
Bug description:
The svc instruction doesn't work as expected.
- qemu 0.13.0 rc1 (git)
Test : demo with freeRTOS (for example
FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
If we start the scheduler, it will call that function (__attribute__
(( naked ))) :
void vPortStartFirstTask( void )
{
__asm volatile(
ldr r0, =0xE000ED08 \n /*
Use the NVIC offset register to locate the stack. */
ldr r0, [r0]
\n
ldr r0, [r0]
\n
msr msp, r0
\n /* Set the msp back to the start of the stack. */
svc 0
\n /* System call to start first task. */
);
}
The 4 first lines in asm work fine. The scv 0 call will rise the right
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will
never call the PendSV Handler (xPortPendSVHandler here). This function is
recorded in the nvic vector.
Next, (after the svc), the processor will execute the line after in code
(this is a naked function) so the next function written after
vPortStartFirstTask in the code.
command line :
console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
console 2 : arm-none-eabi-gdb -ex target remote localhost:1234
gcc/RTOSDemo.axf
arm-none-eabi from
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
Same error with another project with arm-elf
processor : arm cortex m3
host : gentoo (2.6.35-r9) (without kqemu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/657006/+subscriptions
[Qemu-devel] FYI: Delaying 1.2 release to Sept. 5th.
I cannot provide additional details so please don't ask. There's a issue in the 1.2 release being investigated. We need to delay the release by a few days to ensure the fix can be in the release. I've updated the wiki appropriately. Regards, Anthony Liguori
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/22/2012 03:40 PM, Richard Davies wrote: I can trigger the slow boots without KSM and they have the same profile, with _raw_spin_lock_irqsave and isolate_freepages_block at the top. I reduced to 3x 20GB 8-core VMs on a 128GB host (rather than 3x 40GB 8-core VMs), and haven't managed to get a really slow boot yet (5 minutes). I'll post agan when I get one. I think you can go higher than that. But 120GB on a 128GB host is pushing it. In the slowest boot that I have so far (1-2 minutes), this is the perf top ouput: PerfTop: 26741 irqs/sec kernel:97.5% exact: 0.0% [4000Hz cycles], (all, 16 CPUs) --- 53.94% [kernel] [k] clear_page_c 2.77% [kernel] [k] svm_vcpu_put 2.60% [kernel] [k] svm_vcpu_run 1.79% [kernel] [k] sub_preempt_count 1.56% [kernel] [k] svm_vcpu_load 1.44% [kernel] [k] __schedule 1.36% [kernel] [k] kvm_arch_vcpu_ioctl_run 1.34% [kernel] [k] resched_task 1.32% [kernel] [k] _raw_spin_lock 0.98% [kernel] [k] trace_preempt_on 0.95% [kernel] [k] get_parent_ip 0.94% [kernel] [k] yield_to This is pretty normal, Widows is touching memory so clear_page_c() is called to scrub it. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH V4 0/2] Add JSON output to qemu-img info
This patchset add a JSON output mode to the qemu-img info command. It's a rewrite from scratch of the original patchset by Wenchao Xia following Anthony Liguori advices on JSON formating. the --output=(json|human) option is now mandatory on the command line. Benoît Canet (3): qapi: Add SnapshotInfo. qapi: Add ImageInfo. qemu-img: Add json output option to the info command. in v2: eblake: make some field optionals squash the two qapi patchs together fix a typo on vm_clock_nsec bcanet: fix a potential memory leak in v3: lcapitulino: remove unneeded test put '\n' at the end of json in printf statement drop the uneeded head pointer in collect_snapshots in v4: Wenchao Xia Kevin Wolf: -Refactor to separate rate ImageInfo collection from human printing. Kevin Wolf: -Use --output=(json|human). -make the two choice exclusive and print a message if none is specified. -cosmetic '=' alignement in collect snapshots. Benoît Canet: -add full-backing-filename to the ImageInfo structure (needed for human printing) -make ImageInfo-actual_size optional depending on the context. Benoît Canet (2): qapi: Add SnapshotInfo and ImageInfo. qemu-img: Add json output option to the info command. Makefile |3 +- qapi-schema.json | 62 ++ qemu-img.c | 252 -- 3 files changed, 272 insertions(+), 45 deletions(-) -- 1.7.9.5
[Qemu-devel] [PATCH V4 1/2] qapi: Add SnapshotInfo and ImageInfo.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
qapi-schema.json | 62 ++
1 file changed, 62 insertions(+)
diff --git a/qapi-schema.json b/qapi-schema.json
index a92adb1..4c4b9b9 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -126,6 +126,68 @@
'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
##
+# @SnapshotInfo
+#
+# @id: unique snapshot id
+#
+# @name: user choosen name
+#
+# @vm-state-size: size of the VM state
+#
+# @date-sec: UTC date of the snapshot
+#
+# @date-nsec: date in nano seconds
+#
+# @vm-clock-nsec: VM clock relative to boot in nano seconds
+#
+# Since: 1.2
+#
+##
+
+{ 'type': 'SnapshotInfo',
+ 'data': { 'id': 'str', 'name': 'str', 'vm-state-size': 'int',
+'date-sec': 'int', 'date-nsec': 'int',
+'vm-clock-nsec': 'int' } }
+
+##
+# @ImageInfo:
+#
+# Information about a QEMU image file
+#
+# @filename: name of the image file
+#
+# @format: format of the image file
+#
+# @virtual-size: maximum capacity in bytes of the image
+#
+# @actual-size: #optional actual size on disk in bytes of the image
+#
+# @dirty-flag: #optional true if image is not cleanly closed
+#
+# @cluster-size: #optional size of a cluster in bytes
+#
+# @encrypted: #optional true if the image is encrypted
+#
+# @backing-filename: #optional name of the backing file
+#
+# @full-backing-filename: #optional full path of the backing file
+#
+# @backing-filename-format: #optional the format of the backing file
+#
+# @snapshots: #optional list of VM snapshots
+#
+# Since: 1.2
+#
+##
+
+{ 'type': 'ImageInfo',
+ 'data': {'filename': 'str', 'format': 'str', '*dirty-flag': 'bool',
+ '*actual-size': 'int', 'virtual-size': 'int',
+ '*cluster-size': 'int', '*encrypted': 'bool',
+ '*backing-filename': 'str', '*full-backing-filename': 'str',
+ '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'] }
}
+
+##
# @StatusInfo:
#
# Information about VCPU run state
--
1.7.9.5
[Qemu-devel] [PATCH V4 2/2] qemu-img: Add json output option to the info command.
This option --output=[human|json] make qemu-img info output on
human or JSON representation at the choice of the user.
example:
{
snapshots: [
{
vm-clock-nsec: 20637102488,
name: vm-20120821145509,
date-sec: 1345553709,
date-nsec: 220289000,
id: 1,
vm-state-size: 96522745
},
{
vm-clock-nsec: 46028210866,
name: vm-20120821154059,
date-sec: 1345556459,
date-nsec: 171392000,
id: 2,
vm-state-size: 101208714
}
],
virtual-size: 1073741824,
filename: snap.qcow2,
cluster-size: 65536,
format: qcow2,
actual-size: 985587712,
dirty-flag: false
}
Signed-off-by: Benoit Canet ben...@irqsave.net
---
Makefile |3 +-
qemu-img.c | 252 +---
2 files changed, 210 insertions(+), 45 deletions(-)
diff --git a/Makefile b/Makefile
index ab82ef3..9ba064b 100644
--- a/Makefile
+++ b/Makefile
@@ -160,7 +160,8 @@ tools-obj-y = $(oslib-obj-y) $(trace-obj-y) qemu-tool.o
qemu-timer.o \
iohandler.o cutils.o iov.o async.o
tools-obj-$(CONFIG_POSIX) += compatfd.o
-qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y)
+qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) $(qapi-obj-y) \
+ qapi-visit.o qapi-types.o
qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y)
qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y)
diff --git a/qemu-img.c b/qemu-img.c
index 80cfb9b..1591898 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -21,12 +21,16 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
+#include qapi-visit.h
+#include qapi/qmp-output-visitor.h
+#include qjson.h
#include qemu-common.h
#include qemu-option.h
#include qemu-error.h
#include osdep.h
#include sysemu.h
#include block_int.h
+#include getopt.h
#include stdio.h
#ifdef _WIN32
@@ -84,6 +88,7 @@ static void help(void)
'-p' show progress of command (only certain commands)\n
'-S' indicates the consecutive number of bytes that must contain
only zeros\n
for qemu-img to create a sparse image during conversion\n
+ '--output' takes the format in which the output must be done
(human or json)\n
\n
Parameters to check subcommand:\n
'-r' tries to repair any inconsistencies that are found during
the check.\n
@@ -1083,7 +1088,6 @@ out:
return 0;
}
-
static void dump_snapshots(BlockDriverState *bs)
{
QEMUSnapshotInfo *sn_tab, *sn;
@@ -1102,21 +1106,188 @@ static void dump_snapshots(BlockDriverState *bs)
g_free(sn_tab);
}
-static int img_info(int argc, char **argv)
+static void collect_snapshots(BlockDriverState *bs , ImageInfo *info)
+{
+int i, sn_count;
+QEMUSnapshotInfo *sn_tab = NULL;
+SnapshotInfoList *sn_info_list, *cur_item = NULL;
+sn_count = bdrv_snapshot_list(bs, sn_tab);
+
+for (i = 0; i sn_count; i++) {
+info-has_snapshots = true;
+sn_info_list = g_new0(SnapshotInfoList, 1);
+
+sn_info_list-value= g_new0(SnapshotInfo, 1);
+sn_info_list-value-id= g_strdup(sn_tab[i].id_str);
+sn_info_list-value-name = g_strdup(sn_tab[i].name);
+sn_info_list-value-vm_state_size = sn_tab[i].vm_state_size;
+sn_info_list-value-date_sec = sn_tab[i].date_sec;
+sn_info_list-value-date_nsec = sn_tab[i].date_nsec;
+sn_info_list-value-vm_clock_nsec = sn_tab[i].vm_clock_nsec;
+
+/* XXX: waiting for the qapi to support GSList */
+if (!cur_item) {
+info-snapshots = cur_item = sn_info_list;
+} else {
+cur_item-next = sn_info_list;
+cur_item = sn_info_list;
+}
+
+}
+
+g_free(sn_tab);
+}
+
+static void dump_json_image_info(ImageInfo *info)
+{
+Error *errp = NULL;
+QString *str;
+QmpOutputVisitor *ov = qmp_output_visitor_new();
+QObject *obj;
+visit_type_ImageInfo(qmp_output_get_visitor(ov),
+ info, NULL, errp);
+obj = qmp_output_get_qobject(ov);
+str = qobject_to_json_pretty(obj);
+assert(str != NULL);
+printf(%s\n, qstring_get_str(str));
+qobject_decref(obj);
+qmp_output_visitor_cleanup(ov);
+QDECREF(str);
+}
+
+static void collect_backing_file_format(ImageInfo *info, char *filename)
+{
+BlockDriverState *bs = NULL;
+bs = bdrv_new_open(filename, NULL,
+ BDRV_O_FLAGS | BDRV_O_NO_BACKING);
+if (!bs) {
+return;
+}
+info-backing_filename_format =
+g_strdup(bdrv_get_format_name(bs));
+bdrv_delete(bs);
+info-has_backing_filename_format = true;
+}
+
+static void collect_image_info(BlockDriverState *bs,
+ ImageInfo *info,
+
Re: [Qemu-devel] qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop
On 08/21/12 10:23, Stefan Hajnoczi wrote: On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszkajan.kis...@siemens.com wrote: On 2012-08-19 11:42, Avi Kivity wrote: On 08/17/2012 06:04 PM, Jan Kiszka wrote: Can anyone imagine that such a barrier may actually be required? If it is currently possible that env-stop is evaluated before we called into sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the signal without properly processing its reason (stop). Should not be required (TM): Both signal eating / stop checking and stop setting / signal generation happens under the BQL, thus the ordering must not make a difference here. Agree. Don't see where we could lose a signal. Maybe due to a subtle memory corruption that sets thread_kicked to non-zero, preventing the kicking this way. Cannot be ruled out, yet too much of a coincidence. Could be a kernel bug (either in kvm or elsewhere), we've had several before in this area. Is this reproducible? Not for me. Peter only hit it very rarely, Peter obviously more easily. I have only hit this once and was not able to reproduce it. For me it was very reproducible, but my issue was fixed by: http://www.mail-archive.com/kvm@vger.kernel.org/msg70908.html Never seen this since then, Peter Stefan
Re: [Qemu-devel] [RFC 0/8] include qdev core in *-user, make CPU child of DeviceState
On Wed, Aug 22, 2012 at 12:05:44PM +0300, Avi Kivity wrote:
On 08/21/2012 06:42 PM, Eduardo Habkost wrote:
So, here's a third suggestion to the CPU/DeviceState problem. Basically I
split
the qdev code into a core (that can be easily compiled into *-user), and a
part
specific to qemu-system-*.
I'm barging in late here, so sorry if this has been suggested and shot
down: is it not possible to use composition here?
typedef ... CPU;
typedef struct CPUState {
DeviceState qdev;
CPU cpu;
} CPUState;
But I guess bringing qdev to -user is inevitable.
I guess it would be OK, and almost equivalent to the suggestion by
Anthony (use a different parent class for the CPU class on system-* and
*-user), as most state today is in the arch-specific classes.
The only problem I see is when some part of the CPU code starts using a
DeviceState feature (e.g. calling x86_cpu_realize() only at
qdev_init()-time). Then we have to duplicate some code to make *-user
work differently (not much code, I guess, but it would still make it
easier to break it if we have two implementations).
--
Eduardo
Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
On 08/22/2012 02:47 PM, Alexander Graf wrote: Ok, so IIUC, that means we do need the cpu_physical_memory_write_rom() version for load_image_targphys(), and so my original patch is basically the right fix. Sure it is, I don't think anyone argued about that :). But it's duplicating code in a slow path. So my proposal was instead of doing the write manually in the this is read-write RAM case, just fall back to the known-to-work cpu_physical_memory_rw for those pages. That would make the rom function smaller, more obvious and duplicate less code. I think there were patches (from Xen) extracting that snippet into a helper. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
On Wed, Aug 22, 2012 at 02:09:28PM +0200, Paolo Bonzini wrote: Il 22/08/2012 13:04, Cong Meng ha scritto: Cong, what is the limit that the host HBA enforces (and what is the HBA)? What commands see a problem? Is it fixed by using scsi-block instead of scsi-generic (if you can use scsi-block at all, i.e. it's not a tape or similar device)? I don't see real problem caused by the the queue limits actually. It's a bug which Stefan told me. I'd rather avoid patching the specification if not to solve real (rather than known-but-theoretical) problems. Benjamin Herrenschmidt reported this in problem in 2010: http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01741.html This is a real problem in practice. IE. the USB CD-ROM on this POWER7 blade limits transfers to 0x1e000 bytes for example and the Linux sr driver on the guest is going to try to give me bigger requests than that if I don't start limiting them, which will cause all sort of errors. It cannot be fixed for emulated SCSI HBAs in general but it can for virtio-scsi. I/O requests will be failed with EIO if they exceed block queue limits. Take a look at block/blk-core.c:generic_make_request_checks() and blk_rq_check_limits(). Cong: Have you checked the block queue limits on your test machine and exceeded them to see what happens? Stefan
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size
Daniel P. Berrange berra...@redhat.com writes:
On Tue, Aug 21, 2012 at 09:53:55AM -0300, Luiz Capitulino wrote:
On Tue, 21 Aug 2012 11:07:50 +0100
Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Aug 20, 2012 at 04:02:39PM -0300, Luiz Capitulino wrote:
On Mon, 20 Aug 2012 15:31:38 +0100
Daniel P. Berrange berra...@redhat.com wrote:
From: Daniel P. Berrange berra...@redhat.com
Add a 'query-target' QAPI command to allow management applications
to determine what target architecture a QEMU binary is emulating
without having to parse the binary name or -help output
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{ u'return': { u'arch': u'x86_64', u'bits': 64}}
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
arch_init.c | 11 +++
qapi-schema.json | 25 +
qmp-commands.hx | 5 +
3 files changed, 41 insertions(+)
diff --git a/arch_init.c b/arch_init.c
index 9b46bfc..095672d 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1080,3 +1080,14 @@ int xen_available(void)
return 0;
#endif
}
+
+
+TargetInfo *qmp_query_target(Error **errp)
+{
+TargetInfo *info = g_malloc0(sizeof(*info));
+
+info-arch = g_strdup(TARGET_ARCH);
+info-bits = TARGET_PHYS_ADDR_BITS;
+
+return info;
+}
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..f0e3fe0 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2454,3 +2454,28 @@
#
##
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
+
+##
+# @TargetInfo:
+#
+# Information describing the QEMU target.
+#
+# @arch: the name of the target architecture (eg x86_64, i686,
etc)
Should be an enum, otherwise looks good.
Really ? It feels a little bit odd to make this an enum IMHO.
I don't think it's odd. We should avoid using free-form strings when
the set of possible values a command returns is limited and known.
The only small issue I see though, is that TARGET_ARCH is defined in
configure, so you'll have to add something like CONFIG_TARGET_ENUM there too
Well the (slightly inefficient) way is to just iterate over the enum
strings until you find the matching index. Not a good idea for large
enums, but I figure it'd be acceptable for the small number of arches.
We can create a new CONFIG_ #define that gets set directly to the
enumerator value. No need for string comparison.
Regards,
Anthony Liguori
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] For 1.2: Re: [PATCH 3/8] migration: move total_time from ram stats to migration info
Eric Blake ebl...@redhat.com writes:
On 08/18/2012 05:17 AM, Juan Quintela wrote:
Signed-off-by: Juan Quintela quint...@redhat.com
---
hmp.c| 4 ++--
migration.c | 6 +++---
qapi-schema.json | 14 +++---
qmp-commands.hx | 6 +++---
4 files changed, 15 insertions(+), 15 deletions(-)
+++ b/qapi-schema.json
@@ -290,10 +290,6 @@
#
# @total: total amount of bytes involved in the migration process
#
-# @total-time: total amount of ms since migration started. If
-#migration has ended, it returns the total migration
-#time. (since 1.2)
-#
# @duplicate: number of duplicate pages (since 1.2)
#
# @normal : number of normal pages (since 1.2)
@@ -304,8 +300,7 @@
##
{ 'type': 'MigrationStats',
'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
- 'total-time': 'int', 'duplicate': 'int', 'normal': 'int',
- 'normal-bytes': 'int' } }
+ 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int' } }
##
# @XBZRLECacheStats
@@ -350,12 +345,17 @@
#migration statistics, only returned if XBZRLE feature is
on and
#status is 'active' or 'completed' (since 1.2)
#
+# @total-time: total amount of milliseconds since migration started.
+#If migration has ended, it returns the total migration
+#time. (since 1.2)
+#
# Since: 0.14.0
##
{ 'type': 'MigrationInfo',
'data': {'*status': 'str', '*ram': 'MigrationStats',
'*disk': 'MigrationStats',
- '*xbzrle-cache': 'XBZRLECacheStats'} }
+ '*xbzrle-cache': 'XBZRLECacheStats',
+ 'total-time': 'int'} }
Anthony - are you planning on taking this series for 1.2?
No. This is a new feature and we're past freeze.
If we don't
get this patch in on time, then taking this for 1.3 would result in
changing released QMP interface (right now, there has been no release
with the field in the wrong type).
Ack. We need to preserve compat with the 1.2 interface.
Regards,
Anthony Liguori
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [PATCH 1/5] trace-cmd: Use TRACE_DIR envrionment variable if defined
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
From: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Use TRACE_DIR environment variable for setting
TRACING_DIR would be better, as we are searching for /debug/tracing and
not /debug/trace. Perhaps DEBUG_TRACING_DIR would be even better as to
be less of a generic term.
-- Steve
debugfs/tracing directory if defined. This is
for controlling guest(or remote) ftrace.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-util.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/trace-util.c b/trace-util.c
index e128188..d5a3eb4 100644
--- a/trace-util.c
+++ b/trace-util.c
@@ -311,6 +311,15 @@ char *tracecmd_find_tracing_dir(void)
char type[100];
FILE *fp;
+ tracing_dir = getenv(TRACE_DIR);
+ if (tracing_dir) {
+ tracing_dir = strdup(tracing_dir);
+ if (!tracing_dir)
+ die(malloc);
+ warning(Use environmental tracing directory: %s\n,
tracing_dir);
+ return tracing_dir;
+ }
+
if ((fp = fopen(/proc/mounts,r)) == NULL) {
warning(Can't open /proc/mounts for read);
return NULL;
Re: [Qemu-devel] [PATCH 2/5] trace-cmd: Use tracing directory to count CPUs
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote: From: Masami Hiramatsu masami.hiramatsu...@hitachi.com Count debugfs/tracing/per_cpu/cpu* to determine the number of CPUs. I'm curious, do you find that sysconf doesn't return the # of CPUs the system has? I've had boxes where the per_cpu/cpu* had more cpus than the box actually holds. But this was a bug in the kernel, not the tool. This change log needs to have rational instead of just explaining what the patch does. Thanks, -- Steve Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com ---
Re: [Qemu-devel] [PATCH 3/5] trace-cmd: Support trace-agent of virtio-trace
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
Add read path and control path to use trace-agent of virtio-trace.
When we use trace-agent, trace-cmd will be used as follows:
# AGENT_READ_DIR=/tmp/virtio-trace/tracing \
AGENT_CTL=/tmp/virtio-trace/agent-ctl-path.in \
TRACING_DIR=/tmp/virtio-trace/debugfs/tracing \\
Ha! You used TRACING_DIR but patch one introduces TRACE_DIR. Lets
change this to DEBUG_TRACING_DIR instead anyway.
Also, I don't like the generic environment variables. Perhaps
VIRTIO_TRACE_DIR, or AGENT_TRACE_DIR and AGENT_TRACE_CTL. Lets try to
keep the environment namespace sparse.
trace-cmd record -e sched:*
Here, AGENT_READ_DIR is the path for a reading directory of virtio-trace,
AGENT_CTL is a control path of trace-agent, and TRACING_DIR is a debugfs path
of a guest.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-cmd.h |1 +
trace-recorder.c | 57
+-
trace-util.c | 18 +
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/trace-cmd.h b/trace-cmd.h
index f904dc5..75506ed 100644
--- a/trace-cmd.h
+++ b/trace-cmd.h
@@ -72,6 +72,7 @@ static inline int tracecmd_host_bigendian(void)
}
char *tracecmd_find_tracing_dir(void);
+char *guest_agent_tracing_read_dir(void);
/* --- Opening and Reading the trace.dat file --- */
diff --git a/trace-recorder.c b/trace-recorder.c
index 215affc..3b750e9 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -33,6 +33,7 @@
#include unistd.h
#include ctype.h
#include errno.h
+#include stdbool.h
#include trace-cmd.h
@@ -43,6 +44,8 @@ struct tracecmd_recorder {
int page_size;
int cpu;
int stop;
+ int ctl_fd;
+ boolagent_existing;
Thanks for the reminder. I need to convert a lot to use 'bool' instead.
};
void tracecmd_free_recorder(struct tracecmd_recorder *recorder)
@@ -59,11 +62,29 @@ void tracecmd_free_recorder(struct tracecmd_recorder
*recorder)
free(recorder);
}
+static char *use_trace_agent_dir(char *ctl_path,
+ struct tracecmd_recorder *recorder)
+{
+ ctl_path = strdup(ctl_path);
+ if (!ctl_path)
+ die(malloc);
+ warning(Use environmental control path: %s\n, ctl_path);
s/Use/Using/
-- Steve
+
+ recorder-ctl_fd = open(ctl_path, O_WRONLY);
+ if (recorder-ctl_fd 0)
+ return NULL;
+
+ recorder-agent_existing = true;
+
+ return guest_agent_tracing_read_dir();
+}
+
Re: [Qemu-devel] [PATCH V4 1/2] qapi: Add SnapshotInfo and ImageInfo.
On 08/22/2012 06:45 AM, Benoît Canet wrote: Signed-off-by: Benoit Canet ben...@irqsave.net --- qapi-schema.json | 62 ++ 1 file changed, 62 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index a92adb1..4c4b9b9 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -126,6 +126,68 @@ 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] } ## +# @SnapshotInfo +# +# @id: unique snapshot id +# +# @name: user choosen name s/choosen/chosen/ +# +# @vm-state-size: size of the VM state +# +# @date-sec: UTC date of the snapshot +# +# @date-nsec: date in nano seconds +# +# @vm-clock-nsec: VM clock relative to boot in nano seconds Since we have two fields named *-nsec, it might be worth clarifying that date-nsec is merely the fractional portion to be combined with date-sec (always less than 10), while vm-clock-nsec includes seconds if the drift is that large. For that matter, should we even be exposing things in this manner? I know the internal struct has seconds and nanos separate for date, because it maps to struct timespec; but why can't we combine them into one giant number for JSON? Or are we worried about exceeding int64_t if we take seconds * 10 when dealing with the timestamp the snapshot was created, even though we aren't worried about the VM clock being that far away from boot? +# +# Since: 1.2 Probably too late for 1.2, so this should be 1.3. +## +# @ImageInfo: +# +# Information about a QEMU image file +# +# @filename: name of the image file +# +# @format: format of the image file +# +# @virtual-size: maximum capacity in bytes of the image +# +# @actual-size: #optional actual size on disk in bytes of the image That seems backwards - with a raw file, don't you know the actual size, but have no idea what it can further grow to? +# +# @dirty-flag: #optional true if image is not cleanly closed +# +# @cluster-size: #optional size of a cluster in bytes +# +# @encrypted: #optional true if the image is encrypted +# +# @backing-filename: #optional name of the backing file +# +# @full-backing-filename: #optional full path of the backing file +# +# @backing-filename-format: #optional the format of the backing file +# +# @snapshots: #optional list of VM snapshots +# +# Since: 1.2 Again, 1.3. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 1/3] qapi: Fix memory leak
From: Stefan Weil s...@weilnetz.de valgrind report: ==24534== 232 bytes in 2 blocks are definitely lost in loss record 1,245 of 1,601 ==24534==at 0x4824F20: malloc (vg_replace_malloc.c:236) ==24534==by 0x293C88: malloc_and_trace (vl.c:2281) ==24534==by 0x489AD99: ??? (in /lib/libglib-2.0.so.0.2400.1) ==24534==by 0x489B23B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) ==24534==by 0x2B4EFC: opts_visitor_new (opts-visitor.c:376) ==24534==by 0x29DEA5: net_client_init (net.c:708) ==24534==by 0x29E6C7: net_init_client (net.c:966) ==24534==by 0x2C2179: qemu_opts_foreach (qemu-option.c:1114) ==24534==by 0x29E85B: net_init_clients (net.c:1008) ==24534==by 0x296F40: main (vl.c:3463) Signed-off-by: Stefan Weil s...@weilnetz.de Reviewed-by: Laszlo Ersek ler...@redhat.com Signed-off-by: Luiz Capitulino lcapitul...@redhat.com --- qapi/opts-visitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qapi/opts-visitor.c b/qapi/opts-visitor.c index a59d306..e048b6c 100644 --- a/qapi/opts-visitor.c +++ b/qapi/opts-visitor.c @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov) g_hash_table_destroy(ov-unprocessed_opts); } g_free(ov-fake_id_opt); -memset(ov, '\0', sizeof *ov); +g_free(ov); } -- 1.7.11.2.249.g31c7954.dirty
[Qemu-devel] [PULL for-1.2 0/3]: QMP queue
Three little fixes. Two for QMP and one for HMP. The changes (since 682527c00409d676c0d3b9fac99ca3b2fdfd6d2c) are available in the following repository: git://repo.or.cz/qemu/qmp-unstable.git queue/qmp Blue Swirl (1): monitor: avoid declaring unused variables Juan Quintela (1): migration: move total_time from ram stats to migration info Stefan Weil (1): qapi: Fix memory leak hmp.c | 4 ++-- migration.c | 7 --- monitor.c | 2 +- qapi-schema.json| 14 +++--- qapi/opts-visitor.c | 2 +- qmp-commands.hx | 6 +++--- 6 files changed, 18 insertions(+), 17 deletions(-)
[Qemu-devel] [PATCH 2/3] monitor: avoid declaring unused variables
From: Blue Swirl blauwir...@gmail.com
Some variables are only used on !win32, declare
them only when used.
This avoids a warning in mingw32 build:
CCi386-softmmu/monitor.o
/src/qemu/monitor.c: In function 'monitor_fdset_get_fd':
/src/qemu/monitor.c:2575: warning: unused variable 'mon_fd_flags'
/src/qemu/monitor.c:2574: warning: unused variable 'mon_fdset_fd'
/src/qemu/monitor.c:2573: warning: unused variable 'mon_fdset'
Signed-off-by: Blue Swirl blauwir...@gmail.com
Reviewed-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index ce42466..480f583 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2570,11 +2570,11 @@ FdsetInfoList *qmp_query_fdsets(Error **errp)
int monitor_fdset_get_fd(int64_t fdset_id, int flags)
{
+#ifndef _WIN32
MonFdset *mon_fdset;
MonFdsetFd *mon_fdset_fd;
int mon_fd_flags;
-#ifndef _WIN32
QLIST_FOREACH(mon_fdset, mon_fdsets, next) {
if (mon_fdset-id != fdset_id) {
continue;
--
1.7.11.2.249.g31c7954.dirty
Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
Il 22/08/2012 15:13, Stefan Hajnoczi ha scritto: http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01741.html This is a real problem in practice. IE. the USB CD-ROM on this POWER7 blade limits transfers to 0x1e000 bytes for example and the Linux sr driver on the guest is going to try to give me bigger requests than that if I don't start limiting them, which will cause all sort of errors. It cannot be fixed for emulated SCSI HBAs in general but it can for virtio-scsi. For disks, this should be fixed simply by using scsi-block instead of scsi-generic. CD-ROMs are indeed more complicated because burning CDs cannot be done with syscalls. :/ Paolo
Re: [Qemu-devel] [PATCH V4 2/2] qemu-img: Add json output option to the info command.
On 08/22/2012 06:45 AM, Benoît Canet wrote:
This option --output=[human|json] make qemu-img info output on
human or JSON representation at the choice of the user.
@@ -1083,7 +1088,6 @@ out:
return 0;
}
-
static void dump_snapshots(BlockDriverState *bs)
{
Spurious whitespace change.
+static int img_info(int argc, char **argv)
+{
+int c;
+bool human = false, json = false;
+const char *filename, *fmt, *output;
+BlockDriverState *bs;
+ImageInfo *info;
fmt = NULL;
+output = NULL;
for(;;) {
-c = getopt(argc, argv, f:h);
+int option_index = 0;
+static struct option long_options[] = {
+{help, no_argument, 0, 'h'},
+{format, required_argument, 0, 'f'},
+{output, required_argument, 0, 'm'},
I would define a constant, such as 'enum {OPTION_FORMAT=256};', so that
you don't risk future confusion...
+{0, 0, 0, 0}
+};
+c = getopt_long(argc, argv, f:h,
...if we later do add an 'm' short option.
+long_options, option_index);
if (c == -1) {
break;
}
@@ -1128,6 +1299,9 @@ static int img_info(int argc, char **argv)
case 'f':
fmt = optarg;
break;
+case 'm':
Given the above, this would reuse your new named value.
@@ -1135,52 +1309,42 @@ static int img_info(int argc, char **argv)
}
filename = argv[optind++];
+if (output !strncmp(output, json, strlen(json))) {
Why strncmp? It ignores trailing garbage (as in --output=jsonoops).
Stick to strcmp.
+json = true;
+} else if (output !strncmp(output, human, strlen(human))) {
And again.
+human = true;
+} else {
+fprintf(stderr,
+Error: --output must be used with human or json as
argument.\n);
+return 1;
+}
If we get here, and --output=... was not given, then both human and json
are false. That's a problem, since...
+
+if (human) {
+dump_human_image_info(info);
+dump_snapshots(bs);
}
-bdrv_get_backing_filename(bs, backing_filename,
sizeof(backing_filename));
-if (backing_filename[0] != '\0') {
-bdrv_get_full_backing_filename(bs, backing_filename2,
- sizeof(backing_filename2));
-printf(backing file: %s, backing_filename);
-if (strcmp(backing_filename, backing_filename2) != 0) {
-printf( (actual path: %s), backing_filename2);
-}
-putchar('\n');
+
+if (json) {
+collect_snapshots(bs, info);
+dump_json_image_info(info);
}
-dump_snapshots(bs);
+
+qapi_free_ImageInfo(info);
...you will end up with no output. You want to default to human output
for back-compat to older usage.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH 3/3] migration: move total_time from ram stats to migration info
From: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
hmp.c| 4 ++--
migration.c | 7 ---
qapi-schema.json | 14 +++---
qmp-commands.hx | 6 +++---
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/hmp.c b/hmp.c
index a9d5675..81c8acb 100644
--- a/hmp.c
+++ b/hmp.c
@@ -149,6 +149,8 @@ void hmp_info_migrate(Monitor *mon)
if (info-has_status) {
monitor_printf(mon, Migration status: %s\n, info-status);
+monitor_printf(mon, total time: % PRIu64 milliseconds\n,
+ info-total_time);
}
if (info-has_ram) {
@@ -158,8 +160,6 @@ void hmp_info_migrate(Monitor *mon)
info-ram-remaining 10);
monitor_printf(mon, total ram: % PRIu64 kbytes\n,
info-ram-total 10);
-monitor_printf(mon, total time: % PRIu64 milliseconds\n,
- info-ram-total_time);
monitor_printf(mon, duplicate: % PRIu64 pages\n,
info-ram-duplicate);
monitor_printf(mon, normal: % PRIu64 pages\n,
diff --git a/migration.c b/migration.c
index 653a3c1..1edeec5 100644
--- a/migration.c
+++ b/migration.c
@@ -166,14 +166,15 @@ MigrationInfo *qmp_query_migrate(Error **errp)
case MIG_STATE_ACTIVE:
info-has_status = true;
info-status = g_strdup(active);
+info-has_total_time = true;
+info-total_time = qemu_get_clock_ms(rt_clock)
+- s-total_time;
info-has_ram = true;
info-ram = g_malloc0(sizeof(*info-ram));
info-ram-transferred = ram_bytes_transferred();
info-ram-remaining = ram_bytes_remaining();
info-ram-total = ram_bytes_total();
-info-ram-total_time = qemu_get_clock_ms(rt_clock)
-- s-total_time;
info-ram-duplicate = dup_mig_pages_transferred();
info-ram-normal = norm_mig_pages_transferred();
info-ram-normal_bytes = norm_mig_bytes_transferred();
@@ -193,13 +194,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
info-has_status = true;
info-status = g_strdup(completed);
+info-total_time = s-total_time;
info-has_ram = true;
info-ram = g_malloc0(sizeof(*info-ram));
info-ram-transferred = ram_bytes_transferred();
info-ram-remaining = 0;
info-ram-total = ram_bytes_total();
-info-ram-total_time = s-total_time;
info-ram-duplicate = dup_mig_pages_transferred();
info-ram-normal = norm_mig_pages_transferred();
info-ram-normal_bytes = norm_mig_bytes_transferred();
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..37f47e1 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -290,10 +290,6 @@
#
# @total: total amount of bytes involved in the migration process
#
-# @total-time: total amount of ms since migration started. If
-#migration has ended, it returns the total migration
-#time. (since 1.2)
-#
# @duplicate: number of duplicate pages (since 1.2)
#
# @normal : number of normal pages (since 1.2)
@@ -304,8 +300,7 @@
##
{ 'type': 'MigrationStats',
'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
- 'total-time': 'int', 'duplicate': 'int', 'normal': 'int',
- 'normal-bytes': 'int' } }
+ 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int' } }
##
# @XBZRLECacheStats
@@ -350,12 +345,17 @@
#migration statistics, only returned if XBZRLE feature is on
and
#status is 'active' or 'completed' (since 1.2)
#
+# @total-time: #optional total amount of milliseconds since migration started.
+#If migration has ended, it returns the total migration
+#time. (since 1.2)
+#
# Since: 0.14.0
##
{ 'type': 'MigrationInfo',
'data': {'*status': 'str', '*ram': 'MigrationStats',
'*disk': 'MigrationStats',
- '*xbzrle-cache': 'XBZRLECacheStats'} }
+ '*xbzrle-cache': 'XBZRLECacheStats',
+ '*total-time': 'int'} }
##
# @query-migrate
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 2ce4ce6..8671bf3 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2239,14 +2239,14 @@ The main json-object contains the following:
- status: migration status (json-string)
- Possible values: active, completed, failed, cancelled
+- total-time: total amount of ms since migration started. If
+migration has ended, it returns the total migration
+time (json-int)
- ram: only present if status is active, it is a json-object with the
following RAM information (in bytes):
- transferred: amount transferred (json-int)
- remaining: amount remaining (json-int)
- total: total (json-int)
- - total-time: total amount of ms since migration started. If
-
Re: [Qemu-devel] [PATCH V4 1/2] qapi: Add SnapshotInfo and ImageInfo.
Le Wednesday 22 Aug 2012 à 08:03:14 (-0600), Eric Blake a écrit : On 08/22/2012 06:45 AM, Benoît Canet wrote: Signed-off-by: Benoit Canet ben...@irqsave.net --- qapi-schema.json | 62 ++ 1 file changed, 62 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index a92adb1..4c4b9b9 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -126,6 +126,68 @@ 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] } ## +# @SnapshotInfo +# +# @id: unique snapshot id +# +# @name: user choosen name s/choosen/chosen/ +# +# @vm-state-size: size of the VM state +# +# @date-sec: UTC date of the snapshot +# +# @date-nsec: date in nano seconds +# +# @vm-clock-nsec: VM clock relative to boot in nano seconds Since we have two fields named *-nsec, it might be worth clarifying that date-nsec is merely the fractional portion to be combined with date-sec (always less than 10), while vm-clock-nsec includes seconds if the drift is that large. For that matter, should we even be exposing things in this manner? I know the internal struct has seconds and nanos separate for date, because it maps to struct timespec; but why can't we combine them into one giant number for JSON? Wouldn't people working with low level language be annoyed after parsing this JSON to have to split this combined number in two parts to fit them back into struct timespec ? Or are we worried about exceeding int64_t if we take seconds * 10 when dealing with the timestamp the snapshot was created, even though we aren't worried about the VM clock being that far away from boot? +# +# Since: 1.2 Probably too late for 1.2, so this should be 1.3. +## +# @ImageInfo: +# +# Information about a QEMU image file +# +# @filename: name of the image file +# +# @format: format of the image file +# +# @virtual-size: maximum capacity in bytes of the image +# +# @actual-size: #optional actual size on disk in bytes of the image That seems backwards - with a raw file, don't you know the actual size, but have no idea what it can further grow to? +# +# @dirty-flag: #optional true if image is not cleanly closed +# +# @cluster-size: #optional size of a cluster in bytes +# +# @encrypted: #optional true if the image is encrypted +# +# @backing-filename: #optional name of the backing file +# +# @full-backing-filename: #optional full path of the backing file +# +# @backing-filename-format: #optional the format of the backing file +# +# @snapshots: #optional list of VM snapshots +# +# Since: 1.2 Again, 1.3. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler
I have put together a test program and tried against a vanila copy of
qemu 1.1.1
The SVC wil be completely masked unless I apply patch 0002-target-arm-
Disable-priority_mask-feature.patch, which hacks arm_gic.c to initialise
the gic priority_mask to 0x100 instead of 0xf0. There doesn't appear to
be anyway to write to the gix priority_mask from arm code - maybe it
should be linked to the ARM Cortex BASEPRI?
Anyway the test code indicates execution does continue after the SVC
call before the exception is handled.
Where would you like me to upload/send the test code?
Cheers
Mark
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/657006
Title:
arm v7M - svc insn doesn't trigger PendSV handler
Status in QEMU:
New
Bug description:
The svc instruction doesn't work as expected.
- qemu 0.13.0 rc1 (git)
Test : demo with freeRTOS (for example
FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
If we start the scheduler, it will call that function (__attribute__
(( naked ))) :
void vPortStartFirstTask( void )
{
__asm volatile(
ldr r0, =0xE000ED08 \n /*
Use the NVIC offset register to locate the stack. */
ldr r0, [r0]
\n
ldr r0, [r0]
\n
msr msp, r0
\n /* Set the msp back to the start of the stack. */
svc 0
\n /* System call to start first task. */
);
}
The 4 first lines in asm work fine. The scv 0 call will rise the right
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will
never call the PendSV Handler (xPortPendSVHandler here). This function is
recorded in the nvic vector.
Next, (after the svc), the processor will execute the line after in code
(this is a naked function) so the next function written after
vPortStartFirstTask in the code.
command line :
console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
console 2 : arm-none-eabi-gdb -ex target remote localhost:1234
gcc/RTOSDemo.axf
arm-none-eabi from
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
Same error with another project with arm-elf
processor : arm cortex m3
host : gentoo (2.6.35-r9) (without kqemu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/657006/+subscriptions
Re: [Qemu-devel] For 1.2: Re: [PATCH 3/8] migration: move total_time from ram stats to migration info
On 08/22/2012 07:22 AM, Anthony Liguori wrote:
Just restating things to make sure I'm clear...
{ 'type': 'MigrationInfo',
'data': {'*status': 'str', '*ram': 'MigrationStats',
'*disk': 'MigrationStats',
- '*xbzrle-cache': 'XBZRLECacheStats'} }
+ '*xbzrle-cache': 'XBZRLECacheStats',
+ 'total-time': 'int'} }
Anthony - are you planning on taking this series for 1.2?
No. This is a new feature and we're past freeze.
No, the overall series (patches 1,2,4-8) is not appropriate at this time.
If we don't
get this patch in on time, then taking this for 1.3 would result in
changing released QMP interface (right now, there has been no release
with the field in the wrong type).
Ack. We need to preserve compat with the 1.2 interface.
Yes, this particular patch 3 is a bug fix in order to prevent a future
regression when 1.3 takes the rest of the series, and must therefore be
part of the 1.2 release (and Luiz is on top of that, via the qmp branch).
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/22/2012 05:41 PM, Richard Davies wrote: Avi Kivity wrote: Richard Davies wrote: I can trigger the slow boots without KSM and they have the same profile, with _raw_spin_lock_irqsave and isolate_freepages_block at the top. I reduced to 3x 20GB 8-core VMs on a 128GB host (rather than 3x 40GB 8-core VMs), and haven't managed to get a really slow boot yet (5 minutes). I'll post agan when I get one. I think you can go higher than that. But 120GB on a 128GB host is pushing it. I've now triggered a very slow boot at 3x 36GB 8-core VMs on a 128GB host (i.e. 108GB on a 128GB host). It has the same profile with _raw_spin_lock_irqsave and isolate_freepages_block at the top. Then it's still memory starved. Please provide /proc/zoneinfo while this is happening. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH V4 1/2] qapi: Add SnapshotInfo and ImageInfo.
On 08/22/2012 08:32 AM, Benoît Canet wrote: Since we have two fields named *-nsec, it might be worth clarifying that date-nsec is merely the fractional portion to be combined with date-sec (always less than 10), while vm-clock-nsec includes seconds if the drift is that large. For that matter, should we even be exposing things in this manner? I know the internal struct has seconds and nanos separate for date, because it maps to struct timespec; but why can't we combine them into one giant number for JSON? Wouldn't people working with low level language be annoyed after parsing this JSON to have to split this combined number in two parts to fit them back into struct timespec ? Perhaps, in which case, why don't we present vm-clock-nsec via two fields of seconds and fraction, for the same reasoning? My point is that we have two different bike shed colors showing in this one API, but I would prefer we be consistent and pick just one (as to _which_ color, I can be persuaded either way). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] memtest 4.20+ does not work with -cpu host
Hi, has anyone ever tested to run memtest with -cpu host flag passed to qemu-kvm? For me it resets when probing the chipset. With -cpu qemu64 it works just fine. Maybe this is specific to memtest, but it might be sth that can happen in other applications to. Any thoughts? Thanks, Peter
[Qemu-devel] Bug in option parsing
Hi everybody,
while coding the support for Jason's dump-guest-core option I realized
there is (probably) a problem with the way QEMU parses additional
machine options ('dump-guest-core', 'kvm_shadow_mem' etc.). Running QEMU
with option to -machine works ok, but using '-M' (as libvirt does) works
only w/o additional options, otherwise it ends in an error (the whole
string is probably parsed as a machine name).
Is '-M' so obsolete it shouldn't be used at all or is it just an bug? We
still use '-M' everywhere I know and '-machine' isn't compatible with
older versions and different builds of QEMU.
Should I file a bug or do we have to drop '-M' for this situations?
Have a nice day,
Martin
[Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size (v2)
From: Daniel P. Berrange berra...@redhat.com
Add a 'query-target' QAPI command to allow management applications
to determine what target architecture a QEMU binary is emulating
without having to parse the binary name or -help output
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{ u'return': { u'arch': u'x86_64' }}
Signed-off-by: Daniel P. Berrange berra...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
v1 - v2 (aliguori)
- remove 'bits' field
- switch command to return an enum
---
arch_init.c | 11 +++
configure|7 ++-
qapi-schema.json | 39 +++
qmp-commands.hx |5 +
4 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 9b46bfc..5a1173e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -44,6 +44,7 @@
#include exec-memory.h
#include hw/pcspk.h
#include qemu/page_cache.h
+#include qmp-commands.h
#ifdef DEBUG_ARCH_INIT
#define DPRINTF(fmt, ...) \
@@ -1080,3 +1081,13 @@ int xen_available(void)
return 0;
#endif
}
+
+
+TargetInfo *qmp_query_target(Error **errp)
+{
+TargetInfo *info = g_malloc0(sizeof(*info));
+
+info-arch = TARGET_TYPE;
+
+return info;
+}
diff --git a/configure b/configure
index 60d266f..d97fd81 100755
--- a/configure
+++ b/configure
@@ -3834,14 +3834,19 @@ case $target_arch2 in
;;
esac
+upper() {
+echo $@| LC_ALL=C tr '[a-z]' '[A-Z]'
+}
+
echo TARGET_SHORT_ALIGNMENT=$target_short_alignment $config_target_mak
echo TARGET_INT_ALIGNMENT=$target_int_alignment $config_target_mak
echo TARGET_LONG_ALIGNMENT=$target_long_alignment $config_target_mak
echo TARGET_LLONG_ALIGNMENT=$target_llong_alignment $config_target_mak
echo TARGET_ARCH=$TARGET_ARCH $config_target_mak
-target_arch_name=`echo $TARGET_ARCH | LC_ALL=C tr '[a-z]' '[A-Z]'`
+target_arch_name=`upper $TARGET_ARCH`
echo TARGET_$target_arch_name=y $config_target_mak
echo TARGET_ARCH2=$target_arch2 $config_target_mak
+echo TARGET_TYPE=TARGET_TYPE_`upper $target_arch2` $config_target_mak
echo TARGET_BASE_ARCH=$TARGET_BASE_ARCH $config_target_mak
if [ $TARGET_ABI_DIR = ]; then
TARGET_ABI_DIR=$TARGET_ARCH
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..72b3c4d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2454,3 +2454,42 @@
#
##
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
+
+##
+# @TargetType
+#
+# Target CPU emulation type
+#
+# These parameters correspond to the softmmu binary CPU name that is currently
+# running.
+#
+# Since: 1.2.0
+##
+{ 'enum': 'TargetType',
+ 'data': [ 'alpha', 'arm', 'cris', 'i386', 'lm32', 'm68k', 'microblazeel',
+'microblaze', 'mips64el', 'mips64', 'mipsel', 'mips', 'or32',
+'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb', 'sh4', 'sparc64',
+'sparc', 'unicore32', 'x86_64', 'xtensaeb', 'xtensa' ] }
+
+##
+# @TargetInfo:
+#
+# Information describing the QEMU target.
+#
+# @arch: the target architecture (eg x86_64, i386, etc)
+#
+# Since: 1.2.0
+##
+{ 'type': 'TargetInfo',
+ 'data': { 'arch': 'TargetType' } }
+
+##
+# @query-target:
+#
+# Return information about the target for this QEMU
+#
+# Returns: TargetInfo
+#
+# Since: 1.2.0
+##
+{ 'command': 'query-target', 'returns': 'TargetInfo' }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 2ce4ce6..00d798f 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2509,3 +2509,8 @@ EQMP
.mhandler.cmd_new = qmp_marshal_input_query_cpu_definitions,
},
+{
+.name = query-target,
+.args_type = ,
+.mhandler.cmd_new = qmp_marshal_input_query_target,
+},
--
1.7.5.4
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size (v2)
You can remove '/bit size' in the commit message 1st line.
On Wed, Aug 22, 2012 at 10:09:38AM -0500, Anthony Liguori wrote:
From: Daniel P. Berrange berra...@redhat.com
Add a 'query-target' QAPI command to allow management applications
to determine what target architecture a QEMU binary is emulating
without having to parse the binary name or -help output
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{ u'return': { u'arch': u'x86_64' }}
Signed-off-by: Daniel P. Berrange berra...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
v1 - v2 (aliguori)
- remove 'bits' field
- switch command to return an enum
---
arch_init.c | 11 +++
configure|7 ++-
qapi-schema.json | 39 +++
qmp-commands.hx |5 +
4 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 9b46bfc..5a1173e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -44,6 +44,7 @@
#include exec-memory.h
#include hw/pcspk.h
#include qemu/page_cache.h
+#include qmp-commands.h
#ifdef DEBUG_ARCH_INIT
#define DPRINTF(fmt, ...) \
@@ -1080,3 +1081,13 @@ int xen_available(void)
return 0;
#endif
}
+
+
+TargetInfo *qmp_query_target(Error **errp)
+{
+TargetInfo *info = g_malloc0(sizeof(*info));
+
+info-arch = TARGET_TYPE;
+
+return info;
+}
diff --git a/configure b/configure
index 60d266f..d97fd81 100755
--- a/configure
+++ b/configure
@@ -3834,14 +3834,19 @@ case $target_arch2 in
;;
esac
+upper() {
+echo $@| LC_ALL=C tr '[a-z]' '[A-Z]'
+}
+
echo TARGET_SHORT_ALIGNMENT=$target_short_alignment $config_target_mak
echo TARGET_INT_ALIGNMENT=$target_int_alignment $config_target_mak
echo TARGET_LONG_ALIGNMENT=$target_long_alignment $config_target_mak
echo TARGET_LLONG_ALIGNMENT=$target_llong_alignment $config_target_mak
echo TARGET_ARCH=$TARGET_ARCH $config_target_mak
-target_arch_name=`echo $TARGET_ARCH | LC_ALL=C tr '[a-z]' '[A-Z]'`
+target_arch_name=`upper $TARGET_ARCH`
echo TARGET_$target_arch_name=y $config_target_mak
echo TARGET_ARCH2=$target_arch2 $config_target_mak
+echo TARGET_TYPE=TARGET_TYPE_`upper $target_arch2` $config_target_mak
echo TARGET_BASE_ARCH=$TARGET_BASE_ARCH $config_target_mak
if [ $TARGET_ABI_DIR = ]; then
TARGET_ABI_DIR=$TARGET_ARCH
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..72b3c4d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2454,3 +2454,42 @@
#
##
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
+
+##
+# @TargetType
+#
+# Target CPU emulation type
+#
+# These parameters correspond to the softmmu binary CPU name that is
currently
+# running.
+#
+# Since: 1.2.0
+##
+{ 'enum': 'TargetType',
+ 'data': [ 'alpha', 'arm', 'cris', 'i386', 'lm32', 'm68k', 'microblazeel',
+'microblaze', 'mips64el', 'mips64', 'mipsel', 'mips', 'or32',
+'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb', 'sh4', 'sparc64',
+'sparc', 'unicore32', 'x86_64', 'xtensaeb', 'xtensa' ] }
+
+##
+# @TargetInfo:
+#
+# Information describing the QEMU target.
+#
+# @arch: the target architecture (eg x86_64, i386, etc)
+#
+# Since: 1.2.0
+##
+{ 'type': 'TargetInfo',
+ 'data': { 'arch': 'TargetType' } }
+
+##
+# @query-target:
+#
+# Return information about the target for this QEMU
+#
+# Returns: TargetInfo
+#
+# Since: 1.2.0
+##
+{ 'command': 'query-target', 'returns': 'TargetInfo' }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 2ce4ce6..00d798f 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2509,3 +2509,8 @@ EQMP
.mhandler.cmd_new = qmp_marshal_input_query_cpu_definitions,
},
+{
+.name = query-target,
+.args_type = ,
+.mhandler.cmd_new = qmp_marshal_input_query_target,
+},
The changes look fine to me.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] Bug in option parsing
On 2012-08-22 17:05, Martin Kletzander wrote:
Hi everybody,
while coding the support for Jason's dump-guest-core option I realized
there is (probably) a problem with the way QEMU parses additional
machine options ('dump-guest-core', 'kvm_shadow_mem' etc.). Running QEMU
with option to -machine works ok, but using '-M' (as libvirt does) works
only w/o additional options, otherwise it ends in an error (the whole
string is probably parsed as a machine name).
Is '-M' so obsolete it shouldn't be used at all or is it just an bug? We
still use '-M' everywhere I know and '-machine' isn't compatible with
older versions and different builds of QEMU.
Should I file a bug or do we have to drop '-M' for this situations?
If libvirt uses -M just like -machine, i.e. with more than a machine
name, that would be a libvirt bug (but that would have been noticed much
earlier - did you patch something?). QEMU only keeps -M machine-name
around to please existing users that didn't switch yet. It is NOT an
alias for -machine.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH v2] Fix copypaste typos in documentation comments
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu --- memory.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) v2: indented memory_region_init_ram_ptr diff --git a/memory.h b/memory.h index bd1bbae..f6c8e32 100644 --- a/memory.h +++ b/memory.h @@ -252,9 +252,9 @@ void memory_region_init_ram(MemoryRegion *mr, uint64_t size); /** - * memory_region_init_ram: Initialize RAM memory region from a user-provided. - * pointer. Accesses into the region will modify - * memory directly. + * memory_region_init_ram_ptr: Initialize RAM memory region from a + * user-provided pointer. Accesses into the + * region will modify memory directly. * * @mr: the #MemoryRegion to be initialized. * @name: the name of the region. @@ -581,7 +581,8 @@ void memory_region_add_subregion(MemoryRegion *mr, target_phys_addr_t offset, MemoryRegion *subregion); /** - * memory_region_add_subregion: Add a subregion to a container, with overlap. + * memory_region_add_subregion_overlap: Add a subregion to a container + * with overlap. * * Adds a subregion at @offset. The subregion may overlap with other * subregions. Conflicts are resolved by having a higher @priority hide a @@ -743,7 +744,7 @@ void memory_listener_unregister(MemoryListener *listener); void memory_global_dirty_log_start(void); /** - * memory_global_dirty_log_stop: begin dirty logging for all regions + * memory_global_dirty_log_stop: end dirty logging for all regions */ void memory_global_dirty_log_stop(void); -- 1.7.10
[Qemu-devel] [PATCH v2] console: Correct computation of bytes per pixel from bits per pixel
Division with round up is the correct way to compute this even if the
only case where division with round down gives incorrect result is
probably 15 bpp. This case was explicitely patched up in one of these
functions but was unhandled in the other. (I'm not sure about setting
16 bpp for the 15bpp case either but I left that there for now.)
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
console.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
v2: Use DIV_ROUND_UP and extended commit message
diff --git a/console.c b/console.c
index 4525cc7..9df1701 100644
--- a/console.c
+++ b/console.c
@@ -1612,7 +1612,7 @@ PixelFormat qemu_different_endianness_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
@@ -1661,13 +1661,12 @@ PixelFormat qemu_default_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
case 15:
pf.bits_per_pixel = 16;
-pf.bytes_per_pixel = 2;
pf.rmask = 0x7c00;
pf.gmask = 0x03E0;
pf.bmask = 0x001F;
--
1.7.10
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/22/2012 10:41 AM, Richard Davies wrote: Avi Kivity wrote: Richard Davies wrote: I can trigger the slow boots without KSM and they have the same profile, with _raw_spin_lock_irqsave and isolate_freepages_block at the top. I reduced to 3x 20GB 8-core VMs on a 128GB host (rather than 3x 40GB 8-core VMs), and haven't managed to get a really slow boot yet (5 minutes). I'll post agan when I get one. I think you can go higher than that. But 120GB on a 128GB host is pushing it. I've now triggered a very slow boot at 3x 36GB 8-core VMs on a 128GB host (i.e. 108GB on a 128GB host). It has the same profile with _raw_spin_lock_irqsave and isolate_freepages_block at the top. That's the page compaction code. Mel Gorman and I have been working to fix that, the latest fixes and improvements are in the -mm kernel already.
Re: [Qemu-devel] [PATCH] vmware_vga: Cleanup and allow simple drivers to work without the fifo
On 2012-08-22 12:19, BALATON Zoltan wrote: On Wed, 22 Aug 2012, Jan Kiszka wrote: This is a rather big patch. I strongly suspect you can break it up into smaller pieces that address separate aspects one-by-one. Also, it is definitely to heavy for qemu-trivial. Despite its size the changes included are fairly simple but I can try to break it up. I've sent it to qemu-trivial because it may meet the Do not fall under an actively maintained subsystem. But that doesn't make it trivial, rather harder (if no one reviewed it). category as I've found no maintainer for this part. Should I send the revisions only to qemu-devel then? Yes, that's more appropriate IMHO. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] console: Correct computation of bytes per pixel from bits per pixel
On 2012-08-22 17:19, BALATON Zoltan wrote:
Division with round up is the correct way to compute this even if the
only case where division with round down gives incorrect result is
probably 15 bpp. This case was explicitely patched up in one of these
functions but was unhandled in the other. (I'm not sure about setting
16 bpp for the 15bpp case either but I left that there for now.)
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
console.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
v2: Use DIV_ROUND_UP and extended commit message
diff --git a/console.c b/console.c
index 4525cc7..9df1701 100644
--- a/console.c
+++ b/console.c
@@ -1612,7 +1612,7 @@ PixelFormat
qemu_different_endianness_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
@@ -1661,13 +1661,12 @@ PixelFormat qemu_default_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
case 15:
pf.bits_per_pixel = 16;
-pf.bytes_per_pixel = 2;
Removed unintentionally?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Windows slow boot: contractor wanted
Rik van Riel wrote: Richard Davies wrote: I've now triggered a very slow boot at 3x 36GB 8-core VMs on a 128GB host (i.e. 108GB on a 128GB host). It has the same profile with _raw_spin_lock_irqsave and isolate_freepages_block at the top. That's the page compaction code. Mel Gorman and I have been working to fix that, the latest fixes and improvements are in the -mm kernel already. Hi Rik, That's good news. Can you point me to specific patches which we can backport to a 3.5.2 kernel to test whether they fix our problem? Thanks, Richard.
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size (v2)
On 08/22/2012 09:09 AM, Anthony Liguori wrote:
From: Daniel P. Berrange berra...@redhat.com
Add a 'query-target' QAPI command to allow management applications
to determine what target architecture a QEMU binary is emulating
without having to parse the binary name or -help output
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{ u'return': { u'arch': u'x86_64' }}
Signed-off-by: Daniel P. Berrange berra...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
+
+##
+# @TargetInfo:
+#
+# Information describing the QEMU target.
+#
+# @arch: the target architecture (eg x86_64, i386, etc)
Missed my v1 comment that 'eg' is misspelled (would be 'e.g.'), and with
my recommendation for an alternate wording:
@arch: the target architecture (such as x86_64 or i686)
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH for-1.2 v2 4/5] MAINTAINERS: Document Bamboo machine and ppc4xx devices
Place it in alphabetical order and add new Devices section ppc4xx to share file rules with 405 and virtex_ml507. Signed-off-by: Andreas Färber afaer...@suse.de Cc: Alexander Graf ag...@suse.de --- MAINTAINERS | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e6b2409..f833a6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -352,6 +352,12 @@ L: qemu-...@nongnu.org S: Odd Fixes F: hw/ppc405_boards.c +Bamboo +M: Alexander Graf ag...@suse.de +L: qemu-...@nongnu.org +S: Odd Fixes +F: hw/ppc440_bamboo.c + e500 M: Alexander Graf ag...@suse.de M: Scott Wood scottw...@freescale.com @@ -474,6 +480,12 @@ S: Supported F: hw/pci* F: hw/piix* +ppc4xx +M: Alexander Graf ag...@suse.de +L: qemu-...@nongnu.org +S: Odd Fixes +F: hw/ppc4xx*.[hc] + ppce500 M: Alexander Graf ag...@suse.de M: Scott Wood scottw...@freescale.com -- 1.7.7
[Qemu-devel] [PATCH for-1.2 v2 0/5] target-ppc: MAINTAINERS additions
Hi Alex, Here's an updated and squashed series adding some MAINTAINERS sections for ppc machines and their devices. Based on Peter's suggestion the machines are no longer grouped by ppc4xx chipset but ordered alphabetically, and the shared devices both for ppc4xx and e500 get their own Devices sections for rule sharing across machines. Since this is documentation only I would like to get this into rc1. Feel free to adapt/reorder in any way you see fit to document things. Regards, Andreas Cc: Alexander Graf ag...@suse.de Cc: Edgar E. Iglesias edgar.igles...@gmail.com Cc: Peter Maydell peter.mayd...@linaro.org v1 - v2: * Rebased onto splitup and relocation of mpc8544ds machine * Order machines alphabetically (PMM) * Split out devices used by more than one machine into own Devices sections Andreas Färber (5): MAINTAINERS: Document sPAPR (pSeries) machine MAINTAINERS: Document e500 machines and devices MAINTAINERS: Downgrade ppc405 to Odd Fixes MAINTAINERS: Document Bamboo machine and ppc4xx devices MAINTAINERS: Document virtex_ml507 machine MAINTAINERS | 50 +- roms/SLOF |2 +- 2 files changed, 50 insertions(+), 2 deletions(-) -- 1.7.7
[Qemu-devel] [PATCH for-1.2 v2 3/5] MAINTAINERS: Downgrade ppc405 to Odd Fixes
As requested by Alex. Signed-off-by: Andreas Färber afaer...@suse.de --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 618045b..e6b2409 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -349,7 +349,7 @@ PowerPC Machines 405 M: Alexander Graf ag...@suse.de L: qemu-...@nongnu.org -S: Maintained +S: Odd Fixes F: hw/ppc405_boards.c e500 -- 1.7.7
[Qemu-devel] [PATCH for-1.2 v2 2/5] MAINTAINERS: Document e500 machines and devices
Signed-off-by: Andreas Färber afaer...@suse.de Cc: Alexander Graf ag...@suse.de Cc: Scott Wood scottw...@freescale.com --- MAINTAINERS | 23 +++ roms/SLOF |2 +- 2 files changed, 24 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index aab3235..618045b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -352,6 +352,22 @@ L: qemu-...@nongnu.org S: Maintained F: hw/ppc405_boards.c +e500 +M: Alexander Graf ag...@suse.de +M: Scott Wood scottw...@freescale.com +L: qemu-...@nongnu.org +S: Supported +F: hw/ppc/e500.[hc] +F: hw/ppc/e500plat.c + +mpc8544ds +M: Alexander Graf ag...@suse.de +M: Scott Wood scottw...@freescale.com +L: qemu-...@nongnu.org +S: Supported +F: hw/ppc/mpc8544ds.c +F: hw/mpc8544_guts.c + New World M: Alexander Graf ag...@suse.de L: qemu-...@nongnu.org @@ -458,6 +474,13 @@ S: Supported F: hw/pci* F: hw/piix* +ppce500 +M: Alexander Graf ag...@suse.de +M: Scott Wood scottw...@freescale.com +L: qemu-...@nongnu.org +S: Supported +F: hw/ppce500_* + SCSI M: Paolo Bonzini pbonz...@redhat.com S: Supported diff --git a/roms/SLOF b/roms/SLOF index f21f7a3..7279655 16 --- a/roms/SLOF +++ b/roms/SLOF @@ -1 +1 @@ -Subproject commit f21f7a3f46b557eb5923f899ce8b4401b3cc6d91 +Subproject commit 7279655af2eba855bd2df61303d25abd1eeb2300 -- 1.7.7
