Re: [Qemu-devel] [PATCH V5 11/17] qapi: Add new command to query colo status
On Sun, Mar 11, 2018 at 5:33 AM, Eric Blake wrote:
> On 03/10/2018 03:22 PM, Zhang Chen wrote:
>
>> Libvirt or other high level sofware can use this command query colo
>> status.
>>
>
> s/sofware/software/
>
> You can test this command like that:
>> {'execute':'query-colo-status'}
>>
>> Signed-off-by: Zhang Chen
>> ---
>> migration/colo.c| 35 +++
>> qapi/migration.json | 35 +++
>> 2 files changed, 70 insertions(+)
>>
>>
> +++ b/qapi/migration.json
>> @@ -1201,3 +1201,38 @@
>> # Since: 2.9
>> ##
>> { 'command': 'xen-colo-do-checkpoint' }
>> +
>> +##
>> +# @COLOStatus:
>> +#
>> +# The result format for 'query-colo-status'.
>> +#
>> +# @mode: which COLO mode the VM was in when it exited.
>> +#true is primary mode, false is secondary mode.
>>
>
> Eww. Why not make this an enum ("primary", "secondary") instead of having
> to remember what true means?
>
> +#
>> +# @colo_running: if true means COLO running well, otherwise COLO have
>> done.
>>
>
> New interfaces should use '-' rather than '_' as the separator; this
> should be 'colo-running'
>
> +#
>> +# @reason: describes the reason for the COLO exit.
>> +# true is error, false is user request.
>>
>
> Again, would an enum ("error", "user") be nicer than a bool? It is also
> more extensible if you add a third reason down the road.
>
> +#
>> +# Since: 2.12
>> +##
>> +{ 'struct': 'COLOStatus',
>> + 'data': { 'mode': 'bool', 'colo_running': 'bool', 'reason': 'bool' } }
>> +
>> +##
>> +# @query-colo-status:
>> +#
>> +# Query COLO status while the vm is running.
>> +#
>> +# Returns: A @COLOStatus object showing the status.
>> +#
>> +# Example:
>> +#
>> +# -> { "execute": "query-colo-status" }
>> +# <- { "return": { "colo_running": "true", "mode": "true", "reason":
>> "true" } }
>>
>
> Inconsistent with your declaration above; if these are truly declared
> 'bool', then the example should be (with the spelling fix, but not fixing
> where you should have been using enums instead of bools):
>
> { "return": { "colo-running": true, "mode": true, "reason": true } }
>
> We're awfully close to soft freeze, and this is a new feature - which
> maintainer will be trying to get this polished and into the tree in time?
Maybe Paolo or David? CC paolo and David, any comments about this series?
I have addressed all comments about this patch and sent the PATCH V6,
Thanks your comments and please review it.
Thanks
Zhang Chen
>
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
[Qemu-devel] [PATCH V6 16/17] COLO: notify net filters about checkpoint/failover event
From: zhanghailiang
Notify all net filters about the checkpoint and failover event.
Signed-off-by: zhanghailiang
---
migration/colo.c | 12
1 file changed, 12 insertions(+)
diff --git a/migration/colo.c b/migration/colo.c
index f3d588e..1a59baa 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -87,6 +87,11 @@ static void secondary_vm_do_failover(void)
if (local_err) {
error_report_err(local_err);
}
+/* Notify all filters of all NIC to do checkpoint */
+colo_notify_filters_event(COLO_EVENT_FAILOVER, &local_err);
+if (local_err) {
+error_report_err(local_err);
+}
if (!autostart) {
error_report("\"-S\" qemu option will be ignored in secondary side");
@@ -796,6 +801,13 @@ void *colo_process_incoming_thread(void *opaque)
goto out;
}
+/* Notify all filters of all NIC to do checkpoint */
+colo_notify_filters_event(COLO_EVENT_CHECKPOINT, &local_err);
+if (local_err) {
+qemu_mutex_unlock_iothread();
+goto out;
+}
+
vmstate_loading = false;
vm_start();
trace_colo_vm_state_change("stop", "run");
--
2.7.4
[Qemu-devel] [PATCH V6 17/17] COLO: quick failover process by kick COLO thread
From: zhanghailiang
COLO thread may sleep at qemu_sem_wait(&s->colo_checkpoint_sem),
while failover works begin, It's better to wakeup it to quick
the process.
Signed-off-by: zhanghailiang
---
migration/colo.c | 8
1 file changed, 8 insertions(+)
diff --git a/migration/colo.c b/migration/colo.c
index 1a59baa..1bc5f02 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -134,6 +134,11 @@ static void primary_vm_do_failover(void)
migrate_set_state(&s->state, MIGRATION_STATUS_COLO,
MIGRATION_STATUS_COMPLETED);
+/*
+ * kick COLO thread which might wait at
+ * qemu_sem_wait(&s->colo_checkpoint_sem).
+ */
+colo_checkpoint_notify(migrate_get_current());
/*
* Wake up COLO thread which may blocked in recv() or send(),
@@ -549,6 +554,9 @@ static void colo_process_checkpoint(MigrationState *s)
qemu_sem_wait(&s->colo_checkpoint_sem);
+if (s->state != MIGRATION_STATUS_COLO) {
+goto out;
+}
ret = colo_do_checkpoint_transaction(s, bioc, fb);
if (ret < 0) {
goto out;
--
2.7.4
[Qemu-devel] [Bug 1754542] Re: colo: secondary vm crash when execute x-colo-lost-heartbeat
** Description changed:
I use Arch Linux x86_64
- both qemu 2.11.1 and Zhang
Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
+ Zhang
Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
Secondary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
file.backing.backing=colo-disk0 \
-incoming tcp:0:
Secondary:
{'execute':'qmp_capabilities'}
{ 'execute': 'nbd-server-start',
'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33',
'port': '8889'} } }
}
{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0',
'writable': true } }
Primary:
{'execute':'qmp_capabilities'}
{ 'execute': 'human-monitor-command',
'arguments': {'command-line': 'drive_add -n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}}
{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node':
'nbd_client0' } }
{ 'execute': 'migrate-set-capabilities',
'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true
} ] } }
{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:' } }
{ 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay':
2000 } }
- Above are all OK.Two VM syncing.
-
+ And two VM with cash
Primary:
- { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0',
'child': 'children.1'}}
- { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del
blk-buddy0'}}
+ {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event":
"RESUME"}
+ [1]329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
Secondary:
- { 'execute': 'nbd-server-stop' }
- { 'execute': 'x-colo-lost-heartbeat' }
+ {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event":
"RESUME"}
+ [1]367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
- But When I execute x-colo-lost-heartbeat.Primary run Secondary cash
-
- { 'execute': 'nbd-server-stop' }
- {"return": {}}
- qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before
all bytes were read
- { 'execute': 'x-colo-lost-heartbeat' }
- {"return": {}}
- qemu-system-x86_64: Can't receive COLO message: Input/output error
- **
- ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion
failed (obj->ref > 0): (0 > 0)
- [1]2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm
-m 2048 -smp 2 -qmp stdi
+ if use qemu 2.11.1
+ The sync will success,but when Secondary VM execute
x-colo-lost-heartbeat,Secondary VM will crash
** Description changed:
I use Arch Linux x86_64
Zhang
Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
Secondary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file
[Qemu-devel] [Bug 1754542] Re: colo: vm crash with segmentation fault
** Summary changed:
- colo: secondary vm crash when execute x-colo-lost-heartbeat
+ colo: vm crash with segmentation fault
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754542
Title:
colo: vm crash with segmentation fault
Status in QEMU:
New
Bug description:
I use Arch Linux x86_64
Zhang
Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
Secondary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
file.backing.backing=colo-disk0 \
-incoming tcp:0:
Secondary:
{'execute':'qmp_capabilities'}
{ 'execute': 'nbd-server-start',
'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33',
'port': '8889'} } }
}
{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0',
'writable': true } }
Primary:
{'execute':'qmp_capabilities'}
{ 'execute': 'human-monitor-command',
'arguments': {'command-line': 'drive_add -n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}}
{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node':
'nbd_client0' } }
{ 'execute': 'migrate-set-capabilities',
'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true
} ] } }
{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:' } }
{ 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay':
2000 } }
And two VM with cash
Primary:
{"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event":
"RESUME"}
[1]329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
Secondary:
{"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event":
"RESUME"}
[1]367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
-
if use qemu 2.11.1
The sync will success,but when Secondary VM execute
x-colo-lost-heartbeat,Secondary VM will crash
Secondary:
{ 'execute': 'nbd-server-stop' }
{ 'execute': 'x-colo-lost-heartbeat' }{"return": {}}
qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before
all bytes were read
{"return": {}}
qemu-system-x86_64: Can't receive COLO message: Input/output error
**
ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion
failed (obj->ref > 0): (0 > 0)
[1]1276 abort sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm
-m 2048 -smp 2 -qmp stdi
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions
Re: [Qemu-devel] [PATCH v8 19/23] SiFive RISC-V UART Device
Hi Mark, On 03/10/2018 10:40 AM, Mark Cave-Ayland wrote: > On 10/03/18 03:02, Michael Clark wrote: > >> On Sat, Mar 10, 2018 at 1:39 AM, Philippe Mathieu-Daudé >> wrote: >> [...] > Another general note: for each of the main QEMU platforms supported > there is a home page on the official wiki, so do make sure that you set > yourself a template for RiscV and add some information to help people > get started. > Thanks for the pointer. I went ahead and created a basic page for RISC-V with instructions on how to build QEMU and boot Fedora. Cheers, Bastian
Re: [Qemu-devel] [PATCH v2] RISC-V: Fix riscv_isa_string, use popcount to count bits
On 03/10/2018 10:25 PM, Philippe Mathieu-Daudé wrote:
> On 03/09/2018 10:01 PM, Michael Clark wrote:
>> Logic bug caused the string size calculation for the RISC-V
>> format ISA string to be small. This fix allows slack for rv128.
>>
>> Cc: Palmer Dabbelt
>> Cc: Peter Maydell
>> Cc: Eric Blake
>> Signed-off-by: Michael Clark
>> ---
>> target/riscv/cpu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>> index 4851890..1456535 100644
>> --- a/target/riscv/cpu.c
>> +++ b/target/riscv/cpu.c
>> @@ -391,7 +391,7 @@ static const TypeInfo riscv_cpu_type_info = {
>> char *riscv_isa_string(RISCVCPU *cpu)
>> {
>> int i;
>> -size_t maxlen = 5 + ctz32(cpu->env.misa);
>> +size_t maxlen = 8 + ctpop64(cpu->env.misa);
>
> Can you document the magic 5/8?
>
> This looks nice, but this seems to me too much optimization to save few
> bytes, using sizeof(riscv_exts) is overflow-free.
>
> Maybe this is enough and self-explanatory:
>
>const size_t maxlen = sizeof("rv128") + sizeof(riscv_exts);
Oops:
const size_t maxlen = sizeof("rv128") + sizeof(riscv_exts) + 1;
>
>> char *isa_string = g_new0(char, maxlen);
>> snprintf(isa_string, maxlen, "rv%d", TARGET_LONG_BITS);
>
> Also, if you keep the snprintf() return value, you can (naming it 'n')
> simplify (also easier to review):
>
>> for (i = 0; i < sizeof(riscv_exts); i++) {
>>
> if (cpu->env.misa & RV(riscv_exts[i])) {
> - isa_string[strlen(isa_string)] = riscv_exts[i] - 'A' + 'a';
> + isa_string[n++] = tolower(riscv_exts[i]);
> }
> }
>
> and simply use g_new() with:
>
> + isa_string[n] = '\0';
>
> return isa_string;
> }
>
> Regards,
>
> Phil.
>
Re: [Qemu-devel] qemu 2.10.2 : util/qemu-thread-posix.c: 64: qemu_mutex_lock: Assertion 'mutex->initialized' failed
On 11 March 2018 at 06:58, Eva Chen wrote: > Hello, > > I am working on compiling QEMU 2.10.2 to a static library. > > Everything works fine in compiling QEMU to an execution > file(qemu-system-aarch64), but after I link all .o and .a file to create a > QEMU library and write a c file to call qemu_main() in qemu/util/vl.c(I > have changed the name "main()" into "qemu_main()"), then it shows this > error message. This isn't really supported, so you're kind of on your own here, but I have a few debugging suggestions below: > util/qemu-thread-posix.c: 64: qemu_mutex_lock: Assertion > 'mutex->initialized' failed. > Abort (core dumped) > > > The information of gdb's backtrace is shown as bellow > (gdb) bt > > *#o Ox705b31f7 in raise () at /usr/lib64/libc.so.6 > #1 0x705b48e8 in abort () at /usr/lib64/libc.s0.6 > #2 0x705ac266 in assert fail base () at /usr/lib64/libc.so.6 > #3 0x705ac312 in 0 at /usr/lib64/libc.so.6 > #4 0x005c47e3 in qemu_mutex_lock (mutex=mutex@entry=0xd84be0 > ) at > util/qemu-thread-posix.c:64 > #5 0x005d5b46 in rcu_register_thread() at util/rcu.c:290 > #6 0x75a790de in rcu_init_complete () at util/rcu.c:318, > #7 Ox77dea503 in _dl_init_internal () at /lib64/ld.linux-x86-64.50.2 > #8 0x77ddclaa in _dl_start_user () at /lib64/ld.linux - x86-64.so.2 > #9 0x0014 in ()* > > I found out that it aborted before conducted to the main function in QEMU This happens before main because this backtrace is from rcu_init() in util/rcu.c, which is marked as __attribute__((__constructor__)), so it is called before main(). (As an aside, you'll probably find your backtraces are more helpful and debugging is easier if you configure QEMU with --enable-debug, which will mean we compile with debug rather than optimization. When you've got it working you can make the final build a non-debug one.) > Also, I use si and n in gdb to see what happened in this QEMU library > it showed that the address and content of *rcu_registry_lock* would change > when it executed qemu_thread_create() in util/rcu.c:315 > > $ qemu_thread_create(&thread, "cal_rcu", call_rcu_thread, NULL, > QEMU_THREAD_DETACHED) > > This change caused the failure of assert(mutex->initialized) in > qemu_mutex_lock (which called by rcu_register_thread() in call_rcu_thread()) That's odd, because mutex->initialized is supposed to be set by qemu_mutex_init() and then not written until something calls qemu_mutex_destroy(). If I were you I'd try using debugger watchpoints to find out where the code is that's overwriting mutex->initialized. thanks -- PMM
Re: [Qemu-devel] [PATCH 4/4] hw/pci: remove obsolete PCIDevice->init()
Hi Michael, Paolo.
Now than all other PCI QOM'ification patches got applied, can you take
this patch for 2.12?
Thanks,
Phil.
On 12/17/2017 09:49 PM, Philippe Mathieu-Daudé wrote:
> All PCI devices are now QOM'ified.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/pci/pci.h | 1 -
> hw/pci/pci.c | 14 --
> 2 files changed, 15 deletions(-)
>
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index 8d02a0a383..0f1ed64c2f 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -217,7 +217,6 @@ typedef struct PCIDeviceClass {
> DeviceClass parent_class;
>
> void (*realize)(PCIDevice *dev, Error **errp);
> -int (*init)(PCIDevice *dev);/* TODO convert to realize() and remove */
> PCIUnregisterFunc *exit;
> PCIConfigReadFunc *config_read;
> PCIConfigWriteFunc *config_write;
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index b2d139bd9a..cd25ab6f6b 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2054,18 +2054,6 @@ static void pci_qdev_realize(DeviceState *qdev, Error
> **errp)
> }
> }
>
> -static void pci_default_realize(PCIDevice *dev, Error **errp)
> -{
> -PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
> -
> -if (pc->init) {
> -if (pc->init(dev) < 0) {
> -error_setg(errp, "Device initialization failed");
> -return;
> -}
> -}
> -}
> -
> PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool
> multifunction,
> const char *name)
> {
> @@ -2538,13 +2526,11 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
> static void pci_device_class_init(ObjectClass *klass, void *data)
> {
> DeviceClass *k = DEVICE_CLASS(klass);
> -PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
>
> k->realize = pci_qdev_realize;
> k->unrealize = pci_qdev_unrealize;
> k->bus_type = TYPE_PCI_BUS;
> k->props = pci_props;
> -pc->realize = pci_default_realize;
> }
>
> static void pci_device_class_base_init(ObjectClass *klass, void *data)
>
[Qemu-devel] [PATCH V1]sm501: dead code removal
From: Aishwarya Kadlag
Remove support for DEPTH != 32 values from hw/display/*_template.h
files and other files that include them. Only DEPTH == 32 case is
supported.
Signed-off-by: Aishwarya Kadlag
---
hw/display/sw501_1.c | 36
hw/display/sw501_template_1.h |4 +++-
2 files changed, 3 insertions(+), 37 deletions(-)
diff -u sm501.c sm501_1.c > sm501.patch -s
--- sm501.c 2018-03-11 17:46:33.621452968 +0530
+++ sm501_1.c 2018-03-11 17:53:26.933445566 +0530
@@ -1358,22 +1358,6 @@
int width, const uint8_t *palette,
int c_x, int c_y);
-#define DEPTH 8
-#include "sm501_template.h"
-
-#define DEPTH 15
-#include "sm501_template.h"
-
-#define BGR_FORMAT
-#define DEPTH 15
-#include "sm501_template.h"
-
-#define DEPTH 16
-#include "sm501_template.h"
-
-#define BGR_FORMAT
-#define DEPTH 16
-#include "sm501_template.h"
#define DEPTH 32
#include "sm501_template.h"
@@ -1383,43 +1367,23 @@
#include "sm501_template.h"
static draw_line_func *draw_line8_funcs[] = {
-draw_line8_8,
-draw_line8_15,
-draw_line8_16,
draw_line8_32,
draw_line8_32bgr,
-draw_line8_15bgr,
-draw_line8_16bgr,
};
static draw_line_func *draw_line16_funcs[] = {
-draw_line16_8,
-draw_line16_15,
-draw_line16_16,
draw_line16_32,
draw_line16_32bgr,
-draw_line16_15bgr,
-draw_line16_16bgr,
};
static draw_line_func *draw_line32_funcs[] = {
-draw_line32_8,
-draw_line32_15,
-draw_line32_16,
draw_line32_32,
draw_line32_32bgr,
-draw_line32_15bgr,
-draw_line32_16bgr,
};
static draw_hwc_line_func *draw_hwc_line_funcs[] = {
-draw_hwc_line_8,
-draw_hwc_line_15,
-draw_hwc_line_16,
draw_hwc_line_32,
draw_hwc_line_32bgr,
-draw_hwc_line_15bgr,
-draw_hwc_line_16bgr,
};
static inline int get_depth_index(DisplaySurface *surface)
diff -u sm501_template.h sm501_template_1.h > sm501_template.patch -s
--- sm501_template.h2018-03-11 17:25:36.816653718 +0530
+++ sm501_template_1.h 2018-03-11 17:25:16.828654076 +0530
@@ -22,13 +22,15 @@
* THE SOFTWARE.
*/
+/*
#if DEPTH == 8
#define BPP 1
#define PIXEL_TYPE uint8_t
#elif DEPTH == 15 || DEPTH == 16
#define BPP 2
#define PIXEL_TYPE uint16_t
-#elif DEPTH == 32
+*/
+#if DEPTH == 32
#define BPP 4
#define PIXEL_TYPE uint32_t
#else
Re: [Qemu-devel] [PATCH 1/1] dump: Update correct kdump phys_base field for AArch64
Hi
On Fri, Mar 9, 2018 at 6:03 PM, Wei Huang wrote:
> For guest kernel that supports KASLR, the load address can change every
> time when guest VM runs. To find the physical base address correctly,
> current QEMU dump searches VMCOREINFO for the string "NUMBER(phys_base)=".
> However this string pattern is only available on x86_64. AArch64 uses a
> different field, called "NUMBER(PHYS_OFFSET)=". This patch makes sure
> QEMU dump uses the correct string on AArch64.
>
> Signed-off-by: Wei Huang
Reviewed-by: Marc-André Lureau
> ---
> dump.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/dump.c b/dump.c
> index 097e60b..6bdb0db 100644
> --- a/dump.c
> +++ b/dump.c
> @@ -1609,10 +1609,18 @@ static void vmcoreinfo_update_phys_base(DumpState *s)
>
> lines = g_strsplit((char *)vmci, "\n", -1);
> for (i = 0; lines[i]; i++) {
> -if (g_str_has_prefix(lines[i], "NUMBER(phys_base)=")) {
> -if (qemu_strtou64(lines[i] + 18, NULL, 16,
> +const char *prefix = NULL;
> +
> +if (s->dump_info.d_machine == EM_X86_64) {
> +prefix = "NUMBER(phys_base)=";
> +} else if (s->dump_info.d_machine == EM_AARCH64) {
> +prefix = "NUMBER(PHYS_OFFSET)=";
> +}
> +
> +if (prefix && g_str_has_prefix(lines[i], prefix)) {
> +if (qemu_strtou64(lines[i] + strlen(prefix), NULL, 16,
>&phys_base) < 0) {
> -warn_report("Failed to read NUMBER(phys_base)=");
> +warn_report("Failed to read %s", prefix);
> } else {
> s->dump_info.phys_base = phys_base;
> }
> --
> 1.8.3.1
>
[Qemu-devel] [PATCH] 9p: Convert use of atoi to qemu_strtol to allow error checking
Signed-off-by: Nia Alarie
---
hw/9pfs/9p.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 48fa48e720..64f3bb976c 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -15,6 +15,7 @@
#include
#include "hw/virtio/virtio.h"
#include "qapi/error.h"
+#include "qemu/cutils.h"
#include "qemu/error-report.h"
#include "qemu/iov.h"
#include "qemu/sockets.h"
@@ -2213,8 +2214,15 @@ static void coroutine_fn v9fs_create(void *opaque)
}
v9fs_path_copy(&fidp->path, &path);
} else if (perm & P9_STAT_MODE_LINK) {
-int32_t ofid = atoi(extension.data);
-V9fsFidState *ofidp = get_fid(pdu, ofid);
+long ofid;
+V9fsFidState *ofidp;
+
+if (qemu_strtol(extension.data, NULL, 10, &ofid) ||
+ofid > INT32_MAX || ofid < INT32_MIN) {
+err = -EINVAL;
+goto out;
+}
+ofidp = get_fid(pdu, (int32_t)ofid);
if (ofidp == NULL) {
err = -EINVAL;
goto out;
--
2.16.2
Re: [Qemu-devel] [PATCH] xen-pvdevice: Introduce a simplistic xen-pvdevice save state
On Thu, 8 Mar 2018, Igor Druzhinin wrote:
> This should help to avoid problems with accessing the device after
> migration/resume without PV drivers. Older systems will acquire
> the new record when migrated which should not change their state for
> worse.
Could you please explain what problems this patch is helping avoid? And
also how this patch is helping exactly?
Please add more concrete info.
> Signed-off-by: Igor Druzhinin
> ---
> hw/i386/xen/xen_pvdevice.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c
> index c093b34..ef22a03 100644
> --- a/hw/i386/xen/xen_pvdevice.c
> +++ b/hw/i386/xen/xen_pvdevice.c
> @@ -71,6 +71,16 @@ static const MemoryRegionOps xen_pv_mmio_ops = {
> .endianness = DEVICE_LITTLE_ENDIAN,
> };
>
> +static const VMStateDescription vmstate_xen_pvdevice = {
> +.name = "xen-pvdevice",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_PCI_DEVICE(parent_obj, XenPVDevice),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> static void xen_pv_realize(PCIDevice *pci_dev, Error **errp)
> {
> XenPVDevice *d = XEN_PV_DEVICE(pci_dev);
> @@ -120,6 +130,7 @@ static void xen_pv_class_init(ObjectClass *klass, void
> *data)
> k->class_id = PCI_CLASS_SYSTEM_OTHER;
> dc->desc = "Xen PV Device";
> dc->props = xen_pv_props;
> +dc->vmsd = &vmstate_xen_pvdevice;
> }
>
> static const TypeInfo xen_pv_type_info = {
> --
> 2.7.4
>
Re: [Qemu-devel] [PATCH 03/11] xen: defer call to xen_restrict until just before os_setup_post
On Fri, 9 Mar 2018, Eduardo Habkost wrote:
> On Fri, Mar 09, 2018 at 12:07:21PM +, Ian Jackson wrote:
> > Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict
> > until just before os_setup_post"):
> > > Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to
> > > xen_restrict until just before os_setup_post"):
> > > > I don't think we should have accelerator-specific code in main(),
> > > > if we already have accelerator classes that can abstract that
> > > > out. I suggest adding a AccelClass;:setup_post() method that can
> > > > be called here.
> > >
> > > I think I can do that.
> >
> > How about this ?
> >
> > From 61f11221afaa29e10021599420238e03836ba413 Mon Sep 17 00:00:00 2001
> > From: Ian Jackson
> > Date: Fri, 9 Mar 2018 12:02:50 +
> > Subject: [PATCH v6.2 12/11] AccelClass: Introduce accel_setup_post
> >
> > This is called just before os_setup_post. Currently none of the
> > accelerators provide this hook, but the Xen one is going to provide
> > one in a moment.
> >
> > Signed-off-by: Ian Jackson
>
> Looks good to me.
>
> Reviewed-by: Eduardo Habkost
>
> That said, I don't think this should block the inclusion of the
> previous patch in 2.12, if the Xen maintainers were already going
> to merge it.
Ian,
The Xen side is almost entirely reviewed and should be OK, but you need
reviewed-bys on some non-Xen specific patches: #7 #8 #11.
Cheers,
Stefano
Re: [Qemu-devel] [PATCH 4/4] hw/pci: remove obsolete PCIDevice->init()
On Sun, Mar 11, 2018 at 04:46:52PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Michael, Paolo.
>
> Now than all other PCI QOM'ification patches got applied, can you take
> this patch for 2.12?
>
> Thanks,
>
> Phil.
>
> On 12/17/2017 09:49 PM, Philippe Mathieu-Daudé wrote:
> > All PCI devices are now QOM'ified.
> >
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > include/hw/pci/pci.h | 1 -
> > hw/pci/pci.c | 14 --
> > 2 files changed, 15 deletions(-)
> >
> > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > index 8d02a0a383..0f1ed64c2f 100644
> > --- a/include/hw/pci/pci.h
> > +++ b/include/hw/pci/pci.h
> > @@ -217,7 +217,6 @@ typedef struct PCIDeviceClass {
> > DeviceClass parent_class;
> >
> > void (*realize)(PCIDevice *dev, Error **errp);
> > -int (*init)(PCIDevice *dev);/* TODO convert to realize() and remove */
> > PCIUnregisterFunc *exit;
> > PCIConfigReadFunc *config_read;
> > PCIConfigWriteFunc *config_write;
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index b2d139bd9a..cd25ab6f6b 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -2054,18 +2054,6 @@ static void pci_qdev_realize(DeviceState *qdev,
> > Error **errp)
> > }
> > }
> >
> > -static void pci_default_realize(PCIDevice *dev, Error **errp)
> > -{
> > -PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
> > -
> > -if (pc->init) {
> > -if (pc->init(dev) < 0) {
> > -error_setg(errp, "Device initialization failed");
> > -return;
> > -}
> > -}
> > -}
> > -
> > PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool
> > multifunction,
> > const char *name)
> > {
> > @@ -2538,13 +2526,11 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
> > static void pci_device_class_init(ObjectClass *klass, void *data)
> > {
> > DeviceClass *k = DEVICE_CLASS(klass);
> > -PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
> >
> > k->realize = pci_qdev_realize;
> > k->unrealize = pci_qdev_unrealize;
> > k->bus_type = TYPE_PCI_BUS;
> > k->props = pci_props;
> > -pc->realize = pci_default_realize;
How about we assert !init here?
+ assert(!pc->init);
> > }
> >
> > static void pci_device_class_base_init(ObjectClass *klass, void *data)
> >
Re: [Qemu-devel] [PATCH 4/4] hw/pci: remove obsolete PCIDevice->init()
On Mon, Mar 12, 2018 at 02:03:17AM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 11, 2018 at 04:46:52PM +0100, Philippe Mathieu-Daudé wrote:
> > Hi Michael, Paolo.
> >
> > Now than all other PCI QOM'ification patches got applied, can you take
> > this patch for 2.12?
> >
> > Thanks,
> >
> > Phil.
> >
> > On 12/17/2017 09:49 PM, Philippe Mathieu-Daudé wrote:
> > > All PCI devices are now QOM'ified.
> > >
> > > Signed-off-by: Philippe Mathieu-Daudé
> > > ---
> > > include/hw/pci/pci.h | 1 -
> > > hw/pci/pci.c | 14 --
> > > 2 files changed, 15 deletions(-)
> > >
> > > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > > index 8d02a0a383..0f1ed64c2f 100644
> > > --- a/include/hw/pci/pci.h
> > > +++ b/include/hw/pci/pci.h
> > > @@ -217,7 +217,6 @@ typedef struct PCIDeviceClass {
> > > DeviceClass parent_class;
> > >
> > > void (*realize)(PCIDevice *dev, Error **errp);
> > > -int (*init)(PCIDevice *dev);/* TODO convert to realize() and remove
> > > */
> > > PCIUnregisterFunc *exit;
> > > PCIConfigReadFunc *config_read;
> > > PCIConfigWriteFunc *config_write;
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index b2d139bd9a..cd25ab6f6b 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -2054,18 +2054,6 @@ static void pci_qdev_realize(DeviceState *qdev,
> > > Error **errp)
> > > }
> > > }
> > >
> > > -static void pci_default_realize(PCIDevice *dev, Error **errp)
> > > -{
> > > -PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
> > > -
> > > -if (pc->init) {
> > > -if (pc->init(dev) < 0) {
> > > -error_setg(errp, "Device initialization failed");
> > > -return;
> > > -}
> > > -}
> > > -}
> > > -
> > > PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool
> > > multifunction,
> > > const char *name)
> > > {
> > > @@ -2538,13 +2526,11 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
> > > static void pci_device_class_init(ObjectClass *klass, void *data)
> > > {
> > > DeviceClass *k = DEVICE_CLASS(klass);
> > > -PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
> > >
> > > k->realize = pci_qdev_realize;
> > > k->unrealize = pci_qdev_unrealize;
> > > k->bus_type = TYPE_PCI_BUS;
> > > k->props = pci_props;
> > > -pc->realize = pci_default_realize;
>
> How about we assert !init here?
>
> + assert(!pc->init);
Oh sorry I missed the chunk that drops it completely.
Will apply.
> > > }
> > >
> > > static void pci_device_class_base_init(ObjectClass *klass, void *data)
> > >
>
>
[Qemu-devel] [Bug 1754542] Re: colo: vm crash with segmentation fault
** Description changed:
I use Arch Linux x86_64
- Zhang
Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
+ Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
Secondary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
file.backing.backing=colo-disk0 \
-incoming tcp:0:
Secondary:
{'execute':'qmp_capabilities'}
{ 'execute': 'nbd-server-start',
- 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33',
'port': '8889'} } }
+ 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.34',
'port': '8889'} } }
}
{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0',
'writable': true } }
Primary:
{'execute':'qmp_capabilities'}
{ 'execute': 'human-monitor-command',
'arguments': {'command-line': 'drive_add -n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}}
{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node':
'nbd_client0' } }
{ 'execute': 'migrate-set-capabilities',
'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true
} ] } }
{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:' } }
- { 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay':
2000 } }
+
And two VM with cash
Primary:
{"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event":
"RESUME"}
[1]329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
Secondary:
{"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event":
"RESUME"}
[1]367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
-
-
-
- -
- if use qemu 2.11.1
- The sync will success,but when Secondary VM execute
x-colo-lost-heartbeat,Secondary VM will crash
- Secondary:
- { 'execute': 'nbd-server-stop' }
- { 'execute': 'x-colo-lost-heartbeat' }{"return": {}}
- qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before
all bytes were read
-
- {"return": {}}
- qemu-system-x86_64: Can't receive COLO message: Input/output error
- **
- ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion
failed (obj->ref > 0): (0 > 0)
- [1]1276 abort sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm
-m 2048 -smp 2 -qmp stdi
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754542
Title:
colo: vm crash with segmentation fault
Status in QEMU:
New
Bug description:
I use Arch Linux x86_64
Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
Secondary:
sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
fi
[Qemu-devel] [Bug 1754542] Re: colo: vm crash with segmentation fault
** Description changed:
I use Arch Linux x86_64
Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
- sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
+ sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
- -drive
if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw
-S
+ -drive
if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
+ children.0.file.filename=/var/lib/libvirt/images/1.raw,\
+ children.0.driver=raw -S
Secondary:
- sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name
secondary \
+ sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio
-name secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
- -drive
if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
+ -drive
if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=/mnt/ramfs/active_disk.img,\
file.backing.driver=qcow2,\
file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
- file.backing.backing=colo-disk0 \
+ file.backing.backing=secondary-disk0 \
-incoming tcp:0:
Secondary:
{'execute':'qmp_capabilities'}
{ 'execute': 'nbd-server-start',
- 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.34',
'port': '8889'} } }
+ 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.34',
'port': '8889'} } }
}
- {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0',
'writable': true } }
+ {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0',
'writable': true } }
Primary:
{'execute':'qmp_capabilities'}
{ 'execute': 'human-monitor-command',
- 'arguments': {'command-line': 'drive_add -n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}}
- { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node':
'nbd_client0' } }
+ 'arguments': {'command-line': 'drive_add -n buddy
driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}}
+ { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0',
'node': 'nbd_client0' } }
{ 'execute': 'migrate-set-capabilities',
- 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true
} ] } }
+ 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true
} ] } }
{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:' } }
-
-
And two VM with cash
Primary:
{"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event":
"RESUME"}
[1]329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
Secondary:
{"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event":
"RESUME"}
[1]367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c
-enable-kvm -m 2048 -smp 2 -qm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754542
Title:
colo: vm crash with segmentation fault
Status in QEMU:
New
Bug description:
I use Arch Linux x86_64
Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10)
Following document 'COLO-FT.txt',
I test colo feature on my hosts
I run this command
Primary:
sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio
-name primary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
children.0.file.filename=/var/lib/libvirt/images/1.raw,\
children.0.driver=raw -S
Secondary:
sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio
-name secondary \
-device piix3-usb-uhci \
-device usb-tablet -netdev tap,id=hn0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=hn0 \
-drive
if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0
\
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.fil
[Qemu-devel] [Bug 1729501] Re: qemu crashes with assertion error `off_cur_end >= off_cur' failed
The issue has been fixed: http://lists.nongnu.org/archive/html/qemu- devel/2018-03/msg02174.html ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1729501 Title: qemu crashes with assertion error `off_cur_end >= off_cur' failed Status in QEMU: Fix Committed Bug description: My host environment: Xen + QEMU git clones today's xen git and qemu git (2017-11-02) xen -- git://xenbits.xen.org/xen.git commit 24fb44e971a62b345c7b6ca3c03b454a1e150abe qemu -- https://github.com/qemu/qemu commit 47ba789c97c8d201d01058b00a14d8a9a85fcfe9 QEMU was compiled using: ./configure --prefix=/mnt/bin/ --enable-xen --target-list=i386-softmmu --extra-cflags="-I/mnt/xen/tools/include -I/mnt/xen/tools/libxc -I/mnt/xen/tools/xenstore"--extra-ldflags="-L/mnt/xen/tools/libxc -L/mnt/xen/tools/xenstore" --enable-debug --enable-debug-stack-usage Xen was configured with the above QEMU distribution: ./configure --with-system-qemu=/mnt/bin/bin/qemu-system-i386 QEMU command line: /mnt/bin/bin/qemu-system-i386 -xen-domid 28 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-28,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-28,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name ubu_hvm -vnc 0.0.0.0:1,to=99 -display none -serial pty -device cirrus-vga,vgamem_mb=8 -boot order=c -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:74:34:32 -netdev type=tap,id=net0,ifname=vif28.0-emu,script=no,downscript=no -device rtl8139,id=nic1,netdev=net1,mac=00:16:3e:5f:48:e4 -netdev type=tap,id=net1,ifname=vif28.1-emu,script=no,downscript=no -machine xenfv -m 1504 -drive file=/mnt/10G.hdd,if=ide,index=0,media=disk,format=raw,cache=writeback Produce: I run a fuzzer program in guest vm, it may set incorrect values for graphics registers, sequencer registers and other registers. Seeing the following error from /var/log/xen/qemu-dm-.log: qemu-system-i386: hw/display/cirrus_vga.c:712: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. I can reproduce it at anytime, if you need to gather more diagnostic information or try test patches, I'm happy to help. gdb bt: #0 0x7f81a64f8c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7f81a64fc028 in __GI_abort () at abort.c:89 #2 0x7f81a64f1bf6 in __assert_fail_base (fmt=0x7f81a6646018 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=file@entry=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=line@entry=712, function=function@entry=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:92 #3 0x7f81a64f1ca2 in __GI___assert_fail (assertion=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=712, function=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:101 #4 0x55d70cb66445 in cirrus_invalidate_region (s=0x55d70ee3a4b0, off_begin=4190568, off_pitch=1842, bytesperline=5056, lines=2922) at hw/display/cirrus_vga.c:712 #5 0x55d70cb6660c in cirrus_bitblt_common_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:752 #6 0x55d70cb6676d in cirrus_bitblt_videotovideo_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:786 #7 0x55d70cb670c5 in cirrus_bitblt_videotovideo (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:986 #8 0x55d70cb678bf in cirrus_bitblt_start (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:1136 #9 0x55d70cb6880b in cirrus_vga_write_gr (s=0x55d70ee3a4b0, reg_index=42, reg_value=228) at hw/display/cirrus_vga.c:1652 #10 0x55d70cb6ab86 in cirrus_vga_ioport_write (opaque=0x55d70ee3a4b0, addr=975, val=228, size=1) at hw/display/cirrus_vga.c:2754 #11 0x55d70c91d9c0 in memory_region_write_accessor (mr=0x55d70ee4af70, addr=31, value=0x7fffdaaeaf38, size=1, shift=8, mask=255, attrs=...) at /mnt/qemu/memory.c:560 #12 0x55d70c91dc3a in access_with_adjusted_size (addr=30, value=0x7fffdaaeaf38, size=2, access_size_min=1, access_size_max=1, access_fn=0x55d70c91d8c9 , mr=0x55d70ee4af70, attrs=...) at /mnt/qemu/memory.c:627 #13 0x55d70c920f48 in memory_region_dispatch_write (mr=0x55d70ee4af70, addr=30, data=58410, size=2, attrs=...) at /mnt/qemu/memory.c:1503 #14 0x55d70c8c51e0 in flatview_write_continue (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4, addr1=30, l=2, mr=0x55d70ee4af70) at /mnt/qemu/exec.c:2951 #15 0x55d70c8c5390 in flatview_write (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4) at /
[Qemu-devel] [Bug 1703506] Re: SMT not supported by QEMU on AMD Ryzen CPU
I tried the above patches on a TR 1900X and they do not help to enable SMT. I still receive the warning. Also, with the patches applied, the CPU now identifies as EPYC in the guest. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703506 Title: SMT not supported by QEMU on AMD Ryzen CPU Status in QEMU: New Bug description: HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703506/+subscriptions
Re: [Qemu-devel] [PATCH v8 01/23] docs: update QMP documents for OOB commands
On Fri, Mar 09, 2018 at 11:13:23AM -0600, Eric Blake wrote:
> On 03/09/2018 02:59 AM, Peter Xu wrote:
> > Update both the developer and spec for the new QMP OOB (Out-Of-Band)
> > command.
> >
> > Signed-off-by: Peter Xu
> > ---
> > docs/devel/qapi-code-gen.txt | 65
> >
> > docs/interop/qmp-spec.txt| 30 +---
> > 2 files changed, 86 insertions(+), 9 deletions(-)
>
> If all goes well, I'm planning on taking this series through my QAPI tree,
> with a pull request either late today or early Monday in order to make the
> soft freeze deadline. We'll see what my review turns up, but hopefully at
> this point it's either clean or minor enough tweaks that I can polish it
> without a v9.
That'll be great. Thanks Eric!
[...]
> > @@ -102,10 +113,16 @@ The format for command execution is:
> > required. Each command documents what contents will be considered
> > valid when handling the json-argument
> > - The "id" member is a transaction identification associated with the
> > - command execution, it is optional and will be part of the response if
> > + command execution. It is required if OOB is enabled, and optional
> > + if not. The same "id" field will be part of the response if
>
> Ambiguous on whether this is the per-command 'run-oob', or whether this is
> the generic QMP capability requested during qmp_capabilities. I think the
> intent is that if you enabled the QMP capability up front, ALL commands must
> have an "id", even if they are run in-band without 'run-oob', because the
> 'id' in the response is what will distinguish whether a later OOB request
> overtook a pending in-band reply.
Yes, maybe I should use "OOB capability" to be explicit - exactly as
you explained.
>
> > provided. The "id" member can be any json-value, although most
> > clients merely use a json-number incremented for each successive
> > command
> > +- The "control" member is optional, and currently only used for
> > + "out-of-band" execution ("oob" as shortcut). The handling or
>
> A bit late to be introducing "oob" as shortcut, given that you've already
> used the abbreviation oob earlier in the document.
>
> > + response of an "oob" command can overtake prior in-band commands.
> > + To enable "oob" handling of a particular command, just provide a
> > + control field with: { "control": { "run-oob": true } }
> > 2.4 Commands Responses
> > --
> > @@ -113,6 +130,11 @@ The format for command execution is:
> > There are two possible responses which the Server will issue as the result
> > of a command execution: success or error.
> > +As long as the commands were issued with a proper "id" field, then the
> > +same "id" field will be attached in the corresponding response message
> > +so that requests and responses can match. Clients should drop all the
> > +responses that are with unknown "id" field.
>
> s/are with/have an/
>
> I've got quite a few wording tweaks, but the general concept is good. If you
> need to respin for other reasons, feel free to make those improvements, but
> I also don't mind making tweaks myself as part of queuing for a pull
> request, so:
>
> Reviewed-by: Eric Blake
(I agree on all the rest of the review comments too)
Thanks!
--
Peter Xu
Re: [Qemu-devel] [PATCH v8 17/23] qapi: introduce new cmd option "allow-oob"
On Sat, Mar 10, 2018 at 08:27:22PM -0600, Eric Blake wrote:
[...]
> I'm a bit disappointed that tests/qapi-schema/qapi-schema-test.json doesn't
> have any "allow-oob":true commands at any point in the series. I consider
> that to be a bug, so it can be fixed by followup patch even after soft
> freeze; but won't make the lack of good testing hold up this series from
> making the release.
Sorry, obviously I missed that one.
If this series will reach master soon, I'll post separate patch for
that before release as bugfix.
If this series can't make it due to any reason, I'll append a patch to
the series when repost.
>
> > +++ b/scripts/qapi/introspect.py
> > @@ -29,6 +29,11 @@ def to_json(obj, level=0):
> > to_json(obj[key], level + 1))
> > for key in sorted(obj.keys())]
> > ret = '{' + ', '.join(elts) + '}'
> > +elif isinstance(obj, bool):
> > +if obj:
> > +ret = 'true'
> > +else:
> > +ret = 'false'
>
> Conflicts with Marc-Andre's work to perform introspection by QLIT_*; but
> it's easy enough to adjust:
>
> +elif isinstance(obj, bool):
> +ret += 'QLIT_QBOOL(%s)' % ('true' if obj else 'false')
>
> Reviewed-by: Eric Blake
Thanks,
--
Peter Xu
Re: [Qemu-devel] [PATCH v8 22/23] tests: qmp-test: verify command batching
On Sat, Mar 10, 2018 at 08:45:46PM -0600, Eric Blake wrote:
> On 03/09/2018 03:00 AM, Peter Xu wrote:
> > OOB introduced DROP event for flow control. This should not affect old
> > QMP clients. Add a command batching check to make sure of it.
> >
> > Reviewed-by: Stefan Hajnoczi
> > Signed-off-by: Peter Xu
> > ---
> > tests/qmp-test.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
>
> > +/*
> > + * Test command batching. In current test OOB is not enabled, we
> > + * should be able to run as many commands in batch as we like.
> > + * Using 16 (>8, which is OOB queue length) to make sure OOB won't
> > + * break existing clients. Note: this test does not control the
> > + * scheduling of QEMU's QMP command processing threads so it may
> > + * not really trigger batching inside QEMU. This is just a
> > + * best-effort test.
> > + */
> > +for (i = 0; i < 16; i++) {
> > +qtest_async_qmp(qts, "{ 'execute': 'query-version' }");
>
> Would the test be any more robust if we could generate a single string to
> send all at once, rather than multiple separate calls to qtest_async_qmp()
> (the overhead in generating separate strings means the monitor may have made
> progress before we send the next string). But that can be a followup, if
> you want to pursue the idea.
Yes, a single string would be nicer.
As the comment said (which was actually pointed out by Stefan), the
test is only a best effort test considering that we cannot really
control how the QEMU QMP internal handles the requests. E.g., even if
we send the strings in one write() call, it's still only buffered on
the receiver's side only, and it'll be QEMU who decide how to fetch
the buffer content.
I can fix this up if there is a new post, or do it separately
otherwise along with the other suggestion below.
>
> > +}
> > +/* Verify the replies to make sure no command is dropped. */
> > +for (i = 0; i < 16; i++) {
> > +resp = qtest_qmp_receive(qts);
> > +/* It should never be dropped. Each of them should be a reply. */
> > +g_assert(qdict_haskey(resp, "return"));
> > +g_assert(!qdict_haskey(resp, "event"));
> > +QDECREF(resp);
>
> Should we also be sending unique ids, and ensure that the responses arrive
> with ids in the same order? Again, idea for a followup.
Yes, it can be better. Will apply the same idea as above, depending
on the fate of current series.
>
> Reviewed-by: Eric Blake
Thanks!
--
Peter Xu
Re: [Qemu-devel] [PATCH v8 23/23] tests: qmp-test: add oob test
On Sat, Mar 10, 2018 at 08:49:42PM -0600, Eric Blake wrote:
> On 03/09/2018 03:00 AM, Peter Xu wrote:
> > Test the new OOB capability. Here we used the new "x-oob-test" command.
> > Firstly, we send a lock=true and oob=false command to hang the main
>
> s/Firstly/First/
>
> > thread. Then send another lock=false and oob=true command (which will
> > be run inside parser this time) to free that hanged command.
> >
> > Reviewed-by: Stefan Hajnoczi
> > Signed-off-by: Peter Xu
> > ---
> > tests/qmp-test.c | 65
> >
> > 1 file changed, 65 insertions(+)
> >
>
> > +/* Now, enable OOB in current QMP session, it should success. */
>
> s/success/succeed/
>
> > +
> > +/*
> > + * Firstly send the "x-oob-test" command with lock=true and
>
> s/Firstly/First/
>
> > + * oob=false, it should hang the dispatcher and main thread;
> > + * later, we send another lock=false with oob=true to continue
> > + * that thread processing. Finally we should receive replies from
> > + * both commands.
> > + */
> > +qmp_async("{ 'execute': 'x-oob-test',"
> > + " 'arguments': { 'lock': true }, "
> > + " 'id': 'lock-cmd'}");
> > +qmp_async("{ 'execute': 'x-oob-test', "
> > + " 'arguments': { 'lock': false }, "
> > + " 'control': { 'run-oob': true }, "
> > + " 'id': 'unlock-cmd' }");
> > +
> > +/* Ignore all events. Wait for 2 acks */
> > +while (acks < 2) {
> > +resp = qmp_receive();
> > +cmd_id = qdict_get_str(resp, "id");
> > +if (!g_strcmp0(cmd_id, "lock-cmd") ||
> > +!g_strcmp0(cmd_id, "unlock-cmd")) {
> > +acks++;
> > +}
> > +QDECREF(resp);
> > +}
>
> Can you make the reply order deterministic? Perhaps by having the lock
> command insert a sleep after locking but before replying, so that the unlock
> always gets to reply first? But that can be a followup.
Yes, I could. I'm just afraid that sleep might be undeterministic too
in some extreme cases, since IMHO it'll still depend on other things
(e.g., the scheduler of host, resources/workload on the host, etc.) to
make sure the order of the two commands will be exactly what we want.
So, even if current test seems to be undetermistic on the order of
received responses, IMHO it's very good on the other hand that it is
very determinstic on the test result...
>
> Reviewed-by: Eric Blake
Thanks,
--
Peter Xu
Re: [Qemu-devel] [PATCH v8 00/23] QMP: out-of-band (OOB) execution support
On Sat, Mar 10, 2018 at 08:59:38PM -0600, Eric Blake wrote: > On 03/09/2018 02:59 AM, Peter Xu wrote: > > Based-on: <20180306053320.15401-1-pet...@redhat.com> > > > > The series is based on the following series: > > > >[PATCH v2 0/9] chardev: qio related non-default context support > >(actually patch 9 is based on version 2.1, Dan's version) [1] > > > > This version only contains some trivial changes, most of the work is > > posted separately in either the QIO or CHARDEV series. > > > > Four days until soft freeze. Hmm... > > > > Please review. Thanks, > > > > v8: > > - fix up doc patch as suggested [Eric] > > - rename functions in form of X_get_Y() or X_bh() [Stefan] > > - English fixes [Stefan] > > - make sure to kick iothread after suspend count update [Stefan] > > - remove the hack to remove fd in monitor_init(), since now we have > >the QIO/CHARDEV series to solve the root problem. > > Still a lot that I had to clean up (in part due to conflicts with other > pending patches that also touch qapi), but given the utility of this > feature, and the impending deadline for freeze, I've gone ahead and done the > cleanup work. Your patches are now stages on my QAPI tree. > > git://repo.or.cz/qemu/ericb.git qapi > http://repo.or.cz/qemu/ericb.git/shortlog/refs/heads/qapi > > Note that I had some ideas for followup patches (mainly strengthening the > testsuite, which is typically safe early on in freeze because it is not > introducing features but strengthening the quality of the release). I really appreciate very much on your work and time on the series. I've noted down all the review comments, including the test enhancements (which I'll do in a proper way soon). I'll avoid replying to every review comments since all of them are sane. Note that this series will depend on the chardev fixes ([1] above) in Paolo's tree. They'll possibly not be needed for compilation, but might be needed for further tests. Hope that won't be a big problem. Thanks again! -- Peter Xu
[Qemu-devel] [Bug 1173490] Re: virtio net adapter driver with kvm slow on winxp
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1173490 Title: virtio net adapter driver with kvm slow on winxp Status in QEMU: Expired Bug description: # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 12.04.1 LTS Release:12.04 Codename: precise #virsh version Compiled against library: libvirt 1.0.4 Using library: libvirt 1.0.4 Using API: QEMU 1.0.4 Running hypervisor: QEMU 1.2.0 windows xp clean install with spice-guest-tools-0.52.exe from http://spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.52.exe it comes very slow , and the Interrupts process got very high cpu usage(above 60%). when i switch the net adapter from virtio to default(rtl8139) ,it works well. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1173490/+subscriptions
[Qemu-devel] [Bug 1129957] Re: Performance issue running quest image on qemu compiled for Win32 platform
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1129957 Title: Performance issue running quest image on qemu compiled for Win32 platform Status in QEMU: Expired Bug description: I'm seeing performance issues when booting a guest image on qemu 1.4.0 compiled for the Win32 platform. The same image boots a lot faster on the same computer running qemu/linux on Fedora via VmWare, and even running the Win32 exectuable via Wine performs better than running qemu natively on Win32. Although I'm not the author of the image, it is located here: http://people.freebsd.org/~wpaul/qemu/vxworks.img All testing has been done on QEMU 1.4.0. I'm also attaching a couple of gprof logs. For these I have disabled ssp in qemu by removing "-fstack-protector-all" and "-D_FORTIFY_SOURCE=2" from the qemu configure script. qemu-perf-linux.txt Machine - Windows XP - VmWare - Fedora - QEMU qemu-perf-win32.txt = Machine - Windows XP - QEMU qemu-perf-wine.txt Machine - Windows XP - VmWare - Fedora - Wine - QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1129957/+subscriptions
[Qemu-devel] [Bug 1122492] Re: qemu and grub2 rescue floppy don't get along
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1122492 Title: qemu and grub2 rescue floppy don't get along Status in QEMU: Expired Bug description: With qemu.git as of Feb 11 2013: # grub2-mkrescue -o test.img # ./x86_64-softmmu/qemu-system-x86_64 -fda test.img -curses SeaBIOS (version ?-20130206_051134-ccnode4) iPXE v1.0.0-591-g7aee315 iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+07FC7EC0+07F87EC0 C900 Booting from Hard Disk... Boot failed: could not read the boot disk Booting from Floppy... GRUB loading Welcome to GRUB! error: attempt to read or write outside of disk `fd0'. Entering rescue mode... grub rescue> Expected results: grub header and a normal usable grub prompt like 'grub>' This was originally reported against qemu 0.15 in Fedora 16 at: https://bugzilla.redhat.com/show_bug.cgi?id=784537 Some more info from that bug: 0) The images that grub2-mkrescue creates are odd mixtures of ISO images and disk images: file -r -k test.img test.img: # ISO 9660 CD-ROM filesystem data 'ISOIMAGE ' (bootable) - x86 boot sector; partition 1: ID=0xcd, active, starthead 0, startsector 1, 4455 sectors, code offset 0x63 DOS executable (COM), boot code 1) The test image I use has a 2281472 byte size. If I append that with zeroes to 2880 KB (2949120 bytes) then I get the expected results. So there's a workaround. But I don't think it's an obvious workaround. 2) It's debatable whether this is a bug. If it's considered a bug, I'm not sure whether qemu and/or grub2 is to blame. Should qemu (silently) handle (floppy) disk image between 1440 KB and 2880 KB as if they actually were 2880 KB in size? Or should grub2, if possible, zero pad the images it creates to (in this case) a 2880 KB size? 3) Please note that there seems to be little one can do to leave "grub rescue" mode. Ie, "insmod normal" will fail too: grub rescue> insmod normal error: attempt to read or write outside of disk `fd0'. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1122492/+subscriptions
[Qemu-devel] [Bug 1055090] Re: esp error: NetBSD/sparc on qemu-system-sparc
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1055090 Title: esp error: NetBSD/sparc on qemu-system-sparc Status in QEMU: Expired Bug description: On qemu-1.2.0's qemu-system-sparc, NetBSD/sparc (32bit) 5.1.2 and 6.0_RC2 generates the following NetBSD's errors. esp0: !TC on DATA XFER [intr 18, stat 82, step 4] prevphase 2, resid 0 esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0 On qemu-0.15.1's qemu-system-sparc, NetBSD/sparc 5.1.2 and 6.0_RC2 works fine. To reproduce with NetBSD/sparc 6.0_RC2, run % qemu-system-sparc -M SS-20 -m 265M -hda NetBSD-sparc-6.0_RC2.qed -nographic -cdrom NetBSD-6.0_RC2-sparc.iso -boot d and try to install NetBSD. You can get above errors when newfs command is invoked. I can reporduce this problem on NetBSD/i386 (32bit) and NetBSD/amd64(64bit; x86_64) host OSes. NetBSD-6.0_RC2-sparc.iso is here, ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0_RC2/images/NetBSD-6.0_RC2-sparc.iso NetBSD-sparc-6.0_RC2.qed is created with % qemu-img create -f qed NetBSD-sparc-6.0_RC2.qed 3G To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1055090/+subscriptions
[Qemu-devel] [Bug 1086745] Re: serial port data THRE comes too early
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1086745 Title: serial port data THRE comes too early Status in QEMU: Expired Bug description: When using a serial port with a Linux guest (and host) and the application uses hardware handshake, this fails because the handling of TEMT and/or THRE is not operating properly in such cases. As long as it takes _time_ for the 'real' port to output the data TEMT may not return true. After writing characters to a real port, the driver should timeout the transmission and after the total time expired, TEMT can be set. Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat IOCTL(GET_LSR_INFO), RTS_off, READ_data. At the moment this fails because very early in the transmission, GET_LSR_INFO returns true and the modem transmitter is switched off. I looked in the source (git) and found that 'char_transmit_time' is present. My skills fail to implement it myself. I build and ran the latest git version and found it to fail as decribed above. I hope someone can solve it. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions
[Qemu-devel] [Bug 1175089] Re: Crash why dragon fly 3.4.1
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1175089 Title: Crash why dragon fly 3.4.1 Status in QEMU: Expired Bug description: Hello, all is here (kernel 3.8, qemu 1.2.2-r3): /usr/bin/qemu-system-x86_64 -k fr -alt-grab -m 2048 -vga vmware -net nic,vlan=0,model=virtio -net user -rtc base=localtime -smp 4,cores=4,sockets=1 -boot once=d -cdrom dfly-x86_64-gui-3.4.1_REL.iso KVM internal error. Suberror: 1 emulation failure EAX=0010 EBX=9338 ECX= EDX= ESI=17fc EDI=17c8 EBP=000364a0 ESP=17b8 EIP=9318 EFL=3002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 CS =0018 9b00 SS =0010 00c09300 DS =0010 00c09300 FS =0033 a000 00c0f300 GS =0033 a000 00c0f300 LDT= 8200 TR =0038 5f98 2067 8b00 GDT= 9590 003f IDT= 5e00 0197 CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 a3 ea 5d 00 00 66 ea 10 93 18 00 0f 20 c0 fe c8 0f 22 c0 1d 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1175089/+subscriptions
[Qemu-devel] [Bug 1090726] Re: qemu does not generate guest cpu topology properly
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1090726 Title: qemu does not generate guest cpu topology properly Status in QEMU: Expired Bug description: Adding the option -smp 12,sockets=2,cores=6,threads=1 exposes Machine (12GB) Socket #0 L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0) L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1) L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2) L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3) L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4) L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5) L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6) L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7) Socket #1 L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8) L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9) L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10) L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11) Rather than: Machine (12GB) Socket #0 L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0) L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1) L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2) L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3) L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4) L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5) Socket #1 L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6) L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7) L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8) L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9) L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10) L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11) Here is a cpuid dump from inside the guest and dump from more recent version of cpuid, in which you can see a bit more detail. The later contains data for a single CPU, because the others are the same. Reproducible on qemu 1.0 and 1.2. with guest os Fedora 17, Debian 6, Debian Squeeze and Windows 2008 R2. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1090726/+subscriptions
Re: [Qemu-devel] [PATCH v7 00/23] Migration: postcopy failure recovery
On Fri, Mar 09, 2018 at 10:59:03AM -0600, Eric Blake wrote: > On 03/09/2018 10:54 AM, Eric Blake wrote: > > On 03/09/2018 03:15 AM, Peter Xu wrote: > > > Based-on: <20180309090006.10018-1-pet...@redhat.com> > > > > > > This series is based on the series: > > > > > > [PATCH v8 00/23] QMP: out-of-band (OOB) execution support > > > > Let's spell that in a way patchew understands: > > > > Based-on: <20180309090006.10018-1-pet...@redhat.com> > > > > Never mind - I missed that you snuck that in on the very first line (which > I'm used to overlooking because it's often a 'From:' author attribution, > instead of a patchew directive). I saw the patchew failure messages, but > didn't read them closely to see why it is failing, and merely assumed it was > because of the missing dependency... Yeh, but there still seems to be something wrong elsewhere since the series can pass compilation and docker tests on my host... Fam, what would happen if I firstly post OOB series, then postcopy series (which will have "based-on" on OOB series) right away? Could Patchew just ignore the "based-on" if I post the 2nd series too fast since Patchew may have not yet went through the first one? Thanks, -- Peter Xu
Re: [Qemu-devel] [edk2] [PATCH v2 0/8] RFC: ovmf: preliminary TPM2 support
It works in my side after specify the full path to swtpm tpmemu.sock in qemu command options. Thanks! Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 > -Original Message- > From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com] > Sent: Friday, March 9, 2018 9:54 PM > To: Shi, Steven ; Marc-André Lureau > > Cc: edk2-de...@lists.01.org; ler...@redhat.com; pjo...@redhat.com; Yao, > Jiewen ; qemu-devel@nongnu.org; > javi...@redhat.com > Subject: Re: [edk2] [PATCH v2 0/8] RFC: ovmf: preliminary TPM2 support > > On 03/08/2018 10:03 PM, Shi, Steven wrote: > > Hi Marcandre, > > Thanks for your command steps and I tried them, but my qemu failed to > connect the socket tpmemu.sock. When I added the control channel to the > TPM, the swtpm socket command stuck there and never exit. Not sure > whether it was successful. > > Below are the command steps running output in my side > > > >> Then you can run: > >> mkdir tpmstatedir > >> swtpm_setup.sh --tpm2 --tpm-state tpmstatedir > > $ swtpm_setup.sh --tpm2 --tpm-state tpmstatedir > > Starting vTPM manufacturing as jshi19:jshi19 @ 2018年03月09日 星期 > 五 10时28分39秒 > > TPM is listening on TCP port 47364. > > Successfully authored TPM state. > > Ending vTPM manufacturing @ 2018年03月09日 星期五 10时28分39 > 秒 > > > >> Run the emulator: > >> swtpm socket --tpmstate dir=tpmstatedir --ctrl > type=unixio,path=tpmemu.sock --tpm2 > > $ swtpm socket --tpmstate dir=tpmstatedir --ctrl > type=unixio,path=tpmemu.sock --tpm2 > > (the swtpm socket command stuck there and never exit) > > > >> Run qemu (from git) with ovmf (with this series): > >> qemu ... -chardev socket,id=chrtpm,path=tpmemu.sock -tpmdev > >> emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0 > >> -drive if=pflash,format=raw,file=OVMF_CODE.fd,readonly -drive > >> if=pflash,format=raw,file=OVMF_VARS.fd .. > > $ qemu-system-x86_64 -serial file:serial.log -m 5120 -hda fat:. -monitor > stdio --enable-kvm -smp 4 -bios ../Ovmf3264/NOOPT_GCC5/FV/OVMF.fd - > chardev socket,id=chrtpm,path=tpmemu.sock -tpmdev > emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0 > > qemu-system-x86_64: -chardev socket,id=chrtpm,path=tpmemu.sock: > Failed to connect socket tpmemu.sock: No such file or directory > > Try giving it both, swtpm and qemu, the full path to the socket. > > > > > > I use the latest version qemu as below: > > $ qemu-system-x86_64 --version > > QEMU emulator version 2.11.50 (v2.10.0-4184-g930b01138b-dirty) > > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers > > > > Thanks > > Steven Shi > >
Re: [Qemu-devel] [PATCH] hw/i386: make IOMMUs configurable via default-configs/
On 28.02.2018 10:32, Paolo Bonzini wrote: > Allow distributions to disable the Intel and/or AMD IOMMU devices. > > Signed-off-by: Paolo Bonzini > --- > default-configs/i386-softmmu.mak | 2 ++ > default-configs/x86_64-softmmu.mak | 2 ++ > hw/i386/Makefile.objs | 5 +++-- > 3 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/default-configs/i386-softmmu.mak > b/default-configs/i386-softmmu.mak > index 3326e3e0bb..9e5a29fa4a 100644 > --- a/default-configs/i386-softmmu.mak > +++ b/default-configs/i386-softmmu.mak > @@ -63,3 +63,5 @@ CONFIG_PXB=y > CONFIG_ACPI_VMGENID=y > CONFIG_FW_CFG_DMA=y > CONFIG_I2C=y > +CONFIG_VTD=y > +CONFIG_AMD_IOMMU=y > diff --git a/default-configs/x86_64-softmmu.mak > b/default-configs/x86_64-softmmu.mak > index 1c6cda1d9a..7baf91b921 100644 > --- a/default-configs/x86_64-softmmu.mak > +++ b/default-configs/x86_64-softmmu.mak > @@ -63,3 +63,5 @@ CONFIG_PXB=y > CONFIG_ACPI_VMGENID=y > CONFIG_FW_CFG_DMA=y > CONFIG_I2C=y > +CONFIG_VTD=y > +CONFIG_AMD_IOMMU=y > diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs > index fd279e7584..528b8dc431 100644 > --- a/hw/i386/Makefile.objs > +++ b/hw/i386/Makefile.objs > @@ -2,8 +2,9 @@ obj-$(CONFIG_KVM) += kvm/ > obj-y += multiboot.o > obj-y += pc.o pc_piix.o pc_q35.o > obj-y += pc_sysfw.o > -obj-y += x86-iommu.o intel_iommu.o > -obj-y += amd_iommu.o > +obj-y += x86-iommu.o > +obj-$(CONFIG_VTD) += x86-iommu.o intel_iommu.o I think you have to remove x86-iommu.o in the above line, since it is included already one line earlier. With that modification: Reviewed-by: Thomas Huth
Re: [Qemu-devel] [PATCH V1]sm501: dead code removal
On 11.03.2018 17:40, Aishwarya Kadlag wrote:
> From: Aishwarya Kadlag
>
> Remove support for DEPTH != 32 values from hw/display/*_template.h
> files and other files that include them. Only DEPTH == 32 case is
> supported.
>
> Signed-off-by: Aishwarya Kadlag
> ---
> hw/display/sw501_1.c | 36
> hw/display/sw501_template_1.h |4 +++-
> 2 files changed, 3 insertions(+), 37 deletions(-)
>
>
> diff -u sm501.c sm501_1.c > sm501.patch -s
Patches should be applicable from the the top directory. It's best if
you create the patches with "git format-patch", see:
https://wiki.qemu.org/Contribute/SubmitAPatch#Use_git_format-patch
> --- sm501.c 2018-03-11 17:46:33.621452968 +0530
> +++ sm501_1.c 2018-03-11 17:53:26.933445566 +0530
> @@ -1358,22 +1358,6 @@
> int width, const uint8_t *palette,
> int c_x, int c_y);
>
> -#define DEPTH 8
> -#include "sm501_template.h"
> -
> -#define DEPTH 15
> -#include "sm501_template.h"
> -
> -#define BGR_FORMAT
> -#define DEPTH 15
> -#include "sm501_template.h"
> -
> -#define DEPTH 16
> -#include "sm501_template.h"
> -
> -#define BGR_FORMAT
> -#define DEPTH 16
> -#include "sm501_template.h"
>
> #define DEPTH 32
> #include "sm501_template.h"
> @@ -1383,43 +1367,23 @@
> #include "sm501_template.h"
>
> static draw_line_func *draw_line8_funcs[] = {
> -draw_line8_8,
> -draw_line8_15,
> -draw_line8_16,
> draw_line8_32,
> draw_line8_32bgr,
> -draw_line8_15bgr,
> -draw_line8_16bgr,
> };
>
> static draw_line_func *draw_line16_funcs[] = {
> -draw_line16_8,
> -draw_line16_15,
> -draw_line16_16,
> draw_line16_32,
> draw_line16_32bgr,
> -draw_line16_15bgr,
> -draw_line16_16bgr,
> };
>
> static draw_line_func *draw_line32_funcs[] = {
> -draw_line32_8,
> -draw_line32_15,
> -draw_line32_16,
> draw_line32_32,
> draw_line32_32bgr,
> -draw_line32_15bgr,
> -draw_line32_16bgr,
> };
>
> static draw_hwc_line_func *draw_hwc_line_funcs[] = {
> -draw_hwc_line_8,
> -draw_hwc_line_15,
> -draw_hwc_line_16,
> draw_hwc_line_32,
> draw_hwc_line_32bgr,
> -draw_hwc_line_15bgr,
> -draw_hwc_line_16bgr,
> };
>
> static inline int get_depth_index(DisplaySurface *surface)
>
>
>
> diff -u sm501_template.h sm501_template_1.h > sm501_template.patch -s
> --- sm501_template.h2018-03-11 17:25:36.816653718 +0530
> +++ sm501_template_1.h 2018-03-11 17:25:16.828654076 +0530
> @@ -22,13 +22,15 @@
> * THE SOFTWARE.
> */
>
> +/*
> #if DEPTH == 8
> #define BPP 1
> #define PIXEL_TYPE uint8_t
> #elif DEPTH == 15 || DEPTH == 16
> #define BPP 2
> #define PIXEL_TYPE uint16_t
> -#elif DEPTH == 32
> +*/
> +#if DEPTH == 32
> #define BPP 4
> #define PIXEL_TYPE uint32_t
> #else
>
I don't know the hw/display code very well, but I think it's not that
easy... Putting Gerd on CC:, maybe he can describe the details of that
BiteSizeTask a little bit better.
(When sending patches, please also always use the get_maintainers.pl
script to get a set of people who should be put on CC: or the patch
might get lost in the high traffic of the qemu-devel mailing list).
Thomas
[Qemu-devel] BiteSIzeTasks
Hi all,
it's great that we have https://wiki.qemu.org/BiteSizedTasks - but
apparently some tasks are apparently described a little bit too
scarcely. Many newcomers seem to have problems understanding the tasks
that are mentioned here. To improve the experience of people willing to
contribute to QEMU a little bit, may I ask everybody who put a task on
that page to have another look at it, and if a task is written without a
good description, please rephrase it a little bit?
I think it would be also good to have a contact person related to each
task. I've added my contact information ("THH" + description at the
bottom of the page) to the tasks that I put on the list. So I'd like to
ask everybody else who put a task on that list to put their contact
information next to their tasks, too.
Thanks,
Thomas
[Qemu-devel] [Bug 1753437] Re: qemu/pc-bios/s390-ccw/libc.c:82: bad test ?
Looks like the mailing list <-> launchpad bridge again ignored mails to the
corresponding mailing list thread. It's not a real bug, see here for details:
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg01142.html
I'll try to remember to clean this up the next time we update the s390-ccw bios.
** Changed in: qemu
Assignee: (unassigned) => Thomas Huth (th-huth)
** Changed in: qemu
Importance: Undecided => Low
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1753437
Title:
qemu/pc-bios/s390-ccw/libc.c:82: bad test ?
Status in QEMU:
Confirmed
Bug description:
qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx'
can't be negative so it is unnecessary to test it.
Source code is
while (num_idx >= 0) {
but
size_t num_idx = 1; /* account for NUL */
So there is no escape from the while loop.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1753437/+subscriptions
