[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
** Attachment added: source guest logs https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/+attachment/3725328/+files/source.log.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none' model='selinux'/ /domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
** Attachment added: Source Libvirtd logs https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/+attachment/3725330/+files/source_libvirtd.logs -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none' model='selinux'/ /domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
** Attachment added: Destination Libvirtd logs https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/+attachment/3725331/+files/destination_libvirtd.logs -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none' model='selinux'/ /domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
** Attachment added: Destination guest logs https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499/+attachment/3725329/+files/dest.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none' model='selinux'/ /domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions
Re: [Qemu-devel] virsh live migration w/o shared storage fails with error as vm is not running
On 06/13/2013 02:14 PM, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 10:31:04AM +0530, chandrashekar shastri wrote: We are testing the upstream KVM with : Kernel, Qemu, Libvirt, Virt-Manager is built from the source (git). kernel version : 3.9.0+ qemu version : QEMU emulator version 1.5.0 libvirt version : 1.0.5 virt-install : 0.600.3 I have followed the below steps to test the Live migration w/o shared storage feature : 1. Created the qemu-img create -f qcow2 vm.qcow2 12G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live rhel64-64 qemu+ssh://9.126.89.202/system --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source shutdown and got an error on the vnc display as Viewport:write: Broken pipe (32) and the VM on the destination was undefined. Below is the libvirt debug log, please let me with your comments. Debug log: -- What about /var/log/libvirt/qemu/rhel64-64.log? That is the QEMU command-line and stderr log. I have attached all source and destination logs, including the sosreport of both source and destination in the bug. https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1192499 Also can you try without copy-storage-all just to see if migration completes successfully? The guest will act weird once it migrates since the disk is zeroed but it will isolate the failure to --copy-storage-all. Without copy-storage-all (meaning with NFS shared storage the migration works fine). Stefan Please let me know if you need more info. Thanks, Shastri
Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page
Il 04/07/2013 23:07, Peter Lieven ha scritto: Am 04.07.2013 um 14:37 schrieb Paolo Bonzini pbonz...@redhat.com: Il 03/07/2013 23:23, Peter Lieven ha scritto: BDC is not used. I had an implementation that sent multiple descriptors out, but at least for my storage the maximum unmap counts not for each descriptors, but for all together. So in this case we do not need the field at all. I forgot to remove it. discard and write_zeroes will both only send one request up to max_unmap in size. apropos write_zeroes: do you know if UNMAP is guaranteed to unmap data if lbprz == 1? Yes. On the other hand note that WRITE_SAME should be guaranteed _not_ to unmap if lbprz == 0 and you do WRITE_SAME with UNMAP and a zero payload, but I suspect there may be buggy targets here. I have read in the specs something that the target might unmap the blocks or not touch them at all. Maybe you have more information. That's even true of UNMAP itself, actually. :) The storage can always upgrade a block from unmapped to anchored and from anchored to allocated, so UNMAP can be a no-op and still comply with the standard. My concern was, if I UNMAP a block and lbprz == 1 is it guaranteed that it reads as zero afterwards? Regardless if the target decides to upgrade the block or do not unmap the block? I would be very surprised, but if you are worried about that, it definitely won't happen with WRITE_SAME. Paolo
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
[CCing Vadim and Yan] On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote: Hi asias, 1 Window can not boot from vhost-scsi device; 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.) Do you have any plan about these? I can reproduce this issue on win2003 (Linux guest works fine). The guest hangs in the boot process. OS is on virito-blk disk, vhost-scsi is attached as the second disk. Guest probes from target 0 to 255. Only target 1 is available. vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except tareget 1. Howerver, from the log we can see, guest is sending to target 0 again and hangs afterwards. Vadim and Yan, any ideas? [ 3109.954237] br0: port 2(tap0) entered disabled state [ 3109.954387] device tap0 left promiscuous mode [ 3109.954389] br0: port 2(tap0) entered disabled state [ 3119.534136] device tap0 entered promiscuous mode [ 3119.534169] br0: port 2(tap0) entered forwarding state [ 3119.534180] br0: port 2(tap0) entered forwarding state [ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue. [ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.138669] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.138671] target=0, tpg= (null) [ 3120.138672] send bad target head=0, out=1 [ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139221] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139223] target=1, tpg=88021f8fc800 [ 3120.139225] Allocated tv_cmd: 880223cbf800 exp_data_len: 36, data_direction: 2 [ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0 [ 3120.139228] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0 [ 3120.139229] Mapping 1 iovecs for 1 pages [ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1 [ 3120.139472] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006bd9, len: 51 [ 3120.139474] target=1, tpg=88021f8fc800 [ 3120.139475] Allocated tv_cmd: 880223cbf800 exp_data_len: 0, data_direction: 3 [ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0 [ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1 [ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139557] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139558] target=1, tpg=88021f8fc800 [ 3120.139560] Allocated tv_cmd: 880223cbf800 exp_data_len: 8, data_direction: 2 [ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0 [ 3120.139563] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0 [ 3120.139564] Mapping 1 iovecs for 1 pages [ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139785] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139787] target=2, tpg= (null) [ 3120.139788] send bad target head=0, out=1 [ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139940] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 ... [ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.170305] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.170306] target=255, tpg= (null) [ 3120.170306] send bad target head=0, out=1 [ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.474652] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f280efe85, len: 51 [ 3120.474654] target=1, tpg=88021f8fc800 [ 3120.474656] Allocated tv_cmd: 880223cbf800 exp_data_len: 512, data_direction: 2 [ 3120.474658] vhost_scsi got command opcode: 0x28, lun: 0 [ 3120.474660] vhost_scsi_map_iov_to_sgl sg 880208f70d40 sgl_count 2 is_err 0 [ 3120.474662] Mapping 1 iovecs for 2 pages [ 3120.474666] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.474680] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.532843] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.532845] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f280efe85, len: 51 [ 3120.532847] target=1, tpg=88021f8fc800 [ 3120.532848] Allocated tv_cmd: 880223cbf800 exp_data_len: 512, data_direction: 2 [ 3120.532850] vhost_scsi got command opcode: 0x28, lun: 0 [ 3120.532852] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0 [ 3120.532853] Mapping 1
Re: [Qemu-devel] [PATCH] qom: trigger unrealized when device_finalize
Il 05/07/2013 05:26, Liu Ping Fan ha scritto:
Currently, unrealized is triggered in device_unparent(). But
unrealized normally involves the reclaim of resource occupied by
DeviceState. To obey the idiom that reclaiming resource when
refcnt reach zero, move it on the path of object_finalize().
As for device_unparent(), it would be the place to detach the
device from the other system.
This is wrong, unrealize is where the resources should be made invisible
to the guest. This removes a bunch of references to the memory regions
(from the flatview, from the parent region, etc.). Ultimately causes
finalization to be called (after we add RCU, finalization will happen at
the next grace period, because some of the references are removed from
call_rcu callbacks).
What you want is
http://permalink.gmane.org/gmane.comp.emulators.qemu/214871.
Paolo
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
hw/core/qdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 9190a7e..4258d8a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -768,6 +768,10 @@ static void device_initfn(Object *obj)
static void device_finalize(Object *obj)
{
DeviceState *dev = DEVICE(obj);
+
+if (dev-realized) {
+object_property_set_bool(obj, false, realized, NULL);
+}
if (dev-opts) {
qemu_opts_del(dev-opts);
}
@@ -794,9 +798,6 @@ static void device_unparent(Object *obj)
bus = QLIST_FIRST(dev-child_bus);
qbus_free(bus);
}
-if (dev-realized) {
-object_property_set_bool(obj, false, realized, NULL);
-}
if (dev-parent_bus) {
bus_remove_child(dev-parent_bus, dev);
object_unref(OBJECT(dev-parent_bus));
Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page
The device MIGHT map or anchor the blocks after the unmap but it may only do so if the blocks that become mapped are all zero. So I think you can safely assume that if lbprz==1 then it will always read back as zero no matter what happens internally in the target. Either the block becomes unmapped/deallocated and then it will read back as zero, or the blocks is automatically re-mapped to anchored/mapped again but this can only happen if the mapped block is all zero so once again it will still read back as all zero. === 4.7.3.5 Autonomous LBA transitions A device server may perform the following actions at any time: a) transition any deallocated LBA to mapped; b) transition any anchored LBA to mapped; or c) transition any deallocated LBA to anchored. If the LBPRZ bit in the READ CAPACITY (16) parameter data (see 5.16.2) is set to one, and a mapped LBA references a logical block that contains: a) user data with all bits set to zero; and Working Draft SCSI Block Commands – 3 (SBC-3) 27T10/BSR INCITS 514 Revision 35d 15 May 2013 b) protection information, if any, set to ___h, then the device server may transition that mapped LBA to anchored or deallocated at any time. The logical block provisioning st On Thu, Jul 4, 2013 at 2:07 PM, Peter Lieven p...@kamp.de wrote: Am 04.07.2013 um 14:37 schrieb Paolo Bonzini pbonz...@redhat.com: Il 03/07/2013 23:23, Peter Lieven ha scritto: BDC is not used. I had an implementation that sent multiple descriptors out, but at least for my storage the maximum unmap counts not for each descriptors, but for all together. So in this case we do not need the field at all. I forgot to remove it. discard and write_zeroes will both only send one request up to max_unmap in size. apropos write_zeroes: do you know if UNMAP is guaranteed to unmap data if lbprz == 1? Yes. On the other hand note that WRITE_SAME should be guaranteed _not_ to unmap if lbprz == 0 and you do WRITE_SAME with UNMAP and a zero payload, but I suspect there may be buggy targets here. I have read in the specs something that the target might unmap the blocks or not touch them at all. Maybe you have more information. That's even true of UNMAP itself, actually. :) The storage can always upgrade a block from unmapped to anchored and from anchored to allocated, so UNMAP can be a no-op and still comply with the standard. My concern was, if I UNMAP a block and lbprz == 1 is it guaranteed that it reads as zero afterwards? Regardless if the target decides to upgrade the block or do not unmap the block? Peter
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
The destination VM's log says: qemu: warning: error while loading state section id 1 This indicates that either there was an error on the destination while loading state or the migration stream got out of sync. Please check that QEMU on source and destination are identical. If you are running different versions of QEMU on source and destination this could be the cause. Try with qemu.git/master and a simple QEMU command-line (without libvirt): qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm -m 4000 \ -drive file=/home/images/rhel64-64.qcow2,if=ide,format=qcow2,cache=none Use the same command-line on the destination but also add -incoming tcp::1234. To start the migrate on the source, run migrate -b tcp :destination-ip:1234 in the QEMU monitor. If the failure can be reproduce on qemu.git/master in this way it will be easier to debug. I will be away next week and therefore unable to look into this more. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. Stating the obvious, a loop would be a more readable solution for adding 4 devices only differing in device/chardev id. ;)
[Qemu-devel] [Bug 1192499] Re: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer
Thanks, I ll work on this and update it. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer Status in QEMU: New Status in “libvirt” package in Ubuntu: Invalid Status in “libvirt” package in Fedora: Unknown Bug description: virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer and shut downs the guest on the source host. Kernel Version: 3.10.0-rc5+ Libvirt Version: 1.0.6 Qemu Version: 1.5.50 Steps to reproduce the issue: 1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. 2. Started the guest on the source 3. Started the vncdisplay to monitor the guest 4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all 5. It started the copying the storage from souce to destination (conitinously monitored it was growing) 6. Guest on the destination was paused and was running on the source 7. At some point the VM on the source got shutdown and migration failed with Unable to read from monitor: Connection reset by peer Attached the libvirt debug logs. The debug logs shows : 2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : Interrupting 2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even Live migration with nfs also was not working. Guest XML: domain type='kvm' nameVM1/name uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid memory unit='KiB'4096000/memory currentMemory unit='KiB'2048000/currentMemory vcpu placement='auto'1/vcpu numatune memory mode='strict' nodeset='0'/ /numatune os type arch='x86_64' machine='pc-i440fx-1.5'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/local/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/home/images/VM1.qcow2'/ target dev='hda' bus='ide'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller controller type='pci' index='0' model='pci-root'/ interface type='network' mac address='52:54:00:9d:cf:bb'/ source network='default'/ model type='rtl8139'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none' model='selinux'/ /domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions
Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
- Messaggio originale - Da: Fabio Fantoni fabio.fant...@m2r.biz A: Paolo Bonzini pbonz...@redhat.com Cc: Andreas Färber afaer...@suse.de, Stefano Stabellini stefano.stabell...@eu.citrix.com, xen-de...@lists.xensource.com, Wei Liu wei.l...@citrix.com, Ian Campbell ian.campb...@citrix.com, Ian Jackson ian.jack...@eu.citrix.com, qemu-devel@nongnu.org, Hans de Goede hdego...@redhat.com, spice-de...@lists.freedesktop.org Inviato: Venerdì, 5 luglio 2013 10:42:30 Oggetto: Re: [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. With only the EHCI you might have problems redirecting USB 1.1 devices. The EHCI+UHCI magic is the right thing to do for USB 2.0 support on x86. What Andreas and I were suggesting was to split the patch in two parts: first adding support for USB 2.0/3.0, and only then adding redirection (perhaps with the possibility to customize how many redirected devices to support). Paolo
Re: [Qemu-devel] [PATCH 01/17] cow: make reads go at a decent speed
On Wed, Jul 03, 2013 at 04:34:15PM +0200, Paolo Bonzini wrote:
@@ -146,23 +159,20 @@ static inline int is_bit_set(BlockDriverState *bs,
int64_t bitnum)
static int coroutine_fn cow_co_is_allocated(BlockDriverState *bs,
int64_t sector_num, int nb_sectors, int *num_same)
{
+int64_t bitnum = sector_num + sizeof(struct cow_header_v2) * 8;
+uint64_t offset = (bitnum / 8) -BDRV_SECTOR_SIZE;
+uint8_t bitmap[512];
Please use BDRV_SECTOR_SIZE, you used it one line above but then
switched to literal 512.
Re: [Qemu-devel] [PATCH 06/17] block: expect errors from bdrv_co_is_allocated
On Wed, Jul 03, 2013 at 04:34:20PM +0200, Paolo Bonzini wrote:
diff --git a/qemu-img.c b/qemu-img.c
index f8c97d3..857e2ca 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -2073,6 +2073,10 @@ static int img_rebase(int argc, char **argv)
/* If the cluster is allocated, we don't need to take action */
ret = bdrv_is_allocated(bs, sector, n, n);
+if (ret 0) {
+error_report(error while reading from file);
+goto out;
+}
We should print the errno valid and saying while reading from file is
a little misleading:
error while checking cluster allocation status: %d, ret
Re: [Qemu-devel] [PATCH v4 02/15] tcg: Split rem requirement from div requirement
On 4 July 2013 21:40, Richard Henderson r...@twiddle.net wrote: There are several hosts with only a div insn. Remainder is computed manually from the quotient and inputs. We can do this generically. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 05/07/2013 11:02, Paolo Bonzini ha scritto: - Messaggio originale - Da: Fabio Fantoni fabio.fant...@m2r.biz A: Paolo Bonzini pbonz...@redhat.com Cc: Andreas Färber afaer...@suse.de, Stefano Stabellini stefano.stabell...@eu.citrix.com, xen-de...@lists.xensource.com, Wei Liu wei.l...@citrix.com, Ian Campbell ian.campb...@citrix.com, Ian Jackson ian.jack...@eu.citrix.com, qemu-devel@nongnu.org, Hans de Goede hdego...@redhat.com, spice-de...@lists.freedesktop.org Inviato: Venerdì, 5 luglio 2013 10:42:30 Oggetto: Re: [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. With only the EHCI you might have problems redirecting USB 1.1 devices. The EHCI+UHCI magic is the right thing to do for USB 2.0 support on x86. What Andreas and I were suggesting was to split the patch in two parts: first adding support for USB 2.0/3.0, and only then adding redirection (perhaps with the possibility to customize how many redirected devices to support). Paolo What is the best parameters for adding usb2 controller, those who had already done? About usb1 controller implementation parameter in xen is only with -usb, is correct or need something better? About usb3 controller implementation what is the best parameters? About possibility to customize how many redirection channel I'll do it, if I remember good on Hans post on spice-devel I seen that max working is 4, is correct? About different usb controller implementation on xen can be good change xl parameter usb from 0|1 (usb1 controller added or not) to 0|1|2|3 where 0 is none, 1 is usb1, 2 is usb2 and 3 is usb3 or is better keep usb=0|1 and add usb_version=1|2|3 parameter? Thanks for any reply and sorry for my bad english.
Re: [Qemu-devel] [PATCH v4 08/15] tcg-arm: Make use of conditional availability of opcodes for divide
On 4 July 2013 21:40, Richard Henderson r...@twiddle.net wrote: We can now detect and use divide instructions at runtime, rather than having to restrict their availability to compile-time. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH v4 09/15] tcg-arm: Rename use_armv5_instructions to use_armvt5_instructions
On 4 July 2013 21:40, Richard Henderson r...@twiddle.net wrote: As it really controls the availability of a thumb interworking instruction on armv5t. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH v4 10/15] tcg-arm: Simplify logic in detecting the ARM ISA in use
On 4 July 2013 21:40, Richard Henderson r...@twiddle.net wrote: GCC 4.8 defines a handy __ARM_ARCH symbol that we can use, which will make us nicely forward compatible with ARMv8 AArch32. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH v4 11/15] tcg-arm: Use AT_PLATFORM to detect the host ISA
On 4 July 2013 21:40, Richard Henderson r...@twiddle.net wrote: With this we can generate armv7 insns even when the OS compiles for a lower common denominator. The macros are arranged so that when we do compile for a given ISA, all of the runtime checks for that ISA are optimized away. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] Wayland support
Thanks Alex! Currently I'm trying to enable Wayland in Tizen Emulator. Tizen Emulator is a clone of QEMU. Tizen can run in it as guest OS. It seems like that spice does not fit this requirement. Hi, I don't known if it's really a problem from qemu or tizen emulator. Wayland is running on your guest, so it's more a problem with kms,mesa,etc... a kms driver exist for cirrus card: http://lists.freedesktop.org/archives/dri-devel/2011-April/010396.html for spice (qxl) video card, a kms driver in currently in developement http://lists.freedesktop.org/archives/dri-devel/2013-March/035714.html If a kms driver exist, wayland should run (with software rendering, if no gallium driver exist in mesa) - Mail original - De: Max A Yu max.a...@intel.com À: Alexandre DERUMIER aderum...@odiso.com Cc: qemu-devel@nongnu.org Envoyé: Mercredi 3 Juillet 2013 10:14:59 Objet: RE: [Qemu-devel] Wayland support Thanks Alex! Currently I'm trying to enable Wayland in Tizen Emulator. Tizen Emulator is a clone of QEMU. Tizen can run in it as guest OS. It seems like that spice does not fit this requirement. Thanks, Max -Original Message- From: Alexandre DERUMIER [mailto:aderum...@odiso.com] Sent: Wednesday, July 03, 2013 2:14 PM To: Yu, Max A Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Wayland support I don't known if it's what you want, but wayland have a beta spice backend http://www.phoronix.com/scan.php?page=news_itempx=MTM1NzQ - Mail original - De: Max A Yu max.a...@intel.com À: qemu-devel@nongnu.org Envoyé: Mardi 2 Juillet 2013 05:36:50 Objet: [Qemu-devel] Wayland support Hi, Can QEMU support wayland? I’d like to know if anybody have ideas/solutions on that. Thanks, Max
Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 05/07/2013 11:27, Fabio Fantoni ha scritto: What is the best parameters for adding usb2 controller, those who had already done? About usb1 controller implementation parameter in xen is only with -usb, is correct or need something better? -usb is USB 1.0 on pc and USB 2.0 on q35. The device name for USB 1.0 is piix3-usb-uhci. About usb3 controller implementation what is the best parameters? The device name is nec-usb-xhci. Only USB 2.0 has the complication of companion controllers. About possibility to customize how many redirection channel I'll do it, if I remember good on Hans post on spice-devel I seen that max working is 4, is correct? I don't know. Paolo
Re: [Qemu-devel] [PATCH 06/17] block: expect errors from bdrv_co_is_allocated
Il 05/07/2013 11:19, Stefan Hajnoczi ha scritto:
/* If the cluster is allocated, we don't need to take action */
ret = bdrv_is_allocated(bs, sector, n, n);
+if (ret 0) {
+error_report(error while reading from file);
+goto out;
+}
We should print the errno valid and saying while reading from file is
a little misleading:
error while checking cluster allocation status: %d, ret
I think this is too specific. In the end, errors from bdrv_is_allocated
are almost always due to a problem reading the metadata from the file.
I will change it to error reading image metadata, or something like that.
(And also use strerror).
Paolo
Re: [Qemu-devel] [libvirt-users] libvirt virtio_net - host.freeze@reset.domain
On 04.07.2013 11:14, poma wrote: On 03.07.2013 13:43, Daniel P. Berrange wrote: On Tue, Jul 02, 2013 at 01:25:21PM +0200, poma wrote: Hello people, libvirtd (libvirt) 1.0.5.2 virsh 1.0.5.2 virt-manager 0.10.0 Host: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Guest1: Linux localhost 3.9.8-300.fc19.i686.PAE #1 SMP Thu Jun 27 19:29:30 UTC 2013 i686 (none) Guest2: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Virtual NIC - source model: macvtap/NAT/bridge virtio(virtio_net) Host freeze at virsh reset domain or virt-manager - Force Reset Need kernel.sysrq or power reset. I don't believe this is a libvirt issue - the 'virsh reset' command will issue the 'system_reset' QEMU monitor command. This in turn does an immediate reset of the guest CPUs/machine. Even if QEMU is doing the wrong thing, the kernel should obviously never freeze/crash in this way - it should be robust against a malicious QEMU process. You should probably send this message to the main QEMU and/or KVM mailing lists so that it comes to the attention of people who are more familiar with QEMU + virtio-net Regards, Daniel Thanks for your response. Mateusz hit the same issue[1] as well. OK, here we go. poma [1] https://lists.fedoraproject.org/pipermail/users/2013-July/436984.html OK, is this a side effect or not, but certainly kernel[1] with 'bridge-timer-fix.patch'[2] resolves issue aforementioned, so far. Thanks Cong, Josh. poma [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5569632 kernel-3.9.8-300.7.fc19.x86_64.rpm [2] https://bugzilla.redhat.com/show_bug.cgi?id=880035#c53 Ref. fix for unreliable guest-host multicast triggers oops https://bugzilla.redhat.com/show_bug.cgi?id=980254
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
Hi Asias, Windows driver should be able to support as many logical units and targets as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just propagate the relevant SRB error code to the port driver. In any case, I will try reproducing this problem on my system. Best, Vadim. - Original Message - From: Asias He as...@redhat.com To: Libaiqing libaiq...@huawei.com Cc: Paolo Bonzini pbonz...@redhat.com, Wenchao Xia xiaw...@linux.vnet.ibm.com, qemu-devel@nongnu.org, n...@linux-iscsi.org, Michael S. Tsirkin m...@redhat.com, Haofeng haof...@huawei.com, Vadim Rozenfeld vroze...@redhat.com, Yan Vugenfirer yvuge...@redhat.com Sent: Friday, July 5, 2013 4:52:05 PM Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module [CCing Vadim and Yan] On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote: Hi asias, 1 Window can not boot from vhost-scsi device; 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.) Do you have any plan about these? I can reproduce this issue on win2003 (Linux guest works fine). The guest hangs in the boot process. OS is on virito-blk disk, vhost-scsi is attached as the second disk. Guest probes from target 0 to 255. Only target 1 is available. vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except tareget 1. Howerver, from the log we can see, guest is sending to target 0 again and hangs afterwards. Vadim and Yan, any ideas? [ 3109.954237] br0: port 2(tap0) entered disabled state [ 3109.954387] device tap0 left promiscuous mode [ 3109.954389] br0: port 2(tap0) entered disabled state [ 3119.534136] device tap0 entered promiscuous mode [ 3119.534169] br0: port 2(tap0) entered forwarding state [ 3119.534180] br0: port 2(tap0) entered forwarding state [ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue. [ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.138669] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.138671] target=0, tpg= (null) [ 3120.138672] send bad target head=0, out=1 [ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139221] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139223] target=1, tpg=88021f8fc800 [ 3120.139225] Allocated tv_cmd: 880223cbf800 exp_data_len: 36, data_direction: 2 [ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0 [ 3120.139228] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0 [ 3120.139229] Mapping 1 iovecs for 1 pages [ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1 [ 3120.139472] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006bd9, len: 51 [ 3120.139474] target=1, tpg=88021f8fc800 [ 3120.139475] Allocated tv_cmd: 880223cbf800 exp_data_len: 0, data_direction: 3 [ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0 [ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1 [ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139557] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139558] target=1, tpg=88021f8fc800 [ 3120.139560] Allocated tv_cmd: 880223cbf800 exp_data_len: 8, data_direction: 2 [ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0 [ 3120.139563] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0 [ 3120.139564] Mapping 1 iovecs for 1 pages [ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 status 0x0 [ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139785] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.139787] target=2, tpg= (null) [ 3120.139788] send bad target head=0, out=1 [ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.139940] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 ... [ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.170305] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, len: 51 [ 3120.170306] target=255, tpg= (null) [ 3120.170306] send bad target head=0, out=1 [ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2 [ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2 [ 3120.474652] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f280efe85, len: 51 [ 3120.474654] target=1, tpg=88021f8fc800 [ 3120.474656] Allocated tv_cmd: 880223cbf800 exp_data_len:
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 28 June 2013 08:01, Rob Landley r...@landley.net wrote: Now that the next kernel's about to come out, I'm trying to get my arm versatile image to work under qemu 1.5.0. The old kernel doesn't work, and the current vanilla kernel doesn't work. This change broke it. Nope. Current vanilla is busted under QEMU-1.4-and-earlier behaviour too: the first PCI device will work but second and subsequent won't. The behaviour with QEMU 1.5 is the same. This is simply and straightforwardly a kernel bug and you need to get the kernel folk to fix it, preferably by actually writing PCI code which works on the hardware. -- PMM
[Qemu-devel] [PATCH 3/3] block: fix bdrv_flush() ordering in bdrv_close()
Since 80ccf93b we flush the block device during close. The
bdrv_drain_all() call should come before bdrv_flush() to ensure guest
write requests have completed. Otherwise we may miss pending writes
when flushing.
Call bdrv_drain_all() again for safety as the final step after
bdrv_flush(). This should not be necessary but we can be paranoid here
in case bdrv_flush() left I/O pending.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Kevin Wolf kw...@redhat.com
---
block.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 6c493ad..183fec8 100644
--- a/block.c
+++ b/block.c
@@ -1358,11 +1358,12 @@ void bdrv_reopen_abort(BDRVReopenState *reopen_state)
void bdrv_close(BlockDriverState *bs)
{
-bdrv_flush(bs);
if (bs-job) {
block_job_cancel_sync(bs-job);
}
-bdrv_drain_all();
+bdrv_drain_all(); /* complete I/O */
+bdrv_flush(bs);
+bdrv_drain_all(); /* in case flush left pending I/O */
notifier_list_notify(bs-close_notifiers, bs);
if (bs-drv) {
--
1.8.1.4
[Qemu-devel] [PATCH 1/3] vmdk: Implement .bdrv_has_zero_init
From: Fam Zheng f...@redhat.com
Depending on the subformat, has_zero_init queries underlying storage for
flat extent. If it has a flat extent and its underlying storage doesn't
have zero init, return 0. Otherwise return 1.
Aligns the operator assignments.
Signed-off-by: Fam Zheng f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
block/vmdk.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index a28fb5e..3756333 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1724,6 +1724,23 @@ static int64_t
vmdk_get_allocated_file_size(BlockDriverState *bs)
return ret;
}
+static int vmdk_has_zero_init(BlockDriverState *bs)
+{
+int i;
+BDRVVmdkState *s = bs-opaque;
+
+/* If has a flat extent and its underlying storage doesn't have zero init,
+ * return 0. */
+for (i = 0; i s-num_extents; i++) {
+if (s-extents[i].flat) {
+if (!bdrv_has_zero_init(s-extents[i].file)) {
+return 0;
+}
+}
+}
+return 1;
+}
+
static QEMUOptionParameter vmdk_create_options[] = {
{
.name = BLOCK_OPT_SIZE,
@@ -1762,21 +1779,22 @@ static QEMUOptionParameter vmdk_create_options[] = {
};
static BlockDriver bdrv_vmdk = {
-.format_name= vmdk,
-.instance_size = sizeof(BDRVVmdkState),
-.bdrv_probe = vmdk_probe,
-.bdrv_open = vmdk_open,
-.bdrv_reopen_prepare = vmdk_reopen_prepare,
-.bdrv_read = vmdk_co_read,
-.bdrv_write = vmdk_co_write,
-.bdrv_co_write_zeroes = vmdk_co_write_zeroes,
-.bdrv_close = vmdk_close,
-.bdrv_create= vmdk_create,
-.bdrv_co_flush_to_disk = vmdk_co_flush,
-.bdrv_co_is_allocated = vmdk_co_is_allocated,
-.bdrv_get_allocated_file_size = vmdk_get_allocated_file_size,
-
-.create_options = vmdk_create_options,
+.format_name = vmdk,
+.instance_size= sizeof(BDRVVmdkState),
+.bdrv_probe = vmdk_probe,
+.bdrv_open= vmdk_open,
+.bdrv_reopen_prepare = vmdk_reopen_prepare,
+.bdrv_read= vmdk_co_read,
+.bdrv_write = vmdk_co_write,
+.bdrv_co_write_zeroes = vmdk_co_write_zeroes,
+.bdrv_close = vmdk_close,
+.bdrv_create = vmdk_create,
+.bdrv_co_flush_to_disk= vmdk_co_flush,
+.bdrv_co_is_allocated = vmdk_co_is_allocated,
+.bdrv_get_allocated_file_size = vmdk_get_allocated_file_size,
+.bdrv_has_zero_init = vmdk_has_zero_init,
+
+.create_options = vmdk_create_options,
};
static void bdrv_vmdk_init(void)
--
1.8.1.4
[Qemu-devel] [PULL 0/3] Block patches
The following changes since commit ab8bf29078e0ab8347e2ff8b4e5542f7a0c751cf: Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2013-07-03 08:37:00 -0500) are available in the git repository at: git://github.com/stefanha/qemu.git block for you to fetch changes up to 58fda173e1156d24e5ff62361774715152188a07: block: fix bdrv_flush() ordering in bdrv_close() (2013-07-05 10:52:23 +0200) Fam Zheng (2): vmdk: Implement .bdrv_has_zero_init curl: refuse to open URL from HTTP server without range support Stefan Hajnoczi (1): block: fix bdrv_flush() ordering in bdrv_close() block.c | 5 +++-- block/curl.c | 24 ++-- block/vmdk.c | 48 +--- 3 files changed, 54 insertions(+), 23 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 2/3] curl: refuse to open URL from HTTP server without range support
From: Fam Zheng f...@redhat.com
CURL driver requests partial data from server on guest IO req. For HTTP
and HTTPS, it uses Range: *** in requests, and this will not work if
server not accepting range. This patch does this check when open.
* Removed curl_size_cb, which is not used: On one hand it's registered to
libcurl as CURLOPT_WRITEFUNCTION, instead of CURLOPT_HEADERFUNCTION,
which will get called with *data*, not *header*. On the other hand the
s-len is assigned unconditionally later.
In this gone function, the sscanf for Content-Length: %zd, on
(void *)ptr, which is not guaranteed to be zero-terminated, is
potentially a security bug. So this patch fixes it as a side-effect. The
bug is reported as: https://bugs.launchpad.net/qemu/+bug/1188943
(Note the bug is marked private so you might not be able to see it)
* Introduced curl_header_cb, which is used to parse header and mark the
server as accepting range if Accept-Ranges: bytes line is seen from
response header. If protocol is HTTP or HTTPS, but server response has
no not this support, refuse to open this URL.
Note that python builtin module SimpleHTTPServer is an example of not
supporting range, if you need to test this driver, get a better server
or use internet URLs.
Signed-off-by: Fam Zheng f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
block/curl.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index 6af8cb7..82d39ff 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -81,6 +81,7 @@ typedef struct BDRVCURLState {
CURLState states[CURL_NUM_STATES];
char *url;
size_t readahead_size;
+bool accept_range;
} BDRVCURLState;
static void curl_clean_state(CURLState *s);
@@ -110,14 +111,15 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, int
action,
return 0;
}
-static size_t curl_size_cb(void *ptr, size_t size, size_t nmemb, void *opaque)
+static size_t curl_header_cb(void *ptr, size_t size, size_t nmemb, void
*opaque)
{
-CURLState *s = ((CURLState*)opaque);
+BDRVCURLState *s = opaque;
size_t realsize = size * nmemb;
-size_t fsize;
+const char *accept_line = Accept-Ranges: bytes;
-if(sscanf(ptr, Content-Length: %zd, fsize) == 1) {
-s-s-len = fsize;
+if (realsize = strlen(accept_line)
+ strncmp((char *)ptr, accept_line, strlen(accept_line)) == 0) {
+s-accept_range = true;
}
return realsize;
@@ -447,8 +449,11 @@ static int curl_open(BlockDriverState *bs, QDict *options,
int flags)
// Get file size
+s-accept_range = false;
curl_easy_setopt(state-curl, CURLOPT_NOBODY, 1);
-curl_easy_setopt(state-curl, CURLOPT_WRITEFUNCTION, (void *)curl_size_cb);
+curl_easy_setopt(state-curl, CURLOPT_HEADERFUNCTION,
+ curl_header_cb);
+curl_easy_setopt(state-curl, CURLOPT_HEADERDATA, s);
if (curl_easy_perform(state-curl))
goto out;
curl_easy_getinfo(state-curl, CURLINFO_CONTENT_LENGTH_DOWNLOAD, d);
@@ -456,6 +461,13 @@ static int curl_open(BlockDriverState *bs, QDict *options,
int flags)
s-len = (size_t)d;
else if(!s-len)
goto out;
+if ((!strncasecmp(s-url, http://;, strlen(http://;))
+|| !strncasecmp(s-url, https://;, strlen(https://;)))
+ !s-accept_range) {
+pstrcpy(state-errmsg, CURL_ERROR_SIZE,
+Server does not support 'range' (byte ranges).);
+goto out;
+}
DPRINTF(CURL: Size = %zd\n, s-len);
curl_clean_state(state);
--
1.8.1.4
Re: [Qemu-devel] Wayland support
for spice (qxl) video card, a kms driver in currently in developement http://lists.freedesktop.org/archives/dri-devel/2013-March/035714.html update : This has been released in kernel 3.10. - Mail original - De: Alexandre DERUMIER aderum...@odiso.com À: Max A Yu max.a...@intel.com Cc: qemu-devel@nongnu.org Envoyé: Vendredi 5 Juillet 2013 11:58:21 Objet: Re: [Qemu-devel] Wayland support Thanks Alex! Currently I'm trying to enable Wayland in Tizen Emulator. Tizen Emulator is a clone of QEMU. Tizen can run in it as guest OS. It seems like that spice does not fit this requirement. Hi, I don't known if it's really a problem from qemu or tizen emulator. Wayland is running on your guest, so it's more a problem with kms,mesa,etc... a kms driver exist for cirrus card: http://lists.freedesktop.org/archives/dri-devel/2011-April/010396.html for spice (qxl) video card, a kms driver in currently in developement http://lists.freedesktop.org/archives/dri-devel/2013-March/035714.html If a kms driver exist, wayland should run (with software rendering, if no gallium driver exist in mesa) - Mail original - De: Max A Yu max.a...@intel.com À: Alexandre DERUMIER aderum...@odiso.com Cc: qemu-devel@nongnu.org Envoyé: Mercredi 3 Juillet 2013 10:14:59 Objet: RE: [Qemu-devel] Wayland support Thanks Alex! Currently I'm trying to enable Wayland in Tizen Emulator. Tizen Emulator is a clone of QEMU. Tizen can run in it as guest OS. It seems like that spice does not fit this requirement. Thanks, Max -Original Message- From: Alexandre DERUMIER [mailto:aderum...@odiso.com] Sent: Wednesday, July 03, 2013 2:14 PM To: Yu, Max A Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Wayland support I don't known if it's what you want, but wayland have a beta spice backend http://www.phoronix.com/scan.php?page=news_itempx=MTM1NzQ - Mail original - De: Max A Yu max.a...@intel.com À: qemu-devel@nongnu.org Envoyé: Mardi 2 Juillet 2013 05:36:50 Objet: [Qemu-devel] Wayland support Hi, Can QEMU support wayland? I’d like to know if anybody have ideas/solutions on that. Thanks, Max
[Qemu-devel] [Bug 685096] Re: USB Passthrough not working for Windows 7 guest
** This bug is no longer a duplicate of bug 1033727 USB passthrough doesn't work anymore with qemu-kvm 1.1.1 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/685096 Title: USB Passthrough not working for Windows 7 guest Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. The device appears in the device manager of Windows 7, but with Error code 10: device cannot start. I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. I am trying this with the latest git-pull of QEMU-KVM. The command line to launch qemu-kvm for win7 is: sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 The command line to launch qemu-kvm for winxp is: sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 Any help is appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/685096/+subscriptions
[Qemu-devel] [PATCH v4] s390: Implement dump-guest-memory support for target s390x
With this patch dump-guest-memory on s390 produces an ELF formatted,
crash-readable dump.
In order to implement this, the arch-specific part of dump-guest-memory
was added:
target-s390x/arch_dump.c contains the whole set of function for writing
Elf note sections of all types for s390x.
Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
[fixed indentation, use CamelCase, rename note_t to Note, use S390CPU]
---
include/elf.h | 6 ++
target-s390x/Makefile.objs | 2 +-
target-s390x/arch_dump.c | 213 +
target-s390x/cpu-qom.h | 5 ++
target-s390x/cpu.c | 4 +
5 files changed, 229 insertions(+), 1 deletion(-)
create mode 100644 target-s390x/arch_dump.c
diff --git a/include/elf.h b/include/elf.h
index cf0d3e2..58bfbf8 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -1348,11 +1348,17 @@ typedef struct elf64_shdr {
/* Notes used in ET_CORE */
#define NT_PRSTATUS1
+#define NT_FPREGSET 2
#define NT_PRFPREG 2
#define NT_PRPSINFO3
#define NT_TASKSTRUCT 4
#define NT_AUXV6
#define NT_PRXFPREG 0x46e62b7f /* copied from
gdb5.1/include/elf/common.h */
+#define NT_S390_PREFIX 0x305 /* s390 prefix register */
+#define NT_S390_CTRS0x304 /* s390 control registers */
+#define NT_S390_TODPREG 0x303 /* s390 TOD programmable register */
+#define NT_S390_TODCMP 0x302 /* s390 TOD clock comparator register
*/
+#define NT_S390_TIMER 0x301 /* s390 timer register */
/* Note header in a PT_NOTE section */
diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
index 4e63417..c34f654 100644
--- a/target-s390x/Makefile.objs
+++ b/target-s390x/Makefile.objs
@@ -1,4 +1,4 @@
obj-y += translate.o helper.o cpu.o interrupt.o
obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
-obj-$(CONFIG_SOFTMMU) += ioinst.o
+obj-$(CONFIG_SOFTMMU) += ioinst.o arch_dump.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/target-s390x/arch_dump.c b/target-s390x/arch_dump.c
new file mode 100644
index 000..bc8db62
--- /dev/null
+++ b/target-s390x/arch_dump.c
@@ -0,0 +1,213 @@
+/*
+ * writing ELF notes for s390x arch
+ *
+ *
+ * Copyright IBM Corp. 2012, 2013
+ *
+ * Ekaterina Tumanova tuman...@linux.vnet.ibm.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 cpu.h
+#include cpu-qom.h
+#include elf.h
+#include exec/cpu-all.h
+#include sysemu/dump.h
+#include sysemu/kvm.h
+
+
+struct S390xUserRegsStruct {
+uint64_t psw[2];
+uint64_t gprs[16];
+uint32_t acrs[16];
+} QEMU_PACKED;
+
+typedef struct S390xUserRegsStruct S390xUserRegs;
+
+struct S390xElfPrstatusStruct {
+uint8_t pad1[32];
+uint32_t pid;
+uint8_t pad2[76];
+S390xUserRegs regs;
+uint8_t pad3[16];
+} QEMU_PACKED;
+
+typedef struct S390xElfPrstatusStruct S390xElfPrstatus;
+
+struct S390xElfFpregsetStruct {
+uint32_t fpc;
+uint32_t pad;
+uint64_t fprs[16];
+} QEMU_PACKED;
+
+typedef struct S390xElfFpregsetStruct S390xElfFpregset;
+
+typedef struct noteStruct {
+Elf64_Nhdr hdr;
+char name[5];
+char pad3[3];
+union {
+S390xElfPrstatus prstatus;
+S390xElfFpregset fpregset;
+uint32_t prefix;
+uint64_t timer;
+uint64_t todcmp;
+uint32_t todpreg;
+uint64_t ctrs[16];
+} contents;
+} QEMU_PACKED Note;
+
+static void s390x_write_elf64_prstatus(Note *note, S390CPU *cpu)
+{
+int i;
+S390xUserRegs *regs;
+
+note-hdr.n_type = cpu_to_be32(NT_PRSTATUS);
+
+regs = (note-contents.prstatus.regs);
+regs-psw[0] = cpu_to_be64(cpu-env.psw.mask);
+regs-psw[1] = cpu_to_be64(cpu-env.psw.addr);
+for (i = 0; i = 15; i++) {
+regs-acrs[i] = cpu_to_be32(cpu-env.aregs[i]);
+regs-gprs[i] = cpu_to_be64(cpu-env.regs[i]);
+}
+}
+
+static void s390x_write_elf64_fpregset(Note *note, S390CPU *cpu)
+{
+int i;
+
+note-hdr.n_type = cpu_to_be32(NT_FPREGSET);
+note-contents.fpregset.fpc = cpu_to_be32(cpu-env.fpc);
+for (i = 0; i = 15; i++) {
+note-contents.fpregset.fprs[i] = cpu_to_be64(cpu-env.fregs[i].ll);
+}
+}
+
+
+static void s390x_write_elf64_timer(Note *note, S390CPU *cpu)
+{
+note-hdr.n_type = cpu_to_be32(NT_S390_TIMER);
+note-contents.timer = cpu_to_be64((uint64_t)(cpu-env.cputm));
+}
+
+static void s390x_write_elf64_todcmp(Note *note, S390CPU *cpu)
+{
+note-hdr.n_type = cpu_to_be32(NT_S390_TODCMP);
+note-contents.todcmp = cpu_to_be64((uint64_t)(cpu-env.ckc));
+}
+
+static void s390x_write_elf64_todpreg(Note *note, S390CPU *cpu)
+{
+note-hdr.n_type = cpu_to_be32(NT_S390_TODPREG);
+note-contents.todpreg = cpu_to_be32((uint32_t)(cpu-env.todpr));
+}
+
+static void s390x_write_elf64_ctrs(Note *note, S390CPU *cpu)
+{
+int i;
[Qemu-devel] [PATCH 0/3] Fail migration on bdrv_flush_all() error
If bdrv_flush_all() returns an error, there is an inconsistency in the view of an image file between the source and the destination host. Completing the migration would lead to corruption. Better abort migration in this case. Kevin Wolf (3): block: Add return value for bdrv_flush_all() cpus: Add return value for vm_stop() migration: Fail migration on bdrv_flush_all() error block.c | 10 -- cpus.c | 20 +--- include/block/block.h | 2 +- include/sysemu/sysemu.h | 4 ++-- migration.c | 17 ++--- stubs/vm-stop.c | 2 +- 6 files changed, 39 insertions(+), 16 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 2/3] cpus: Add return value for vm_stop()
If flushing the block devices fails, return an error. The VM is stopped
anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
cpus.c | 20 +---
include/sysemu/sysemu.h | 4 ++--
stubs/vm-stop.c | 2 +-
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 20958e5..e15fdcb 100644
--- a/cpus.c
+++ b/cpus.c
@@ -435,17 +435,21 @@ bool cpu_is_stopped(CPUState *cpu)
return !runstate_is_running() || cpu-stopped;
}
-static void do_vm_stop(RunState state)
+static int do_vm_stop(RunState state)
{
+int ret = 0;
+
if (runstate_is_running()) {
cpu_disable_ticks();
pause_all_vcpus();
runstate_set(state);
vm_state_notify(0, state);
bdrv_drain_all();
-bdrv_flush_all();
+ret = bdrv_flush_all();
monitor_protocol_event(QEVENT_STOP, NULL);
}
+
+return ret;
}
static bool cpu_can_run(CPUState *cpu)
@@ -1078,7 +1082,7 @@ void cpu_stop_current(void)
}
}
-void vm_stop(RunState state)
+int vm_stop(RunState state)
{
if (qemu_in_vcpu_thread()) {
qemu_system_vmstop_request(state);
@@ -1087,19 +1091,21 @@ void vm_stop(RunState state)
* vm_stop() has been requested.
*/
cpu_stop_current();
-return;
+return 0;
}
-do_vm_stop(state);
+
+return do_vm_stop(state);
}
/* does a state transition even if the VM is already stopped,
current state is forgotten forever */
-void vm_stop_force_state(RunState state)
+int vm_stop_force_state(RunState state)
{
if (runstate_is_running()) {
-vm_stop(state);
+return vm_stop(state);
} else {
runstate_set(state);
+return 0;
}
}
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..b5e1add 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -35,8 +35,8 @@ void vm_state_notify(int running, RunState state);
#define VMRESET_REPORT true
void vm_start(void);
-void vm_stop(RunState state);
-void vm_stop_force_state(RunState state);
+int vm_stop(RunState state);
+int vm_stop_force_state(RunState state);
typedef enum WakeupReason {
QEMU_WAKEUP_REASON_OTHER = 0,
diff --git a/stubs/vm-stop.c b/stubs/vm-stop.c
index 4568935..f82c897 100644
--- a/stubs/vm-stop.c
+++ b/stubs/vm-stop.c
@@ -1,7 +1,7 @@
#include qemu-common.h
#include sysemu/sysemu.h
-void vm_stop(RunState state)
+int vm_stop(RunState state)
{
abort();
}
--
1.8.1.4
[Qemu-devel] [PATCH 1/3] block: Add return value for bdrv_flush_all()
bdrv_flush() can fail, and bdrv_flush_all() should return an error as
well if this happens for a block device. It returns the first error
return now, but still at least tries to flush the remaining devices even
in error cases.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 10 --
include/block/block.h | 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index 6c493ad..6abdd99 100644
--- a/block.c
+++ b/block.c
@@ -2902,13 +2902,19 @@ int bdrv_get_flags(BlockDriverState *bs)
return bs-open_flags;
}
-void bdrv_flush_all(void)
+int bdrv_flush_all(void)
{
BlockDriverState *bs;
+int result = 0;
QTAILQ_FOREACH(bs, bdrv_states, list) {
-bdrv_flush(bs);
+int ret = bdrv_flush(bs);
+if (ret 0 !result) {
+result = ret;
+}
}
+
+return result;
}
int bdrv_has_zero_init_1(BlockDriverState *bs)
diff --git a/include/block/block.h b/include/block/block.h
index dd8eca1..31c1bbc 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -266,7 +266,7 @@ void bdrv_clear_incoming_migration_all(void);
/* Ensure contents are flushed to disk. */
int bdrv_flush(BlockDriverState *bs);
int coroutine_fn bdrv_co_flush(BlockDriverState *bs);
-void bdrv_flush_all(void);
+int bdrv_flush_all(void);
void bdrv_close_all(void);
void bdrv_drain_all(void);
--
1.8.1.4
[Qemu-devel] [PATCH 3/3] migration: Fail migration on bdrv_flush_all() error
If bdrv_flush_all() returns an error, there is an inconsistency in the
view of an image file between the source and the destination host.
Completing the migration would lead to corruption. Better abort
migration in this case.
To reproduce this case, try the following (ensures that there is
something to flush, and then fails that flush):
$ qemu-img create -f qcow2 test.qcow2 1G
$ cat blkdebug.cfg
[inject-error]
event = flush_to_os
errno = 5
$ qemu-system-x86_64 -hda blkdebug:blkdebug.cfg:test.qcow2 -monitor stdio
(qemu) qemu-io ide0-hd0 write 0 4k
(qemu) migrate ...
Signed-off-by: Kevin Wolf kw...@redhat.com
---
migration.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/migration.c b/migration.c
index a704d48..f7ae061 100644
--- a/migration.c
+++ b/migration.c
@@ -528,15 +528,26 @@ static void *migration_thread(void *opaque)
if (pending_size pending_size = max_size) {
qemu_savevm_state_iterate(s-file);
} else {
+int ret;
+
DPRINTF(done iterating\n);
qemu_mutex_lock_iothread();
start_time = qemu_get_clock_ms(rt_clock);
qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
old_vm_running = runstate_is_running();
-vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
-qemu_file_set_rate_limit(s-file, INT_MAX);
-qemu_savevm_state_complete(s-file);
+
+ret = vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
+if (ret = 0) {
+qemu_file_set_rate_limit(s-file, INT_MAX);
+qemu_savevm_state_complete(s-file);
+}
qemu_mutex_unlock_iothread();
+
+if (ret 0) {
+migrate_finish_set_state(s, MIG_STATE_ERROR);
+break;
+}
+
if (!qemu_file_get_error(s-file)) {
migrate_finish_set_state(s, MIG_STATE_COMPLETED);
break;
--
1.8.1.4
[Qemu-devel] [Bug 685096] Re: USB Passthrough not working for Windows 7 guest
I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/685096 Title: USB Passthrough not working for Windows 7 guest Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. The device appears in the device manager of Windows 7, but with Error code 10: device cannot start. I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. I am trying this with the latest git-pull of QEMU-KVM. The command line to launch qemu-kvm for win7 is: sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 The command line to launch qemu-kvm for winxp is: sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 Any help is appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/685096/+subscriptions
[Qemu-devel] [PATCH v2 0/2] add initial Calxeda Midway A15 support
While the Calxeda Midway part is actually a bit more than a Highbank with A15s, for QEMU's purposes this view is sufficient. So refactor the Highbank initialization to allow a very similar machine and add the necessary changes to support the new machine called midway. This is based on work by Rob Herring rob.herr...@calxeda.com. Signed-off-by: Andre Przywara andre.przyw...@calxeda.com Andre Przywara (2): ARM/highbank: prepare for adding similar machines ARM/highbank: add support for Calxeda ECX-2000 / Midway hw/arm/highbank.c | 61 +-- 1 file changed, 50 insertions(+), 11 deletions(-) -- 1.7.12.1
[Qemu-devel] [PATCH v2 1/2] ARM/highbank: prepare for adding similar machines
To allow the modelling of machines similar to Calxeda Highbank,
introduce a parameter to the init function and call it from a
wrapper. This allows to tweak the definition for individual machines
later on.
Signed-off-by: Andre Przywara andre.przyw...@calxeda.com
---
hw/arm/highbank.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index 4405dbd..2c32a2b 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm/highbank.c
@@ -183,20 +183,24 @@ type_init(highbank_regs_register_types)
static struct arm_boot_info highbank_binfo;
+enum cxmachines {
+CALXEDA_HIGHBANK,
+};
+
/* ram_size must be set to match the upper bound of memory in the
* device tree (linux/arch/arm/boot/dts/highbank.dts), which is
* normally 0xff90 or -m 4089. When running this board on a
* 32-bit host, set the reg value of memory to 0xf7ff0 in the
* device tree and pass -m 2047 to QEMU.
*/
-static void highbank_init(QEMUMachineInitArgs *args)
+static void calxeda_init(QEMUMachineInitArgs *args, enum cxmachines machine)
{
ram_addr_t ram_size = args-ram_size;
const char *cpu_model = args-cpu_model;
const char *kernel_filename = args-kernel_filename;
const char *kernel_cmdline = args-kernel_cmdline;
const char *initrd_filename = args-initrd_filename;
-DeviceState *dev;
+DeviceState *dev = NULL;
SysBusDevice *busdev;
qemu_irq *irqp;
qemu_irq pic[128];
@@ -208,7 +212,11 @@ static void highbank_init(QEMUMachineInitArgs *args)
char *sysboot_filename;
if (!cpu_model) {
-cpu_model = cortex-a9;
+switch (machine) {
+case CALXEDA_HIGHBANK:
+cpu_model = cortex-a9;
+break;
+}
}
for (n = 0; n smp_cpus; n++) {
@@ -246,7 +254,11 @@ static void highbank_init(QEMUMachineInitArgs *args)
}
}
-dev = qdev_create(NULL, a9mpcore_priv);
+switch (machine) {
+case CALXEDA_HIGHBANK:
+dev = qdev_create(NULL, a9mpcore_priv);
+break;
+}
qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
qdev_prop_set_uint32(dev, num-irq, NIRQ_GIC);
qdev_init_nofail(dev);
@@ -324,6 +336,11 @@ static void highbank_init(QEMUMachineInitArgs *args)
arm_load_kernel(arm_env_get_cpu(first_cpu), highbank_binfo);
}
+static void highbank_init(QEMUMachineInitArgs *args)
+{
+calxeda_init(args, CALXEDA_HIGHBANK);
+}
+
static QEMUMachine highbank_machine = {
.name = highbank,
.desc = Calxeda Highbank (ECX-1000),
@@ -333,9 +350,9 @@ static QEMUMachine highbank_machine = {
DEFAULT_MACHINE_OPTIONS,
};
-static void highbank_machine_init(void)
+static void calxeda_machines_init(void)
{
qemu_register_machine(highbank_machine);
}
-machine_init(highbank_machine_init);
+machine_init(calxeda_machines_init);
--
1.7.12.1
[Qemu-devel] [PATCH v2 2/2] ARM/highbank: add support for Calxeda ECX-2000 / Midway
The Calxeda ECX-2000 chip (aka. Midway) is model-wise quite similar
to the Highbank. The most prominent difference is the Cortex-A15 CPU
core in it, together with the associated core peripherals.
Add a new ARM machine type called midway.
Move the L2 cache controller device into the Highbank specific part,
since Midway does not have (and need) it.
Signed-off-by: Andre Przywara andre.przyw...@calxeda.com
---
hw/arm/highbank.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index 2c32a2b..3c99a81 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm/highbank.c
@@ -185,6 +185,7 @@ static struct arm_boot_info highbank_binfo;
enum cxmachines {
CALXEDA_HIGHBANK,
+CALXEDA_MIDWAY,
};
/* ram_size must be set to match the upper bound of memory in the
@@ -216,6 +217,9 @@ static void calxeda_init(QEMUMachineInitArgs *args, enum
cxmachines machine)
case CALXEDA_HIGHBANK:
cpu_model = cortex-a9;
break;
+case CALXEDA_MIDWAY:
+cpu_model = cortex-a15;
+break;
}
}
@@ -256,8 +260,16 @@ static void calxeda_init(QEMUMachineInitArgs *args, enum
cxmachines machine)
switch (machine) {
case CALXEDA_HIGHBANK:
+dev = qdev_create(NULL, l2x0);
+qdev_init_nofail(dev);
+busdev = SYS_BUS_DEVICE(dev);
+sysbus_mmio_map(busdev, 0, 0xfff12000);
+
dev = qdev_create(NULL, a9mpcore_priv);
break;
+case CALXEDA_MIDWAY:
+dev = qdev_create(NULL, a15mpcore_priv);
+break;
}
qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
qdev_prop_set_uint32(dev, num-irq, NIRQ_GIC);
@@ -272,11 +284,6 @@ static void calxeda_init(QEMUMachineInitArgs *args, enum
cxmachines machine)
pic[n] = qdev_get_gpio_in(dev, n);
}
-dev = qdev_create(NULL, l2x0);
-qdev_init_nofail(dev);
-busdev = SYS_BUS_DEVICE(dev);
-sysbus_mmio_map(busdev, 0, 0xfff12000);
-
dev = qdev_create(NULL, sp804);
qdev_prop_set_uint32(dev, freq0, 15000);
qdev_prop_set_uint32(dev, freq1, 15000);
@@ -341,6 +348,11 @@ static void highbank_init(QEMUMachineInitArgs *args)
calxeda_init(args, CALXEDA_HIGHBANK);
}
+static void midway_init(QEMUMachineInitArgs *args)
+{
+calxeda_init(args, CALXEDA_MIDWAY);
+}
+
static QEMUMachine highbank_machine = {
.name = highbank,
.desc = Calxeda Highbank (ECX-1000),
@@ -350,9 +362,19 @@ static QEMUMachine highbank_machine = {
DEFAULT_MACHINE_OPTIONS,
};
+static QEMUMachine midway_machine = {
+.name = midway,
+.desc = Calxeda Midway (ECX-2000),
+.init = midway_init,
+.block_default_type = IF_SCSI,
+.max_cpus = 4,
+DEFAULT_MACHINE_OPTIONS,
+};
+
static void calxeda_machines_init(void)
{
qemu_register_machine(highbank_machine);
+qemu_register_machine(midway_machine);
}
machine_init(calxeda_machines_init);
--
1.7.12.1
[Qemu-devel] [PATCH] Target-ppc : Enhance the CPU node labels for guest device tree for pseries.
[PATCH] Target-ppc : Enhance the CPU node labels for the guest
device tree for pseries.
In absence of a -CPU parameter in the qemu command line, the nodes of
KVM-enabled guest device tree look like this :
/proc/device-tree/cpus/HOST@0/...
/proc/device-tree/cpus/HOST@4/...
This patch replaces this obscure 'HOST' label with a more descriptive label.
This is gathered by first identifying the PVR of the host, and then determining
the host CPU alias which corresponds to the model indicated by this PVR.
Sample Final outcome for an KVM-enabled pseries guest running on POWER7:
/proc/device-tree/cpus/PowerPC,POWER7@0/...
/proc/device-tree/cpus/PowerPC,POWER7@4/...
This also helps userspace tools like ppc64_cpu, which expect the device tree
to be in this format in the guest.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
hw/ppc/spapr.c | 17 ++---
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 28
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index fe34291..e084f3f 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -79,6 +79,7 @@
#define HTAB_SIZE(spapr)(1ULL ((spapr)-htab_shift))
+#define PPC_DEVTREE_STR PowerPC,
sPAPREnvironment *spapr;
int spapr_allocate_irq(int hint, bool lsi)
@@ -295,9 +296,12 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
_FDT((fdt_property_cell(fdt, #address-cells, 0x1)));
_FDT((fdt_property_cell(fdt, #size-cells, 0x0)));
-modelname = g_strdup(cpu_model);
+/* device tree nodes must look like this :
+ * PowerPC,CPU_ALIAS@0
+ */
+modelname = g_strdup_printf(PPC_DEVTREE_STR %s, cpu_model);
-for (i = 0; i strlen(modelname); i++) {
+for (i = strlen(PPC_DEVTREE_STR); i strlen(modelname); i++) {
modelname[i] = toupper(modelname[i]);
}
@@ -735,7 +739,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
MemoryRegion *sysmem = get_system_memory();
MemoryRegion *ram = g_new(MemoryRegion, 1);
hwaddr rma_alloc_size;
-uint32_t initrd_base = 0;
+uint32_t initrd_base = 0, pvr = 0;
long kernel_size = 0, initrd_size = 0;
long load_limit, rtas_limit, fw_size;
char *filename;
@@ -959,6 +963,13 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
spapr-entry_point = 0x100;
+/* Ensure that cpu_model is correctly reflected for a KVM guest */
+if (kvm_enabled() !strcmp(cpu_model, host)) {
+asm (mfpvr %0
+: =r(pvr));
+cpu_model = ppc_cpu_alias_by_pvr(pvr);
+}
+
/* Prepare the device tree */
spapr-fdt_skel = spapr_create_fdt_skel(cpu_model,
initrd_base, initrd_size,
diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index 84ba105..90dd1dd 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -99,6 +99,7 @@ static inline PowerPCCPU *ppc_env_get_cpu(CPUPPCState *env)
#define ENV_OFFSET offsetof(PowerPCCPU, env)
PowerPCCPUClass *ppc_cpu_class_by_pvr(uint32_t pvr);
+const char *ppc_cpu_alias_by_pvr(uint32_t pvr);
void ppc_cpu_do_interrupt(CPUState *cpu);
void ppc_cpu_dump_state(CPUState *cpu, FILE *f, fprintf_function cpu_fprintf,
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 50e0ee5..21a7f6f 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7913,6 +7913,34 @@ PowerPCCPUClass *ppc_cpu_class_by_pvr(uint32_t pvr)
return pcc;
}
+const char *ppc_cpu_alias_by_pvr(uint32_t pvr)
+{
+int i;
+const char *cpu_alias;
+char *offset, *model;
+
+cpu_alias = object_class_get_name(OBJECT_CLASS
+(ppc_cpu_class_by_pvr(pvr)));
+
+/* Replace the full class name in cpu_alias with the CPU alias
+ * Eg, POWER7_V2.3-POWERPC64-CPU can simply be called
+ * POWER7
+ */
+
+offset = strstr(cpu_alias, - TYPE_POWERPC_CPU);
+if (offset) {
+model = g_strndup(cpu_alias, offset - cpu_alias);
+for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
+if (strcmp(ppc_cpu_aliases[i].model, model) == 0) {
+g_free(model);
+return ppc_cpu_aliases[i].alias;
+}
+}
+g_free(model);
+}
+return NULL;
+}
+
static gint ppc_cpu_compare_class_name(gconstpointer a, gconstpointer b)
{
ObjectClass *oc = (ObjectClass *)a;
--
1.7.11.7
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[Qemu-devel] [PATCH 1/3] qemu-timer: drop outdated signal safety comments
host_alarm_handler() may be invoked as a signal handler. Previously we
did more processing in the signal handler and therefore needed
signal-safe timer code.
Today host_alarm_handler() just marks the alarm timer as expired/pending
and notifies the main loop using qemu_notify_event().
Therefore these outdated comments about signal safety can be dropped.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
qemu-timer.c | 4
1 file changed, 4 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index b2d95e2..4740da9 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -300,8 +300,6 @@ void qemu_del_timer(QEMUTimer *ts)
{
QEMUTimer **pt, *t;
-/* NOTE: this code must be signal safe because
- qemu_timer_expired() can be called from a signal. */
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
@@ -324,8 +322,6 @@ void qemu_mod_timer_ns(QEMUTimer *ts, int64_t expire_time)
qemu_del_timer(ts);
/* add the timer in the sorted list */
-/* NOTE: this code must be signal safe because
- qemu_timer_expired() can be called from a signal. */
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
--
1.8.1.4
[Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread-safe
This series makes the following functions thread-safe: qemu_mod_timer_ns() qemu_mod_timer() qemu_del_timer() qemu_timer_pending() The following were already thread-safe: qemu_free_timer() qemu_new_timer() qemu_timer_expired() Now it is possible to use QEMUTimer outside the QEMU global mutex. Timer callbacks are still invoked from the main loop. If a thread wishes to run timer callbacks it must use a thread-safe QEMUBH (which Ping Fan Liu is working on). Note that host_clock is not thread-safe because it keeps state and invokes reset notifiers. Device emulation threads mostly care about vm_clock, so this is not a problem. Stefan Hajnoczi (3): qemu-timer: drop outdated signal safety comments qemu-timer: add QEMUClock-active_timers list lock qemu-timer: add qemu_alarm_timer-timer_modified_lock qemu-timer.c | 129 +-- 1 file changed, 90 insertions(+), 39 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 2/3] qemu-timer: add QEMUClock-active_timers list lock
This patch makes QEMUClock-active_timers list iteration thread-safe. With
additional patches, this will allow threads to use timers without holding the
QEMU global mutex.
The qemu_next_alarm_deadline() function was restructured to reduce code
duplication, which would have gotten worse due to the extra locking
calls. The new qemu_next_clock_deadline() function does the work of
updating the nearest deadline.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
qemu-timer.c | 96 +++-
1 file changed, 69 insertions(+), 27 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index 4740da9..c773af0 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -29,6 +29,7 @@
#include hw/hw.h
#include qemu/timer.h
+#include qemu/thread.h
#ifdef CONFIG_POSIX
#include pthread.h
#endif
@@ -46,6 +47,7 @@
struct QEMUClock {
QEMUTimer *active_timers;
+QemuMutex active_timers_lock;
NotifierList reset_notifiers;
int64_t last;
@@ -85,31 +87,38 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head,
int64_t current_time)
return timer_head (timer_head-expire_time = current_time);
}
-static int64_t qemu_next_alarm_deadline(void)
+static int64_t qemu_next_clock_deadline(QEMUClock *clock, int64_t delta)
{
-int64_t delta = INT64_MAX;
-int64_t rtdelta;
+int64_t expire_time, next;
+bool has_timer = false;
-if (!use_icount vm_clock-enabled vm_clock-active_timers) {
-delta = vm_clock-active_timers-expire_time -
- qemu_get_clock_ns(vm_clock);
+if (!clock-enabled) {
+return delta;
}
-if (host_clock-enabled host_clock-active_timers) {
-int64_t hdelta = host_clock-active_timers-expire_time -
- qemu_get_clock_ns(host_clock);
-if (hdelta delta) {
-delta = hdelta;
-}
+
+qemu_mutex_lock(clock-active_timers_lock);
+if (clock-active_timers) {
+has_timer = true;
+expire_time = clock-active_timers-expire_time;
}
-if (rt_clock-enabled rt_clock-active_timers) {
-rtdelta = (rt_clock-active_timers-expire_time -
- qemu_get_clock_ns(rt_clock));
-if (rtdelta delta) {
-delta = rtdelta;
-}
+qemu_mutex_unlock(clock-active_timers_lock);
+if (!has_timer) {
+return delta;
}
-return delta;
+next = expire_time - qemu_get_clock_ns(clock);
+return MIN(next, delta);
+}
+
+static int64_t qemu_next_alarm_deadline(void)
+{
+int64_t delta = INT64_MAX;
+
+if (!use_icount) {
+delta = qemu_next_clock_deadline(vm_clock, delta);
+}
+delta = qemu_next_clock_deadline(host_clock, delta);
+return qemu_next_clock_deadline(rt_clock, delta);
}
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
@@ -240,6 +249,7 @@ static QEMUClock *qemu_new_clock(int type)
clock-enabled = true;
clock-last = INT64_MIN;
notifier_list_init(clock-reset_notifiers);
+qemu_mutex_init(clock-active_timers_lock);
return clock;
}
@@ -254,22 +264,41 @@ void qemu_clock_enable(QEMUClock *clock, bool enabled)
int64_t qemu_clock_has_timers(QEMUClock *clock)
{
-return !!clock-active_timers;
+bool has_timers;
+
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = !!clock-active_timers;
+qemu_mutex_unlock(clock-active_timers_lock);
+return has_timers;
}
int64_t qemu_clock_expired(QEMUClock *clock)
{
-return (clock-active_timers
-clock-active_timers-expire_time qemu_get_clock_ns(clock));
+bool has_timers;
+int64_t expire_time;
+
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = clock-active_timers;
+expire_time = clock-active_timers-expire_time;
+qemu_mutex_unlock(clock-active_timers_lock);
+
+return has_timers expire_time qemu_get_clock_ns(clock);
}
int64_t qemu_clock_deadline(QEMUClock *clock)
{
/* To avoid problems with overflow limit this to 2^32. */
int64_t delta = INT32_MAX;
+bool has_timers;
+int64_t expire_time;
-if (clock-active_timers) {
-delta = clock-active_timers-expire_time - qemu_get_clock_ns(clock);
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = clock-active_timers;
+expire_time = clock-active_timers-expire_time;
+qemu_mutex_unlock(clock-active_timers_lock);
+
+if (has_timers) {
+delta = expire_time - qemu_get_clock_ns(clock);
}
if (delta 0) {
delta = 0;
@@ -298,8 +327,10 @@ void qemu_free_timer(QEMUTimer *ts)
/* stop a timer, but do not dealloc it */
void qemu_del_timer(QEMUTimer *ts)
{
+QEMUClock *clock = ts-clock;
QEMUTimer **pt, *t;
+qemu_mutex_lock(clock-active_timers_lock);
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
@@ -311,18 +342,21 @@ void qemu_del_timer(QEMUTimer *ts)
}
pt = t-next;
}
+
Re: [Qemu-devel] [PATCH 2/3] cpus: Add return value for vm_stop()
Il 05/07/2013 14:03, Kevin Wolf ha scritto:
If flushing the block devices fails, return an error. The VM is stopped
anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
cpus.c | 20 +---
include/sysemu/sysemu.h | 4 ++--
stubs/vm-stop.c | 2 +-
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 20958e5..e15fdcb 100644
--- a/cpus.c
+++ b/cpus.c
@@ -435,17 +435,21 @@ bool cpu_is_stopped(CPUState *cpu)
return !runstate_is_running() || cpu-stopped;
}
-static void do_vm_stop(RunState state)
+static int do_vm_stop(RunState state)
{
+int ret = 0;
+
if (runstate_is_running()) {
cpu_disable_ticks();
pause_all_vcpus();
runstate_set(state);
vm_state_notify(0, state);
bdrv_drain_all();
-bdrv_flush_all();
+ret = bdrv_flush_all();
monitor_protocol_event(QEVENT_STOP, NULL);
}
+
+return ret;
}
static bool cpu_can_run(CPUState *cpu)
@@ -1078,7 +1082,7 @@ void cpu_stop_current(void)
}
}
-void vm_stop(RunState state)
+int vm_stop(RunState state)
{
if (qemu_in_vcpu_thread()) {
qemu_system_vmstop_request(state);
@@ -1087,19 +1091,21 @@ void vm_stop(RunState state)
* vm_stop() has been requested.
*/
cpu_stop_current();
-return;
+return 0;
}
-do_vm_stop(state);
+
+return do_vm_stop(state);
}
/* does a state transition even if the VM is already stopped,
current state is forgotten forever */
-void vm_stop_force_state(RunState state)
+int vm_stop_force_state(RunState state)
{
if (runstate_is_running()) {
-vm_stop(state);
+return vm_stop(state);
} else {
runstate_set(state);
I think you should add a bdrv_flush_all() here. Otherwise, you could
migrate a stopped VM that has failed to flush (not that unlikely if the
VM was stopped due to ENOSPC, for example).
Overall these patches fix the problem and they are good, but I even
wonder if the failure to flush should change the runstate to I/O error
and trigger a monitor event.
In the end, the runstate design is showing some problems... I found
this discussion: http://patchwork.ozlabs.org/patch/117606/ and if you
search for Paolo Bonzini - Oct. 6, 2011, 11:14 a.m. you can find my
humble proposal.
Paolo
+return 0;
}
}
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..b5e1add 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -35,8 +35,8 @@ void vm_state_notify(int running, RunState state);
#define VMRESET_REPORT true
void vm_start(void);
-void vm_stop(RunState state);
-void vm_stop_force_state(RunState state);
+int vm_stop(RunState state);
+int vm_stop_force_state(RunState state);
typedef enum WakeupReason {
QEMU_WAKEUP_REASON_OTHER = 0,
diff --git a/stubs/vm-stop.c b/stubs/vm-stop.c
index 4568935..f82c897 100644
--- a/stubs/vm-stop.c
+++ b/stubs/vm-stop.c
@@ -1,7 +1,7 @@
#include qemu-common.h
#include sysemu/sysemu.h
-void vm_stop(RunState state)
+int vm_stop(RunState state)
{
abort();
}
[Qemu-devel] [PATCH 3/3] qemu-timer: add qemu_alarm_timer-timer_modified_lock
When a timer's expiration time is changed we may need to rearm the alarm
timer. Rearming is necessary when the nearest deadline changes.
This patch introduces the qemu_alarm_timer-timer_modified boolean and a
lock to protect it. It moves rearming the alarm timer from inside
qemu_mod_timer_ns() to qemu_run_all_timers() since we cannot rearm
outside the QEMU global mutex.
The following code is dropped because we always kick the main loop now:
/* Interrupt execution to force deadline recalculation. */
qemu_clock_warp(ts-clock);
if (use_icount) {
qemu_notify_event();
}
cpus.c will invoke qemu_clock_warp() again since the main loop ran.
It is now safe to call qemu_mod_timer_ns() for outside the QEMU global
mutex.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
qemu-timer.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index c773af0..9500d12 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -78,6 +78,10 @@ struct qemu_alarm_timer {
#endif
bool expired;
bool pending;
+
+/* Was the nearest deadline timer modified (possibly by another thread)? */
+QemuMutex timer_modified_lock;
+bool timer_modified;
};
static struct qemu_alarm_timer *alarm_timer;
@@ -371,14 +375,10 @@ void qemu_mod_timer_ns(QEMUTimer *ts, int64_t expire_time)
/* Rearm if necessary */
if (pt == ts-clock-active_timers) {
-if (!alarm_timer-pending) {
-qemu_rearm_alarm_timer(alarm_timer);
-}
-/* Interrupt execution to force deadline recalculation. */
-qemu_clock_warp(ts-clock);
-if (use_icount) {
-qemu_notify_event();
-}
+qemu_mutex_lock(alarm_timer-timer_modified_lock);
+alarm_timer-timer_modified = true;
+qemu_mutex_unlock(alarm_timer-timer_modified_lock);
+qemu_notify_event();
}
}
@@ -484,6 +484,8 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts)
void qemu_run_all_timers(void)
{
+bool timer_modified;
+
alarm_timer-pending = false;
/* vm time timers */
@@ -491,11 +493,20 @@ void qemu_run_all_timers(void)
qemu_run_timers(rt_clock);
qemu_run_timers(host_clock);
+/* Check if qemu_mod_timer_ns() has been called */
+qemu_mutex_lock(alarm_timer-timer_modified_lock);
+timer_modified = alarm_timer-timer_modified;
+alarm_timer-timer_modified = false;
+qemu_mutex_unlock(alarm_timer-timer_modified_lock);
+
/* rearm timer, if not periodic */
if (alarm_timer-expired) {
alarm_timer-expired = false;
qemu_rearm_alarm_timer(alarm_timer);
+} else if (timer_modified) {
+qemu_rearm_alarm_timer(alarm_timer);
}
+
}
#ifdef _WIN32
@@ -805,6 +816,8 @@ int init_timer_alarm(void)
goto fail;
}
+qemu_mutex_init(t-timer_modified_lock);
+
atexit(quit_timers);
#ifdef CONFIG_POSIX
pthread_atfork(NULL, NULL, reinit_timers);
--
1.8.1.4
Re: [Qemu-devel] [PATCH 2/3] qemu-timer: add QEMUClock-active_timers list lock
Il 05/07/2013 14:39, Stefan Hajnoczi ha scritto:
This patch makes QEMUClock-active_timers list iteration thread-safe. With
additional patches, this will allow threads to use timers without holding the
QEMU global mutex.
The qemu_next_alarm_deadline() function was restructured to reduce code
duplication, which would have gotten worse due to the extra locking
calls. The new qemu_next_clock_deadline() function does the work of
updating the nearest deadline.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
qemu-timer.c | 96
+++-
1 file changed, 69 insertions(+), 27 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index 4740da9..c773af0 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -29,6 +29,7 @@
#include hw/hw.h
#include qemu/timer.h
+#include qemu/thread.h
#ifdef CONFIG_POSIX
#include pthread.h
#endif
@@ -46,6 +47,7 @@
struct QEMUClock {
QEMUTimer *active_timers;
+QemuMutex active_timers_lock;
NotifierList reset_notifiers;
int64_t last;
@@ -85,31 +87,38 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head,
int64_t current_time)
return timer_head (timer_head-expire_time = current_time);
}
-static int64_t qemu_next_alarm_deadline(void)
+static int64_t qemu_next_clock_deadline(QEMUClock *clock, int64_t delta)
{
-int64_t delta = INT64_MAX;
-int64_t rtdelta;
+int64_t expire_time, next;
+bool has_timer = false;
-if (!use_icount vm_clock-enabled vm_clock-active_timers) {
-delta = vm_clock-active_timers-expire_time -
- qemu_get_clock_ns(vm_clock);
+if (!clock-enabled) {
+return delta;
}
-if (host_clock-enabled host_clock-active_timers) {
-int64_t hdelta = host_clock-active_timers-expire_time -
- qemu_get_clock_ns(host_clock);
-if (hdelta delta) {
-delta = hdelta;
-}
+
+qemu_mutex_lock(clock-active_timers_lock);
+if (clock-active_timers) {
+has_timer = true;
+expire_time = clock-active_timers-expire_time;
}
Ideally, the main loop would only lock clocks that have an expired
timer. We can optimize it later, but perhaps you can add a FIXME comment.
@@ -254,22 +264,41 @@ void qemu_clock_enable(QEMUClock *clock, bool enabled)
int64_t qemu_clock_has_timers(QEMUClock *clock)
{
-return !!clock-active_timers;
+bool has_timers;
+
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = !!clock-active_timers;
+qemu_mutex_unlock(clock-active_timers_lock);
+return has_timers;
This doesn't need the lock; the result can change immediately after
qemu_clock_has_timers returns. On the other hand, this is likely a sign
that the resulting code is actually not thread safe.
I think you can remove the call to qemu_clock_has_timers(vm_clock) from
qemu_clock_warp. It will advance icount_warp_timer by INT32_MAX nsecs
(a couple of seconds), which is fine.
}
int64_t qemu_clock_expired(QEMUClock *clock)
{
-return (clock-active_timers
-clock-active_timers-expire_time qemu_get_clock_ns(clock));
+bool has_timers;
+int64_t expire_time;
+
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = clock-active_timers;
+expire_time = clock-active_timers-expire_time;
+qemu_mutex_unlock(clock-active_timers_lock);
+
+return has_timers expire_time qemu_get_clock_ns(clock);
}
int64_t qemu_clock_deadline(QEMUClock *clock)
{
/* To avoid problems with overflow limit this to 2^32. */
int64_t delta = INT32_MAX;
+bool has_timers;
+int64_t expire_time;
-if (clock-active_timers) {
-delta = clock-active_timers-expire_time - qemu_get_clock_ns(clock);
+qemu_mutex_lock(clock-active_timers_lock);
+has_timers = clock-active_timers;
+expire_time = clock-active_timers-expire_time;
+qemu_mutex_unlock(clock-active_timers_lock);
+
+if (has_timers) {
+delta = expire_time - qemu_get_clock_ns(clock);
}
if (delta 0) {
delta = 0;
@@ -298,8 +327,10 @@ void qemu_free_timer(QEMUTimer *ts)
/* stop a timer, but do not dealloc it */
void qemu_del_timer(QEMUTimer *ts)
{
+QEMUClock *clock = ts-clock;
QEMUTimer **pt, *t;
+qemu_mutex_lock(clock-active_timers_lock);
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
@@ -311,18 +342,21 @@ void qemu_del_timer(QEMUTimer *ts)
}
pt = t-next;
}
+qemu_mutex_unlock(clock-active_timers_lock);
}
/* modify the current timer so that it will be fired when current_time
= expire_time. The corresponding callback will be called. */
void qemu_mod_timer_ns(QEMUTimer *ts, int64_t expire_time)
{
+QEMUClock *clock = ts-clock;
QEMUTimer **pt, *t;
qemu_del_timer(ts);
/* add the timer in
Re: [Qemu-devel] [PATCH v5] QEMUBH: make AioContext's bh re-entrant
On Wed, Jun 26, 2013 at 05:46:11PM +0800, liu ping fan wrote: On Tue, Jun 25, 2013 at 5:40 PM, Kevin Wolf kw...@redhat.com wrote: Am 25.06.2013 um 19:26 hat Liu Ping Fan geschrieben: BH will be used outside big lock, so introduce lock to protect between the writers, ie, bh's adders and deleter. The lock only affects the writers and bh's callback does not take this extra lock. Note that for the same AioContext, aio_bh_poll() can not run in parallel yet. Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com - Please use exactly three dashes so that 'git am' recognises it as the end of the commit message. Sorry, I will notice at the next time. Should I re-post it? Hi Ping Fan, I'm revisiting this patch but already sent the block pull request for this week. Therefore I suggest you repost - that will make it easier for Kevin to find the patch on the list next week when he's merging patches. Stefan
[Qemu-devel] [PATCH] hw/cpu/a15mpcore: Correct default value for num-irq
The a15mpcore device claims that its default value for num-irq
is the number of interrupts used by the A15MP in the vexpress-a15
board. However that chip has 128 external interrupts, not 64.
Since there is only one A15 based model in QEMU currently, we
can fix this by simply changing the default value.
This error was causing recent (3.10) Linux kernels to print
warnings/backtraces when the number of interrupts reported
by the GIC was smaller than an interrupt number they wanted
to use.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Conveniently, 160 is also the correct value for the A15 in the
Midway SoC, so this actually preemptively fixes a bug in the
midway patches currently on list :-)
Thanks to Christoffer Dall for tracking down what was happening here.
hw/cpu/a15mpcore.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/cpu/a15mpcore.c b/hw/cpu/a15mpcore.c
index 648656d..a902281 100644
--- a/hw/cpu/a15mpcore.c
+++ b/hw/cpu/a15mpcore.c
@@ -81,12 +81,12 @@ static int a15mp_priv_init(SysBusDevice *dev)
static Property a15mp_priv_properties[] = {
DEFINE_PROP_UINT32(num-cpu, A15MPPrivState, num_cpu, 1),
/* The Cortex-A15MP may have anything from 0 to 224 external interrupt
- * IRQ lines (with another 32 internal). We default to 64+32, which
+ * IRQ lines (with another 32 internal). We default to 128+32, which
* is the number provided by the Cortex-A15MP test chip in the
* Versatile Express A15 development board.
* Other boards may differ and should set this property appropriately.
*/
-DEFINE_PROP_UINT32(num-irq, A15MPPrivState, num_irq, 96),
+DEFINE_PROP_UINT32(num-irq, A15MPPrivState, num_irq, 160),
DEFINE_PROP_END_OF_LIST(),
};
--
1.7.9.5
Re: [Qemu-devel] [PATCH v5] QEMUBH: make AioContext's bh re-entrant
Il 05/07/2013 15:46, Stefan Hajnoczi ha scritto: On Wed, Jun 26, 2013 at 05:46:11PM +0800, liu ping fan wrote: On Tue, Jun 25, 2013 at 5:40 PM, Kevin Wolf kw...@redhat.com wrote: Am 25.06.2013 um 19:26 hat Liu Ping Fan geschrieben: BH will be used outside big lock, so introduce lock to protect between the writers, ie, bh's adders and deleter. The lock only affects the writers and bh's callback does not take this extra lock. Note that for the same AioContext, aio_bh_poll() can not run in parallel yet. Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com - Please use exactly three dashes so that 'git am' recognises it as the end of the commit message. Sorry, I will notice at the next time. Should I re-post it? Hi Ping Fan, I'm revisiting this patch but already sent the block pull request for this week. Therefore I suggest you repost - that will make it easier for Kevin to find the patch on the list next week when he's merging patches. In the meanwhile, I've sent a pull request for the atomics header that this patch depends on. Paolo
[Qemu-devel] [PATCHv2] block: add the optional file entry to query-block
This patch adds the optional file entry to the query-block output.
The value is a json-object representing the information about the
underlying file or device (when present).
Signed-off-by: Federico Simoncelli fsimo...@redhat.com
---
block/qapi.c |7 +++
qapi-schema.json |4 +++-
qmp-commands.hx|8
tests/qemu-iotests/043.out | 15 +++
4 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index a4bc411..40db983 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -171,6 +171,13 @@ void bdrv_query_image_info(BlockDriverState *bs,
return;
}
+if (bs-file) {
+bdrv_query_image_info(bs-file, info-file, err);
+if (info-file) {
+info-has_file = true;
+}
+}
+
*p_info = info;
}
diff --git a/qapi-schema.json b/qapi-schema.json
index 5c32528..0cb872c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -238,6 +238,8 @@
#
# @backing-image: #optional info of the backing image (since 1.6)
#
+# @file: #optional info of the underlying file (since 1.6)
+#
# Since: 1.3
#
##
@@ -248,7 +250,7 @@
'*cluster-size': 'int', '*encrypted': 'bool',
'*backing-filename': 'str', '*full-backing-filename': 'str',
'*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'],
- '*backing-image': 'ImageInfo' } }
+ '*backing-image': 'ImageInfo', '*file': 'ImageInfo' } }
##
# @ImageCheck:
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 362f0e1..bb8a931 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -1791,6 +1791,8 @@ Each json-object contain the following:
- backing-image: the detail of the backing image, it is an
optional json-object only present when a
backing image present for this image
+ - file: an optional json-object representing the information
+ about the underlying file or device (when present)
- io-status: I/O operation status, only present if the device supports it
and the VM is configured to stop on errors. It's always reset
@@ -1842,6 +1844,12 @@ Example:
format:qcow2,
virtual-size:2048000
}
+ file:{
+ filename:disks/test.qcow2,
+ format: file,
+ virtual-size: 262144,
+ actual-size: 139264
+ }
}
},
type:unknown
diff --git a/tests/qemu-iotests/043.out b/tests/qemu-iotests/043.out
index ad23337..6aea37b 100644
--- a/tests/qemu-iotests/043.out
+++ b/tests/qemu-iotests/043.out
@@ -44,6 +44,11 @@ cluster_size: 65536
filename: TEST_DIR/t.IMGFMT,
cluster-size: 65536,
format: IMGFMT,
+file: {
+virtual-size: 327680,
+filename: TEST_DIR/t.IMGFMT,
+format: file,
+},
backing-filename: TEST_DIR/t.IMGFMT.2.base,
dirty-flag: false
},
@@ -52,6 +57,11 @@ cluster_size: 65536
filename: TEST_DIR/t.IMGFMT.2.base,
cluster-size: 65536,
format: IMGFMT,
+file: {
+virtual-size: 327680,
+filename: TEST_DIR/t.IMGFMT.2.base,
+format: file,
+},
backing-filename: TEST_DIR/t.IMGFMT.1.base,
dirty-flag: false
},
@@ -60,6 +70,11 @@ cluster_size: 65536
filename: TEST_DIR/t.IMGFMT.1.base,
cluster-size: 65536,
format: IMGFMT,
+file: {
+virtual-size: 327680,
+filename: TEST_DIR/t.IMGFMT.1.base,
+format: file,
+},
dirty-flag: false
}
]
--
1.7.1
Re: [Qemu-devel] [PATCH v5 10/11] qemu-ga: Install Windows VSS provider on `qemu-ga -s install'
On 7/4/13 8:54 , Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/07/2013 18:19, Tomoki Sekiyama ha scritto:
On 7/3/13 11:58 , Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/07/2013 17:49, Tomoki Sekiyama ha scritto:
-return ga_install_service(path, log_filepath,
fixed_state_dir);
+if (ga_install_vss_provider()) {
+return EXIT_FAILURE;
+}
+if (ga_install_service(path, log_filepath,
fixed_state_dir)) {
+ga_uninstall_vss_provider();
+return EXIT_FAILURE;
+}
+return 0;
} else if (strcmp(service, uninstall) == 0) {
+ga_uninstall_vss_provider();
return ga_uninstall_service();
I think this shouldn't be a hard failure. Only the freeze/thaw
commands
should fail.
Paolo
Do you mean that qemu-ga should work without qga-provider.dll etc.
even if it is configured --with-vss-sdk ?
Yes, and I'm even wondering if we should move all VSS code to a DLL
(provider and requestor---they are very tied to each other anyway
because of hEventFrozen/hEventThaw), and have qemu-ga simply look for
qga-provider.dll dropped into the executable directory.
Then qemu-ga can look for it even if it is not configured --with-vss-sdk.
Hm, that sounds reasonable.
I will try on moving the requestor into qga-provider.dll at next
iteration.
This is because the license of the SDK may be problematic for
distributions that compile qemu-ga from source. These distribution
cannot distribute the SDK, and thus they will not be able to compile and
distribute the provider DLL. Still, we should make it as easy as
possible to combine a DLL and executable from separate sources
into---for example---a single MSI.
Paolo
Thanks,
Tomoki Sekiyama
[Qemu-devel] [PATCH] exec: Remove unused global variable phys_ram_fd
It seems to be unused since several years (commit
be995c27640a82c7056b6f53d02ec823570114e5 in 2006).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
exec.c |1 -
include/exec/cpu-all.h |1 -
2 files changed, 2 deletions(-)
diff --git a/exec.c b/exec.c
index c49806c..e8f95a9 100644
--- a/exec.c
+++ b/exec.c
@@ -53,7 +53,6 @@
//#define DEBUG_SUBPAGE
#if !defined(CONFIG_USER_ONLY)
-int phys_ram_fd;
static int in_migration;
RAMList ram_list = { .blocks = QTAILQ_HEAD_INITIALIZER(ram_list.blocks) };
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index 35bdf85..e791c05 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -447,7 +447,6 @@ hwaddr cpu_get_phys_page_debug(CPUArchState *env,
target_ulong addr);
/* memory API */
-extern int phys_ram_fd;
extern ram_addr_t ram_size;
/* RAM is pre-allocated and passed into qemu_ram_alloc_from_ptr */
--
1.7.10.4
[Qemu-devel] [Bug 764252] Re: wishlist: kirkwood support
With this I mean the bugreport, not the feature requested. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/764252 Title: wishlist: kirkwood support Status in QEMU: New Bug description: This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/764252/+subscriptions
[Qemu-devel] [Bug 764252] Re: wishlist: kirkwood support
This was added in 2011, is there a plan to integrate support for kirkwood? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/764252 Title: wishlist: kirkwood support Status in QEMU: New Bug description: This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/764252/+subscriptions
Re: [Qemu-devel] [PATCH 1/3] qemu-timer: drop outdated signal safety comments
On 2013-07-05 14:39, Stefan Hajnoczi wrote:
host_alarm_handler() may be invoked as a signal handler. Previously we
did more processing in the signal handler and therefore needed
signal-safe timer code.
Signal handlers run in the context of the signal processing thread, i.e.
the iothread so far.
Today host_alarm_handler() just marks the alarm timer as expired/pending
and notifies the main loop using qemu_notify_event().
Therefore these outdated comments about signal safety can be dropped.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
qemu-timer.c | 4
1 file changed, 4 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index b2d95e2..4740da9 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -300,8 +300,6 @@ void qemu_del_timer(QEMUTimer *ts)
{
QEMUTimer **pt, *t;
-/* NOTE: this code must be signal safe because
- qemu_timer_expired() can be called from a signal. */
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
@@ -324,8 +322,6 @@ void qemu_mod_timer_ns(QEMUTimer *ts, int64_t expire_time)
qemu_del_timer(ts);
/* add the timer in the sorted list */
-/* NOTE: this code must be signal safe because
- qemu_timer_expired() can be called from a signal. */
pt = ts-clock-active_timers;
for(;;) {
t = *pt;
If you fix the imprecision in the log:
Reviewed-by: Jan Kiszka jan.kis...@siemens.com
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -numa option
On Thu, Jul 04, 2013 at 05:53:08PM +0800, Wanlong Gao wrote:
From: Bandan Das b...@redhat.com
This allows us to use the cpus property multiple times
to specify multiple cpu (ranges) to the -numa option :
-numa node,cpus=1,cpus=2,cpus=4
or
-numa node,cpus=1-3,cpus=5
Note that after this patch, the defalut suffix of -numa node,mem=N
will no longer be M. So we must add the suffix M like -numa node,mem=NM
when assigning N MB of node memory size.
Such an incompatible change is not acceptable, as it would break
existing configurations. libvirt doesn't specify any suffix and expects
it to always mean MB.
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
qemu-options.hx | 3 +-
vl.c| 108
++--
2 files changed, 67 insertions(+), 44 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 137a39b..449cf36 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -100,7 +100,8 @@ STEXI
@item -numa @var{opts}
@findex -numa
Simulate a multi node NUMA system. If mem and cpus are omitted, resources
-are split equally.
+are split equally. The -cpus property may be specified multiple times
The option is not named -cpus, but just cpus. And I believe it is
normally called an option, not a property.
+to denote multiple cpus or cpu ranges.
ETEXI
DEF(add-fd, HAS_ARG, QEMU_OPTION_add_fd,
diff --git a/vl.c b/vl.c
index 6d9fd7d..6f2e17a 100644
--- a/vl.c
+++ b/vl.c
@@ -516,6 +516,32 @@ static QemuOptsList qemu_realtime_opts = {
},
};
+static QemuOptsList qemu_numa_opts = {
+.name = numa,
+.implied_opt_name = type,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_numa_opts.head),
+.desc = {
+{
+.name = type,
+.type = QEMU_OPT_STRING,
+.help = node type
+},{
+.name = nodeid,
+.type = QEMU_OPT_NUMBER,
+.help = node ID
+},{
+.name = mem,
+.type = QEMU_OPT_SIZE,
+.help = memory size
+},{
+.name = cpus,
+.type = QEMU_OPT_STRING,
+.help = cpu number or range
+},
+{ /* end of list */ }
+},
+};
+
const char *qemu_get_vm_name(void)
{
return qemu_name;
@@ -1349,56 +1375,37 @@ error:
exit(1);
}
-static void numa_add(const char *optarg)
+
+static int numa_add_cpus(const char *name, const char *value, void *opaque)
{
-char option[128];
-char *endptr;
-unsigned long long nodenr;
+int *nodenr = opaque;
-optarg = get_opt_name(option, 128, optarg, ',');
-if (*optarg == ',') {
-optarg++;
+if (!strcmp(name, cpu)) {
+numa_node_parse_cpus(*nodenr, value);
}
-if (!strcmp(option, node)) {
-
-if (nb_numa_nodes = MAX_NODES) {
-fprintf(stderr, qemu: too many NUMA nodes\n);
-exit(1);
-}
+return 0;
+}
-if (get_param_value(option, 128, nodeid, optarg) == 0) {
-nodenr = nb_numa_nodes;
-} else {
-if (parse_uint_full(option, nodenr, 10) 0) {
-fprintf(stderr, qemu: Invalid NUMA nodeid: %s\n, option);
-exit(1);
-}
-}
+static int numa_init_func(QemuOpts *opts, void *opaque)
+{
+uint64_t nodenr, mem_size;
-if (nodenr = MAX_NODES) {
-fprintf(stderr, qemu: invalid NUMA nodeid: %llu\n, nodenr);
-exit(1);
-}
+nodenr = qemu_opt_get_number(opts, nodeid, nb_numa_nodes++);
-if (get_param_value(option, 128, mem, optarg) == 0) {
-node_mem[nodenr] = 0;
-} else {
-int64_t sval;
-sval = strtosz(option, endptr);
-if (sval 0 || *endptr) {
-fprintf(stderr, qemu: invalid numa mem size: %s\n, optarg);
-exit(1);
-}
-node_mem[nodenr] = sval;
-}
-if (get_param_value(option, 128, cpus, optarg) != 0) {
-numa_node_parse_cpus(nodenr, option);
-}
-nb_numa_nodes++;
-} else {
-fprintf(stderr, Invalid -numa option: %s\n, option);
+if (nodenr = MAX_NODES) {
+fprintf(stderr, qemu: Max number of NUMA nodes reached : %d\n,
+(int)nodenr);
exit(1);
}
+
+mem_size = qemu_opt_get_size(opts, mem, 0);
+node_mem[nodenr] = mem_size;
+
+if (qemu_opt_foreach(opts, numa_add_cpus, nodenr, 1) 0) {
+return -1;
+}
+
+return 0;
}
static QemuOptsList qemu_smp_opts = {
@@ -2933,6 +2940,7 @@ int main(int argc, char **argv, char **envp)
qemu_add_opts(qemu_object_opts);
qemu_add_opts(qemu_tpmdev_opts);
qemu_add_opts(qemu_realtime_opts);
+qemu_add_opts(qemu_numa_opts);
runstate_init();
@@
Re: [Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread-safe
On 2013-07-05 14:39, Stefan Hajnoczi wrote: This series makes the following functions thread-safe: qemu_mod_timer_ns() qemu_mod_timer() qemu_del_timer() qemu_timer_pending() The following were already thread-safe: qemu_free_timer() qemu_new_timer() qemu_timer_expired() Now it is possible to use QEMUTimer outside the QEMU global mutex. Timer callbacks are still invoked from the main loop. If a thread wishes to run timer callbacks it must use a thread-safe QEMUBH (which Ping Fan Liu is working on). What do you mean with this? We need main-loop independent timers for any task that depends on timely alarm delivery. Do your patches keep this in mind as well? Note that host_clock is not thread-safe because it keeps state and invokes reset notifiers. Device emulation threads mostly care about vm_clock, so this is not a problem. I suppose you know that vm_clock cannot be read outside BQL yet due to timers_state and, under TCG, icount. Any ideas regarding this already? I didn't have to solve that problem so far as I only need CLOCK_REALTIME outside BQL. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
[Qemu-devel] [Bug 764252] Re: wishlist: kirkwood support
If somebody wants to write and submit code I will review it. I am not aware of anybody who is working on kirkwood emulation support or with plans to do so. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/764252 Title: wishlist: kirkwood support Status in QEMU: New Bug description: This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/764252/+subscriptions
Re: [Qemu-devel] [PATCH V4 00/10] Add support for binding guest numa nodes to host numa nodes
On Thu, Jul 04, 2013 at 05:53:07PM +0800, Wanlong Gao wrote:
[...]
Bandan Das (1):
NUMA: Support multiple CPU ranges on -numa option
Wanlong Gao (9):
NUMA: Add numa_info structure to contain numa nodes info
NUMA: Add Linux libnuma detection
NUMA: parse guest numa nodes memory policy
NUMA: handle Error in cpus, mpol and hostnode parser
NUMA: split out the common range parser
NUMA: set guest numa nodes memory policy
NUMA: add qmp command set-mpol to set memory policy for NUMA node
NUMA: add hmp command set-mpol
NUMA: show host memory policy info in info numa command
checkpatch.pl issues:
total: 0 errors, 0 warnings, 155 lines checked
/tmp/numav4-fp/0001-NUMA-Support-multiple-CPU-ranges-on-numa-option.patch has
no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 129 lines checked
/tmp/numav4-fp/0002-NUMA-Add-numa_info-structure-to-contain-numa-nodes-i.patch
has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 68 lines checked
/tmp/numav4-fp/0003-NUMA-Add-Linux-libnuma-detection.patch has no obvious style
problems and is ready for submission.
WARNING: braces {} are necessary for all arms of this statement
#106: FILE: vl.c:1424:
+if (parse_uint(hostnode, value, endptr, 10) 0)
[...]
WARNING: braces {} are necessary for all arms of this statement
#129: FILE: vl.c:1447:
+if (clear)
[...]
+else
[...]
total: 0 errors, 2 warnings, 158 lines checked
/tmp/numav4-fp/0004-NUMA-parse-guest-numa-nodes-memory-policy.patch has style
problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 108 lines checked
/tmp/numav4-fp/0005-NUMA-handle-Error-in-cpus-mpol-and-hostnode-parser.patch
has no obvious style problems and is ready for submission.
WARNING: suspect code indent for conditional statements (8, 11)
#47: FILE: vl.c:1351:
+if (parse_uint_full(endptr + 1, endvalue, 10) 0) {
+ return -1;
total: 0 errors, 1 warnings, 128 lines checked
/tmp/numav4-fp/0006-NUMA-split-out-the-common-range-parser.patch has style
problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
WARNING: braces {} are necessary for all arms of this statement
#100: FILE: cpus.c:1225:
+if (block-host == NULL)
[...]
total: 0 errors, 1 warnings, 105 lines checked
/tmp/numav4-fp/0007-NUMA-set-guest-numa-nodes-memory-policy.patch has style
problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 113 lines checked
/tmp/numav4-fp/0008-NUMA-add-qmp-command-set-mpol-to-set-memory-policy-f.patch
has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 66 lines checked
/tmp/numav4-fp/0009-NUMA-add-hmp-command-set-mpol.patch has no obvious style
problems and is ready for submission.
WARNING: braces {} are necessary for all arms of this statement
#70: FILE: monitor.c:1848:
+if (numa_info[i].flags NODE_HOST_RELATIVE)
[...]
WARNING: braces {} are necessary for all arms of this statement
#76: FILE: monitor.c:1854:
+if (next == numa_max_node())
[...]
WARNING: braces {} are necessary for all arms of this statement
#80: FILE: monitor.c:1858:
+if (next numa_max_node() || next == MAX_CPUMASK_BITS)
[...]
total: 0 errors, 3 warnings, 60 lines checked
/tmp/numav4-fp/0010-NUMA-show-host-memory-policy-info-in-info-numa-comma.patch
has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
--
Eduardo
Re: [Qemu-devel] [PATCH V4 10/10] NUMA: show host memory policy info in info numa command
On Thu, Jul 04, 2013 at 05:53:17PM +0800, Wanlong Gao wrote:
Show host memory policy of nodes in the info numa monitor command.
After this patch, the monitor command info numa will show the
information like following if the host numa support is enabled:
(qemu) info numa
2 nodes
node 0 cpus: 0
node 0 size: 1024 MB
node 0 mempolicy: membind=0,1
node 1 cpus: 1
node 1 size: 1024 MB
node 1 mempolicy: interleave=1
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
monitor.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/monitor.c b/monitor.c
index 93ac045..a40415d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -74,6 +74,11 @@
#endif
#include hw/lm32/lm32_pic.h
+#ifdef CONFIG_NUMA
+#include numa.h
+#include numaif.h
+#endif
+
//#define DEBUG
//#define DEBUG_COMPLETION
@@ -1808,6 +1813,7 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
int i;
CPUArchState *env;
CPUState *cpu;
+unsigned long first, next;
This breaks compilation with --enable-werror and CONFIG_NUMA disabled:
/home/ehabkost/rh/proj/virt/qemu/monitor.c: In function ‘do_info_numa’:
/home/ehabkost/rh/proj/virt/qemu/monitor.c:1816:26: error: unused variable
‘next’ [-Werror=unused-variable]
/home/ehabkost/rh/proj/virt/qemu/monitor.c:1816:19: error: unused variable
‘first’ [-Werror=unused-variable]
cc1: all warnings being treated as errors
make[1]: *** [monitor.o] Error 1
monitor_printf(mon, %d nodes\n, nb_numa_nodes);
for (i = 0; i nb_numa_nodes; i++) {
@@ -1821,6 +1827,42 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
monitor_printf(mon, \n);
monitor_printf(mon, node %d size: % PRId64 MB\n, i,
numa_info[i].node_mem 20);
+
+#ifdef CONFIG_NUMA
+monitor_printf(mon, node %d mempolicy: , i);
+switch (numa_info[i].flags NODE_HOST_POLICY_MASK) {
+case NODE_HOST_BIND:
+monitor_printf(mon, membind=);
+break;
+case NODE_HOST_INTERLEAVE:
+monitor_printf(mon, interleave=);
+break;
+case NODE_HOST_PREFERRED:
+monitor_printf(mon, preferred=);
+break;
+default:
+monitor_printf(mon, default\n);
+continue;
+}
+
+if (numa_info[i].flags NODE_HOST_RELATIVE)
+monitor_printf(mon, +);
+
+next = first = find_first_bit(numa_info[i].host_mem,
MAX_CPUMASK_BITS);
+monitor_printf(mon, %lu, first);
+do {
+if (next == numa_max_node())
+break;
+next = find_next_bit(numa_info[i].host_mem, MAX_CPUMASK_BITS,
+ next + 1);
+if (next numa_max_node() || next == MAX_CPUMASK_BITS)
+break;
+
+monitor_printf(mon, ,%lu, next);
+} while (true);
+
+monitor_printf(mon, \n);
+#endif
}
}
--
1.8.3.2.634.g7a3187e
--
Eduardo
Re: [Qemu-devel] [PATCH V4 02/10] NUMA: Add numa_info structure to contain numa nodes info
On Thu, Jul 04, 2013 at 05:53:09PM +0800, Wanlong Gao wrote:
Add the numa_info structure to contain the numa nodes memory,
VCPUs information and the future added numa nodes host memory
policies.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
Reviewed-by: Eduardo Habkost ehabk...@redhat.com
---
cpus.c | 2 +-
hw/i386/pc.c| 4 ++--
hw/net/eepro100.c | 1 -
include/sysemu/sysemu.h | 8 ++--
monitor.c | 2 +-
vl.c| 24
6 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/cpus.c b/cpus.c
index 20958e5..496d5ce 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1180,7 +1180,7 @@ void set_numa_modes(void)
for (env = first_cpu; env != NULL; env = env-next_cpu) {
cpu = ENV_GET_CPU(env);
for (i = 0; i nb_numa_nodes; i++) {
-if (test_bit(cpu-cpu_index, node_cpumask[i])) {
+if (test_bit(cpu-cpu_index, numa_info[i].node_cpu)) {
cpu-numa_node = i;
}
}
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 78f92e2..78b5a72 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -650,14 +650,14 @@ static FWCfgState *bochs_bios_init(void)
unsigned int apic_id = x86_cpu_apic_id_from_index(i);
assert(apic_id apic_id_limit);
for (j = 0; j nb_numa_nodes; j++) {
-if (test_bit(i, node_cpumask[j])) {
+if (test_bit(i, numa_info[j].node_cpu)) {
numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);
break;
}
}
}
for (i = 0; i nb_numa_nodes; i++) {
-numa_fw_cfg[apic_id_limit + 1 + i] = cpu_to_le64(node_mem[i]);
+numa_fw_cfg[apic_id_limit + 1 + i] =
cpu_to_le64(numa_info[i].node_mem);
}
fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, numa_fw_cfg,
(1 + apic_id_limit + nb_numa_nodes) *
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index dc99ea6..478c688 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -105,7 +105,6 @@
#define PCI_IO_SIZE 64
#define PCI_FLASH_SIZE (128 * KiB)
-#define BIT(n) (1 (n))
#define BITS(n, m) (((0xU (31 - n)) (31 - n + m)) m)
/* The SCB accepts the following controls for the Tx and Rx units: */
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..70fd2ed 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -9,6 +9,7 @@
#include qapi-types.h
#include qemu/notify.h
#include qemu/main-loop.h
+#include qemu/bitmap.h
/* vl.c */
@@ -130,8 +131,11 @@ extern QEMUClock *rtc_clock;
#define MAX_NODES 64
#define MAX_CPUMASK_BITS 255
extern int nb_numa_nodes;
-extern uint64_t node_mem[MAX_NODES];
-extern unsigned long *node_cpumask[MAX_NODES];
+struct node_info {
+uint64_t node_mem;
+DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS);
+};
+extern struct node_info numa_info[MAX_NODES];
#define MAX_OPTION_ROMS 16
typedef struct QEMUOptionRom {
diff --git a/monitor.c b/monitor.c
index 9be515c..93ac045 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1820,7 +1820,7 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
}
monitor_printf(mon, \n);
monitor_printf(mon, node %d size: % PRId64 MB\n, i,
-node_mem[i] 20);
+numa_info[i].node_mem 20);
}
}
diff --git a/vl.c b/vl.c
index 6f2e17a..5207b8e 100644
--- a/vl.c
+++ b/vl.c
@@ -250,8 +250,7 @@ static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
QTAILQ_HEAD_INITIALIZER(fw_boot_order);
int nb_numa_nodes;
-uint64_t node_mem[MAX_NODES];
-unsigned long *node_cpumask[MAX_NODES];
+struct node_info numa_info[MAX_NODES];
uint8_t qemu_uuid[16];
@@ -1367,7 +1366,7 @@ static void numa_node_parse_cpus(int nodenr, const char
*cpus)
goto error;
}
-bitmap_set(node_cpumask[nodenr], value, endvalue-value+1);
+bitmap_set(numa_info[nodenr].node_cpu, value, endvalue-value+1);
return;
error:
@@ -1399,7 +1398,7 @@ static int numa_init_func(QemuOpts *opts, void *opaque)
}
mem_size = qemu_opt_get_size(opts, mem, 0);
-node_mem[nodenr] = mem_size;
+numa_info[nodenr].node_mem = mem_size;
if (qemu_opt_foreach(opts, numa_add_cpus, nodenr, 1) 0) {
return -1;
@@ -2961,8 +2960,8 @@ int main(int argc, char **argv, char **envp)
translation = BIOS_ATA_TRANSLATION_AUTO;
for (i = 0; i MAX_NODES; i++) {
-node_mem[i] = 0;
-node_cpumask[i] = bitmap_new(MAX_CPUMASK_BITS);
+numa_info[i].node_mem = 0;
+bitmap_zero(numa_info[i].node_cpu, MAX_CPUMASK_BITS);
}
nb_numa_nodes = 0;
@@ -4228,7 +4227,7 @@ int main(int argc, char **argv, char **envp)
* and distribute the available memory equally
Re: [Qemu-devel] [PATCH V4 02/10] NUMA: Add numa_info structure to contain numa nodes info
Am 05.07.2013 21:32, schrieb Eduardo Habkost:
On Thu, Jul 04, 2013 at 05:53:09PM +0800, Wanlong Gao wrote:
Add the numa_info structure to contain the numa nodes memory,
VCPUs information and the future added numa nodes host memory
policies.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
Reviewed-by: Eduardo Habkost ehabk...@redhat.com
---
cpus.c | 2 +-
hw/i386/pc.c| 4 ++--
hw/net/eepro100.c | 1 -
include/sysemu/sysemu.h | 8 ++--
monitor.c | 2 +-
vl.c| 24
6 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/cpus.c b/cpus.c
index 20958e5..496d5ce 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1180,7 +1180,7 @@ void set_numa_modes(void)
for (env = first_cpu; env != NULL; env = env-next_cpu) {
cpu = ENV_GET_CPU(env);
for (i = 0; i nb_numa_nodes; i++) {
-if (test_bit(cpu-cpu_index, node_cpumask[i])) {
+if (test_bit(cpu-cpu_index, numa_info[i].node_cpu)) {
cpu-numa_node = i;
}
}
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 78f92e2..78b5a72 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -650,14 +650,14 @@ static FWCfgState *bochs_bios_init(void)
unsigned int apic_id = x86_cpu_apic_id_from_index(i);
assert(apic_id apic_id_limit);
for (j = 0; j nb_numa_nodes; j++) {
-if (test_bit(i, node_cpumask[j])) {
+if (test_bit(i, numa_info[j].node_cpu)) {
numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);
break;
}
}
}
for (i = 0; i nb_numa_nodes; i++) {
-numa_fw_cfg[apic_id_limit + 1 + i] = cpu_to_le64(node_mem[i]);
+numa_fw_cfg[apic_id_limit + 1 + i] =
cpu_to_le64(numa_info[i].node_mem);
}
fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, numa_fw_cfg,
(1 + apic_id_limit + nb_numa_nodes) *
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index dc99ea6..478c688 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -105,7 +105,6 @@
#define PCI_IO_SIZE 64
#define PCI_FLASH_SIZE (128 * KiB)
-#define BIT(n) (1 (n))
#define BITS(n, m) (((0xU (31 - n)) (31 - n + m)) m)
/* The SCB accepts the following controls for the Tx and Rx units: */
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..70fd2ed 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -9,6 +9,7 @@
#include qapi-types.h
#include qemu/notify.h
#include qemu/main-loop.h
+#include qemu/bitmap.h
/* vl.c */
@@ -130,8 +131,11 @@ extern QEMUClock *rtc_clock;
#define MAX_NODES 64
#define MAX_CPUMASK_BITS 255
extern int nb_numa_nodes;
-extern uint64_t node_mem[MAX_NODES];
-extern unsigned long *node_cpumask[MAX_NODES];
+struct node_info {
NodeInfo
+uint64_t node_mem;
+DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS);
+};
Please add a typedef and use that everywhere below.
+extern struct node_info numa_info[MAX_NODES];
I wonder if those structs should be QOM Objects instead, so that we can
use link properties from CPUState. I think Paolo suggested something
in that direction?
Regards,
Andreas
#define MAX_OPTION_ROMS 16
typedef struct QEMUOptionRom {
diff --git a/monitor.c b/monitor.c
index 9be515c..93ac045 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1820,7 +1820,7 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
}
monitor_printf(mon, \n);
monitor_printf(mon, node %d size: % PRId64 MB\n, i,
-node_mem[i] 20);
+numa_info[i].node_mem 20);
}
}
diff --git a/vl.c b/vl.c
index 6f2e17a..5207b8e 100644
--- a/vl.c
+++ b/vl.c
@@ -250,8 +250,7 @@ static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
QTAILQ_HEAD_INITIALIZER(fw_boot_order);
int nb_numa_nodes;
-uint64_t node_mem[MAX_NODES];
-unsigned long *node_cpumask[MAX_NODES];
+struct node_info numa_info[MAX_NODES];
uint8_t qemu_uuid[16];
@@ -1367,7 +1366,7 @@ static void numa_node_parse_cpus(int nodenr, const
char *cpus)
goto error;
}
-bitmap_set(node_cpumask[nodenr], value, endvalue-value+1);
+bitmap_set(numa_info[nodenr].node_cpu, value, endvalue-value+1);
return;
error:
@@ -1399,7 +1398,7 @@ static int numa_init_func(QemuOpts *opts, void *opaque)
}
mem_size = qemu_opt_get_size(opts, mem, 0);
-node_mem[nodenr] = mem_size;
+numa_info[nodenr].node_mem = mem_size;
if (qemu_opt_foreach(opts, numa_add_cpus, nodenr, 1) 0) {
return -1;
@@ -2961,8 +2960,8 @@ int main(int argc, char **argv, char **envp)
translation = BIOS_ATA_TRANSLATION_AUTO;
for (i = 0; i MAX_NODES; i++) {
-node_mem[i] = 0;
-node_cpumask[i]
[Qemu-devel] [PATCH 1/4] po/Makefile: Fix and improve help message
The help message contains single quotes which got lost in the output. Fix also a typo and use two instead of three lines. Signed-off-by: Stefan Weil s...@weilnetz.de --- po/Makefile |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/po/Makefile b/po/Makefile index 60ccd7d..2c5b202 100644 --- a/po/Makefile +++ b/po/Makefile @@ -12,9 +12,8 @@ SRC_PATH=.. vpath %.po $(SRC_PATH)/po all: - @echo Use 'make update' to update translation files - @echo or us 'make build' or 'make install' to build and install - @echo the translation files + @echo Use 'make update' to update translation files or use 'make build' + @echo or 'make install' to build and install the translation files. update: $(SRCS) -- 1.7.10.4
[Qemu-devel] [PATH 0/4] po/Makefile: Fix regression and some minor issues
These patches are included: [PATCH 1/4] po/Makefile: Fix and improve help message [PATCH 2/4] po/Makefile: Fix *.mo generation for out-of-tree builds [PATCH 3/4] po/Makefile: Fix generation of messages.po [PATCH 4/4] po/Makefile: Use macro quiet-command for nice looking Regards Stefan W.
[Qemu-devel] [PATCH 3/4] po/Makefile: Fix generation of messages.po
* Tell xgettext that we use UTF-8 encoding (this is currently optional). * Set charset=UTF-8 in messages.po. This avoids warnings from msgmerge: warning: Charset CHARSET is not a portable encoding name. * Use filename relative to root directory (ui/gtk.c instead of ../ui/gtk.c or $(SRC_PATH)/ui/gtk.c) for comments in *.po files. Signed-off-by: Stefan Weil s...@weilnetz.de --- po/Makefile |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/po/Makefile b/po/Makefile index 0e345b0..a6ab482 100644 --- a/po/Makefile +++ b/po/Makefile @@ -36,7 +36,11 @@ install: $(OBJS) @msgfmt -o $@ $ $(PO_PATH)/messages.po: $(SRC_PATH)/ui/gtk.c - @xgettext -o $@ --foreign-user --package-name=QEMU --package-version=$(VERSION) --msgid-bugs-address=qemu-devel@nongnu.org -k_ -C $ + @cd $(SRC_PATH) \ +(xgettext -o - --from-code=UTF-8 --foreign-user \ + --package-name=QEMU --package-version=$(VERSION) \ + --msgid-bugs-address=qemu-devel@nongnu.org -k_ -C ui/gtk.c | \ + sed -e s/CHARSET/UTF-8/) $@ $(PO_PATH)/%.po: $(PO_PATH)/messages.po @msgmerge $@ $ $@.bak mv $@.bak $@ -- 1.7.10.4
[Qemu-devel] [PATCH 2/4] po/Makefile: Fix *.mo generation for out-of-tree builds (regression)
Commit f84756554e32d97db3aa949db1dd58c7eea62375 added a wildcard search for *.po files. This search found no files for out of tree builds, so those builds no longer created and installed *.mo files. Signed-off-by: Stefan Weil s...@weilnetz.de --- po/Makefile | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/po/Makefile b/po/Makefile index 2c5b202..0e345b0 100644 --- a/po/Makefile +++ b/po/Makefile @@ -1,15 +1,18 @@ # This makefile is very special as it's meant to build as part of the build # process and also within the source tree to update the translation files. -VERSION=$(shell cat ../VERSION) -SRCS=$(filter-out messages.po,$(wildcard *.po)) -OBJS=$(patsubst %.po,%.mo,$(SRCS)) - +# Set SRC_PATH for in-tree builds without configuration. SRC_PATH=.. -include ../config-host.mak -vpath %.po $(SRC_PATH)/po +PO_PATH=$(SRC_PATH)/po + +VERSION=$(shell cat $(SRC_PATH)/VERSION) +SRCS=$(filter-out $(PO_PATH)/messages.po,$(wildcard $(PO_PATH)/*.po)) +OBJS=$(patsubst $(PO_PATH)/%.po,%.mo,$(SRCS)) + +vpath %.po $(PO_PATH) all: @echo Use 'make update' to update translation files or use 'make build' @@ -30,12 +33,12 @@ install: $(OBJS) done %.mo: %.po - @msgfmt -o $@ $(SRC_PATH)/po/`basename $@ .mo`.po + @msgfmt -o $@ $ -messages.po: $(SRC_PATH)/ui/gtk.c +$(PO_PATH)/messages.po: $(SRC_PATH)/ui/gtk.c @xgettext -o $@ --foreign-user --package-name=QEMU --package-version=$(VERSION) --msgid-bugs-address=qemu-devel@nongnu.org -k_ -C $ -%.po: messages.po +$(PO_PATH)/%.po: $(PO_PATH)/messages.po @msgmerge $@ $ $@.bak mv $@.bak $@ .PHONY: clean all -- 1.7.10.4
[Qemu-devel] [PATCH 4/4] po/Makefile: Use macro quiet-command for nice looking messages
Suppress also the ... done message from msgmerge. Signed-off-by: Stefan Weil s...@weilnetz.de --- po/Makefile |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/po/Makefile b/po/Makefile index a6ab482..705166e 100644 --- a/po/Makefile +++ b/po/Makefile @@ -5,6 +5,7 @@ SRC_PATH=.. -include ../config-host.mak +include $(SRC_PATH)/rules.mak PO_PATH=$(SRC_PATH)/po @@ -33,16 +34,16 @@ install: $(OBJS) done %.mo: %.po - @msgfmt -o $@ $ + $(call quiet-command, msgfmt -o $@ $, GEN $@) $(PO_PATH)/messages.po: $(SRC_PATH)/ui/gtk.c - @cd $(SRC_PATH) \ + $(call quiet-command, cd $(SRC_PATH) \ (xgettext -o - --from-code=UTF-8 --foreign-user \ --package-name=QEMU --package-version=$(VERSION) \ --msgid-bugs-address=qemu-devel@nongnu.org -k_ -C ui/gtk.c | \ - sed -e s/CHARSET/UTF-8/) $@ + sed -e s/CHARSET/UTF-8/) $@, GEN $@) $(PO_PATH)/%.po: $(PO_PATH)/messages.po - @msgmerge $@ $ $@.bak mv $@.bak $@ + $(call quiet-command, msgmerge -q $@ $ $@.bak mv $@.bak $@, GEN $@) .PHONY: clean all -- 1.7.10.4
Re: [Qemu-devel] [Xen-devel] [PATCH v5] Xen PV Device
On Thu, Jul 04, 2013 at 01:52:46PM +0100, Stefano Stabellini wrote:
On Thu, 4 Jul 2013, Paul Durrant wrote:
Introduces a new Xen PV PCI device which will act as a binding point for
PV drivers for Xen.
The device has parameterized vendor-id, device-id and revision to allow to
be configured as a binding point for any vendor's PV drivers.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@citrix.com
Reviewed-by: Andreas Färber afaer...@suse.de
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Matt Wilson m...@amazon.com
V5:
- Addresses comments from Andreas Färber
V4:
- Renamed from 'Citrix PV Bus' to 'Xen PV Device'
- Paramaterized vendor-id and device-id as requested by Stefano Stabellini
V3:
- Addresses comments from Anthony Liguori and Peter Maydell
V2:
- Addresses comments from Andreas Farber and Paolo Bonzini
hw/xen/Makefile.objs |1 +
hw/xen/xen_pvdevice.c| 131
++
include/hw/pci/pci_ids.h |5 +-
trace-events |4 ++
4 files changed, 139 insertions(+), 2 deletions(-)
create mode 100644 hw/xen/xen_pvdevice.c
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 2017560..cd2df6a 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,6 @@
# xen backend driver support
common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-y += xen_pvdevice.o
obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c
new file mode 100644
index 000..93dfab2
--- /dev/null
+++ b/hw/xen/xen_pvdevice.c
@@ -0,0 +1,131 @@
+/* Copyright (c) Citrix Systems Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms,
+ * with or without modification, are permitted provided
+ * that the following conditions are met:
+ *
+ * * Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the
+ * following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the
+ * following disclaimer in the documentation and/or other
+ * materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include hw/hw.h
+#include hw/pci/pci.h
+#include trace.h
+
+#define TYPE_XEN_PV_DEVICE xen-pvdevice
+
+#define XEN_PV_DEVICE(obj) \
+ OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE)
+
+typedef struct XenPVDevice {
+/* private */
+PCIDevice parent_obj;
+/* public */
+uint16_tvendor_id;
+uint16_tdevice_id;
+uint8_t revision;
+uint32_tsize;
+MemoryRegionmmio;
+} XenPVDevice;
+
+static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr,
+ unsigned size)
+{
+trace_xen_pv_mmio_read(addr);
+
+return ~(uint64_t)0;
+}
+
+static void xen_pv_mmio_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+trace_xen_pv_mmio_write(addr);
+}
+
+static const MemoryRegionOps xen_pv_mmio_ops = {
+.read = xen_pv_mmio_read,
+.write = xen_pv_mmio_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int xen_pv_init(PCIDevice *pci_dev)
+{
+XenPVDevice *d = XEN_PV_DEVICE(pci_dev);
+uint8_t *pci_conf;
+
+pci_conf = pci_dev-config;
+
+pci_set_word(pci_conf + PCI_VENDOR_ID, d-vendor_id);
+pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d-vendor_id);
+pci_set_word(pci_conf + PCI_DEVICE_ID, d-device_id);
+pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d-device_id);
+pci_set_byte(pci_conf + PCI_REVISION_ID, d-revision);
+
+pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY);
+
+
[Qemu-devel] [Bug 1198350] [NEW] USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument
Public bug reported: Host Gentoo linux 32bit Guest Windows XP SP3 qemu 1.4.2 and qemu fresh get clone and build 2013-07-04 (version1.5.50) qemu command line qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19 The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support. When the USB device is plugged in qemu reports to the command line: USBDEVFS_DISCONNECT: Invalid argument Invalid argument dmesg shows [237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 [237755.582781] usb 2-1.5: config 1 has no interface number 0 [237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019 [237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [237755.583633] usb 2-1.5: Product: Ambit [237755.583634] usb 2-1.5: Manufacturer: Suunto [237755.583636] usb 2-1.5: SerialNumber: CE8309511700 [237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci [237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci [237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be. I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy. I'm guessing it has something to do with the the dmesg lines: [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 [237755.582781] usb 2-1.5: config 1 has no interface number 0 But read that these warnings are not important though I don't get them for other devices. Nor do I get: [237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use I've done alot of searching and I've run out of ideas. Any help would be great. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1198350 Title: USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument Status in QEMU: New Bug description: Host Gentoo linux 32bit Guest Windows XP SP3 qemu 1.4.2 and qemu fresh get clone and build 2013-07-04 (version1.5.50) qemu command line qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19 The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support. When the USB device is plugged in qemu reports to the command line: USBDEVFS_DISCONNECT: Invalid argument Invalid argument dmesg shows [237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 [237755.582781] usb 2-1.5: config 1 has no interface number 0 [237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019 [237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [237755.583633] usb 2-1.5: Product: Ambit [237755.583634] usb 2-1.5: Manufacturer: Suunto [237755.583636] usb 2-1.5: SerialNumber: CE8309511700 [237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci [237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci [237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be. I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy. I'm guessing it has something to do with the the dmesg lines: [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 [237755.582781] usb 2-1.5: config 1 has no interface number 0 But read that these warnings are not important though I don't get them for other devices. Nor do I get:
[Qemu-devel] ANN: DeveloperNews - a qemu-devel digest for maintainers and contributors
Hello everyone, Inspired by a complaint from Scott about information getting lost amongst qemu-devel mails, and spawning a qemu-announce mailing list being out of my powers, I have started a simple Wiki page: http://wiki.qemu.org/DeveloperNews The idea is to have a brief summary of decisions and code changes that affect all maintainers and/or contributors, with references into qemu-devel archive or git.qemu.org or developers' blogs for more info, latest news sorted first. For example, to aid in getting up to speed after a four-week vacation, and to aid hobbyists in coping with the sheer incredible list volume. Self-explanatory that this will only work when information there is less than on qemu-devel (i.e., not every PULL or patchset linked). The intended scope is not random news about what changed in qemu.git but code changes that require fellow developers to rebase or to adopt new patterns and conventions and review criteria. The removal of some function does not necessarily need to be documented there (anyone building against latest master would notice a breakage) but whenever there's old and new ways to do things, we can advise which to choose. The initial contents is of course biased to what's close to my heart; but it's a Wiki, so for instance Stefan H. could add a bullet point about new devices please using new asynchronous block layer APIs only. Obviously adding Wiki contents is work, it cannot replace cover letters or commit messages, but after the n-th reply pages like SubmitAPatch or QOMConventions have become very handy to refer to. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] target-openrisc: Add typename for CPU models.
Hi Andreas,
On Tue, Jul 2, 2013 at 6:18 PM, Andreas Färber afaer...@suse.de wrote:
Hi Jia,
Am 02.07.2013 11:29, schrieb Jia Liu:
On Tue, Jul 2, 2013 at 5:11 PM, Dongxue Zhang elta@gmail.com
mailto:elta@gmail.com wrote:
Make target-openrisc running OK by add typename in
openrisc_cpu_class_by_name().
Signed-off-by: Dongxue Zhang elta@gmail.com
mailto:elta@gmail.com
---
target-openrisc/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index fd90d37..d38c28b 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -96,12 +96,14 @@ static void openrisc_cpu_initfn(Object *obj)
static ObjectClass *openrisc_cpu_class_by_name(const char *cpu_model)
{
ObjectClass *oc;
+char *typename;
if (cpu_model == NULL) {
return NULL;
}
-oc = object_class_by_name(cpu_model);
+typename = g_strdup_printf(%s- TYPE_OPENRISC_CPU, cpu_model);
+oc = object_class_by_name(typename);
if (oc != NULL (!object_class_dynamic_cast(oc,
TYPE_OPENRISC_CPU) ||
object_class_is_abstract(oc))) {
return NULL;
Thanks for your fix, it looks and test good to me.
Sorry for the breakage. Do you want to add a
Reviewed-by/Tested-by/Acked-by? I'd queue it for you then.
If you could upload a Linux test image somewhere that may help avoid
breakages in the future.
I've upload a Linux test image to my Google Drive.
https://docs.google.com/file/d/0BxeTrz3x0CBLbTNmU0lrV1Y0V0U/edit
Also we reported that there was no maintainer for target-openrisc/ in
MAINTAINERS file, do you want to put yourself there so that you are
CC'ed on patches?
Here's a pointer to the latest refactoring that partially affects or32:
http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg05354.html
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Regards,
Jia
Re: [Qemu-devel] [PATCH] exec: Remove unused global variable phys_ram_fd
Am 05.07.2013 19:07, schrieb Stefan Weil: It seems to be unused since several years (commit be995c27640a82c7056b6f53d02ec823570114e5 in 2006). Signed-off-by: Stefan Weil s...@weilnetz.de Confirmed unused, Reviewed-by: Andreas Färber afaer...@suse.de Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH qom-cpu] target-ppc: Change LOG_MMU_STATE() argument to CPUState
Am 03.07.2013 00:54, schrieb Andreas Färber: Choose CPUState rather than PowerPCCPU since doing a CPU() cast on the macro argument would hide type mismatches. Signed-off-by: Andreas Färber afaer...@suse.de --- target-ppc/mmu-hash32.c | 4 ++-- target-ppc/mmu-hash64.c | 4 ++-- target-ppc/mmu_helper.c | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) Inserted into qom-cpu: https://github.com/afaerber/qemu-cpu/commits/qom-cpu Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH qom-cpu 0/3] target-i386: log_cpu_state() cleanups
Am 03.07.2013 20:42, schrieb Andreas Färber: Hello, As a follow-up to my CPUState part 11 series changing log_cpu_state[_mask]() argument to CPUState, these patches propagate X86CPU argument where possible. This is in response to rth asking about type/placement of variables. [...] Andreas Färber (3): target-i386: Change LOG_PCALL_STATE() argument to CPUState target-i386: Change do_interrupt_all() argument to X86CPU target-i386: Change do_smm_enter() argument to X86CPU Inserted 2-3 before and 1 after log_cpu_state*() commit, adapting commit messages: https://github.com/afaerber/qemu-cpu/commits/qom-cpu Andreas cpu-exec.c | 2 +- target-i386/cpu.h| 2 +- target-i386/seg_helper.c | 19 ++- target-i386/smm_helper.c | 6 +++--- 4 files changed, 15 insertions(+), 14 deletions(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 1/9] linux-user: fix segmentation fault passing with h2g(x) != x
When forwarding a segmentation fault into the guest process, we were passing
the host's address directly into the guest process's signal descriptor.
That obviously confused the guest process, since it didn't know what to make
of the (usually 32-bit truncated) address. Passing in h2g(address) makes the
guest process a lot happier.
This fixes java running in arm-linux-user for me.
Signed-off-by: Alexander Graf ag...@suse.de
---
user-exec.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/user-exec.c b/user-exec.c
index 26cde7c..718c54f 100644
--- a/user-exec.c
+++ b/user-exec.c
@@ -94,6 +94,12 @@ static inline int handle_cpu_signal(uintptr_t pc, unsigned
long address,
return 1;
}
+if (GUEST_BASE) {
+/* Convert forcefully to guest address space, invalid addresses
+ are still valid segv ones */
+address = address - GUEST_BASE;
+}
+
env = current_cpu-env_ptr;
/* see if it is an MMU fault */
ret = cpu_handle_mmu_fault(env, address, is_write, MMU_USER_IDX);
--
1.6.0.2
[Qemu-devel] [PATCH 0/9] linux-user: Wine enablement patch set
Howdy, It's been a while since I've tried to run wine in QEMU's i386 linux-user target, so I figured I'd give it a go again. Obviously I've hit a bunch of obstacles, some of which were old, some of which we only introduced recently. However, with this patch set I am able to successfully run Civilization II in wine on my ARM Chromebook: http://db.tt/AvHJOKSg Beware that this patch set is based on Andreas' qom-cpu branch. If you just want a working git tree to try this out on, check out: git://github.com/agraf/qemu.git linux-user-x86-tls-v1 Alex Alexander Graf (9): linux-user: fix segmentation fault passing with h2g(x) != x linux-user: Add is_write segfault check for ARM hosts linux-user: Don't reset a new thread's CPU linux-user: Fix sendrecvmsg() with QEMU_GUEST_BASE linux-user: Fix epoll on ARM hosts linux-user: Add i386 TLS setter linux-user: Enable NPTL for i386 linux-user: Default to 64k guest base linux-user: Unlock mmap_lock when resuming guest from page_unprotect configure|1 + linux-user/i386/target_cpu.h | 12 ++-- linux-user/main.c|6 +++--- linux-user/syscall.c |4 ++-- linux-user/syscall_defs.h|7 +-- translate-all.c | 10 +++--- user-exec.c |9 +++-- 7 files changed, 35 insertions(+), 14 deletions(-)
[Qemu-devel] [PATCH 3/9] linux-user: Don't reset a new thread's CPU
When we create a new thread, there is no reason to reset it. I'm fairly sure the code has mostly been left in there because nobody understood why it was there in the first place. Remove the reset. A new thread's kernel sided state should be identical to the old one's. Signed-off-by: Alexander Graf ag...@suse.de --- linux-user/syscall.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 433d3ba..d0408a2 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -4234,7 +4234,7 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp, init_task_state(ts); /* we create a new CPU instance. */ new_env = cpu_copy(env); -#if defined(TARGET_I386) || defined(TARGET_SPARC) || defined(TARGET_PPC) +#if defined(TARGET_SPARC) || defined(TARGET_PPC) cpu_reset(ENV_GET_CPU(new_env)); #endif /* Init regs that differ from the parent. */ -- 1.6.0.2
[Qemu-devel] [PATCH 5/9] linux-user: Fix epoll on ARM hosts
The epoll emulation uses data structures without packing them, so the
compiler might choose to add padding inside.
This patch makes the most offending one (target_epoll_event) a packed
structure to make sure we don't pad it by accident. ARM would pad it,
so declare the padding mandatory for ARM targets.
This fixes i386-on-ARM epoll emulation for me.
Signed-off-by: Alexander Graf ag...@suse.de
---
linux-user/syscall_defs.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 8b06a19..fbc3cac 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2434,8 +2434,11 @@ typedef union target_epoll_data {
struct target_epoll_event {
uint32_t events;
+#ifdef TARGET_ARM
+uint32_t __pad;
+#endif
target_epoll_data_t data;
-};
+} QEMU_PACKED;
#endif
struct target_rlimit64 {
uint64_t rlim_cur;
--
1.6.0.2
[Qemu-devel] [PATCH 7/9] linux-user: Enable NPTL for i386
The i386 target is now able to properly handle NPTL. Enable it. Signed-off-by: Alexander Graf ag...@suse.de --- configure |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure b/configure index 0e0adde..61f2770 100755 --- a/configure +++ b/configure @@ -4156,6 +4156,7 @@ TARGET_ABI_DIR= case $target_name in i386) +target_nptl=yes ;; x86_64) TARGET_BASE_ARCH=i386 -- 1.6.0.2
[Qemu-devel] [PATCH 2/9] linux-user: Add is_write segfault check for ARM hosts
When we get a segmentation fault we check whether the fault was a write. If it was a write, it might be a fault because we tried to modify a code region. This logic does not work on ARM hosts, because they don't evaluate whether a segementation fault is due to a write. Instead they always declare it a read. So self modifying code fails with a segmentation fault whenever it tries to modify itself. Add the is_write evaluation based on what the kernel tells us as fault reason. Signed-off-by: Alexander Graf ag...@suse.de --- user-exec.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/user-exec.c b/user-exec.c index 718c54f..bbeb0dd 100644 --- a/user-exec.c +++ b/user-exec.c @@ -448,8 +448,7 @@ int cpu_signal_handler(int host_signum, void *pinfo, #else pc = uc-uc_mcontext.arm_pc; #endif -/* XXX: compute is_write */ -is_write = 0; +is_write = (uc-uc_mcontext.error_code 0x800) ? 1 : 0; return handle_cpu_signal(pc, (unsigned long)info-si_addr, is_write, uc-uc_sigmask, puc); -- 1.6.0.2
[Qemu-devel] [PATCH 9/9] linux-user: Unlock mmap_lock when resuming guest from page_unprotect
The page_unprotect() function is running everything locked. Before every
potential exit path of the function mmap_unlock() gets called to make sure
we don't leak the lock.
However, the function calls tb_invalidate_phys_page() which again can
exit a signal through longjmp, leaving our mmap_unlock() attempts in vain.
Add a hint to tb_invalidate_phys_page() that we need to unlock before we
can leave back into guest context, so that we don't leak the lock.
This fixes 16-bit i386 wine programs running in linux-user for me.
Signed-off-by: Alexander Graf ag...@suse.de
---
translate-all.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/translate-all.c b/translate-all.c
index e8683d2..3b5fc7c 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1148,7 +1148,8 @@ void tb_invalidate_phys_page_fast(tb_page_addr_t start,
int len)
#if !defined(CONFIG_SOFTMMU)
static void tb_invalidate_phys_page(tb_page_addr_t addr,
-uintptr_t pc, void *puc)
+uintptr_t pc, void *puc,
+bool locked)
{
TranslationBlock *tb;
PageDesc *p;
@@ -1206,6 +1207,9 @@ static void tb_invalidate_phys_page(tb_page_addr_t addr,
itself */
cpu-current_tb = NULL;
tb_gen_code(env, current_pc, current_cs_base, current_flags, 1);
+if (locked) {
+mmap_unlock();
+}
cpu_resume_from_signal(env, puc);
}
#endif
@@ -1723,7 +1727,7 @@ void page_set_flags(target_ulong start, target_ulong end,
int flags)
if (!(p-flags PAGE_WRITE)
(flags PAGE_WRITE)
p-first_tb) {
-tb_invalidate_phys_page(addr, 0, NULL);
+tb_invalidate_phys_page(addr, 0, NULL, false);
}
p-flags = flags;
}
@@ -1818,7 +1822,7 @@ int page_unprotect(target_ulong address, uintptr_t pc,
void *puc)
/* and since the content will be modified, we must invalidate
the corresponding translated code. */
-tb_invalidate_phys_page(addr, pc, puc);
+tb_invalidate_phys_page(addr, pc, puc, true);
#ifdef DEBUG_TB_CHECK
tb_invalidate_check(addr);
#endif
--
1.6.0.2
[Qemu-devel] [PATCH 4/9] linux-user: Fix sendrecvmsg() with QEMU_GUEST_BASE
While looking for cmsg entries, we want to compare guest pointers to see whether we're at the end of the passed in array. However, what we really do is we compare our in-use host pointer with the to-be-the-end guest pointer. This comparison is obviously bogus. Change the comparison to compare guest pointer with guest pointer. Signed-off-by: Alexander Graf ag...@suse.de --- linux-user/syscall_defs.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h index 92c01a9..8b06a19 100644 --- a/linux-user/syscall_defs.h +++ b/linux-user/syscall_defs.h @@ -214,7 +214,7 @@ __target_cmsg_nxthdr (struct target_msghdr *__mhdr, struct target_cmsghdr *__cms __ptr = (struct target_cmsghdr *)((unsigned char *) __cmsg + TARGET_CMSG_ALIGN (tswapal(__cmsg-cmsg_len))); - if ((unsigned long)((char *)(__ptr+1) - (char *)(size_t)tswapal(__mhdr-msg_control)) + if ((unsigned long)((char *)(h2g(__ptr+1)) - (char *)(size_t)tswapal(__mhdr-msg_control)) tswapal(__mhdr-msg_controllen)) /* No more entries. */ return (struct target_cmsghdr *)0; -- 1.6.0.2
[Qemu-devel] [PATCH 8/9] linux-user: Default to 64k guest base
Most kernels these days have protection code in place to forbid user space
to access low memory. The barrier varies between architectures though.
For this purpose we have the guest base option that allows us to offset
guest visible memory from host memory, so that the guest process thinks
it can access lower memory than it really can access.
Set the default for the guest base to 64k which should be good enough on
any host system.
This fixes running i386 wine on ARM for me.
Signed-off-by: Alexander Graf ag...@suse.de
---
linux-user/main.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 7f15d3d..a246cff 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -45,8 +45,8 @@ envlist_t *envlist;
const char *cpu_model;
unsigned long mmap_min_addr;
#if defined(CONFIG_USE_GUEST_BASE)
-unsigned long guest_base;
-int have_guest_base;
+unsigned long guest_base = 64 * 1024;
+int have_guest_base = 1;
#if (TARGET_LONG_BITS == 32) (HOST_LONG_BITS == 64)
/*
* When running 32-on-64 we should make sure we can fit all of the possible
@@ -3294,7 +3294,7 @@ static void handle_arg_cpu(const char *arg)
static void handle_arg_guest_base(const char *arg)
{
guest_base = strtol(arg, NULL, 0);
-have_guest_base = 1;
+have_guest_base = guest_base ? 1 : 0;
}
static void handle_arg_reserved_va(const char *arg)
--
1.6.0.2
[Qemu-devel] [PATCH 6/9] linux-user: Add i386 TLS setter
We can easily set the TLS on i386. Add code to do so.
Signed-off-by: Alexander Graf ag...@suse.de
---
linux-user/i386/target_cpu.h | 12 ++--
linux-user/syscall.c |2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/linux-user/i386/target_cpu.h b/linux-user/i386/target_cpu.h
index abcac79..1170d84 100644
--- a/linux-user/i386/target_cpu.h
+++ b/linux-user/i386/target_cpu.h
@@ -28,6 +28,14 @@ static inline void cpu_clone_regs(CPUX86State *env,
target_ulong newsp)
env-regs[R_EAX] = 0;
}
-/* TODO: need to implement cpu_set_tls() */
+#if defined(TARGET_ABI32)
+abi_long do_set_thread_area(CPUX86State *env, abi_ulong ptr);
-#endif
+static inline void cpu_set_tls(CPUX86State *env, target_ulong newtls)
+{
+do_set_thread_area(env, newtls);
+cpu_x86_load_seg(env, R_GS, env-segs[R_GS].selector);
+}
+#endif /* defined(TARGET_ABI32) */
+
+#endif /* !defined(TARGET_CPU_H) */
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d0408a2..1996cfb 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -3976,7 +3976,7 @@ static abi_long do_modify_ldt(CPUX86State *env, int func,
abi_ulong ptr,
}
#if defined(TARGET_I386) defined(TARGET_ABI32)
-static abi_long do_set_thread_area(CPUX86State *env, abi_ulong ptr)
+abi_long do_set_thread_area(CPUX86State *env, abi_ulong ptr)
{
uint64_t *gdt_table = g2h(env-gdt.base);
struct target_modify_ldt_ldt_s ldt_info;
--
1.6.0.2
Re: [Qemu-devel] [PATCH RFC qom-cpu 09/41] gdbstub: Replace two find_cpu() with qemu_get_cpu()
Am 01.07.2013 19:14, schrieb Richard Henderson: On 06/29/2013 01:01 PM, Andreas Färber wrote: Since commit cb446ecab714b2444a270be209e0533bcd2ee534 (kvm: Change cpu_synchronize_state() argument to CPUState), one was no longer accessing CPUArchState, the other was just checking existence. Signed-off-by: Andreas Färber afaer...@suse.de --- gdbstub.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Richard Henderson r...@twiddle.net Thanks, applied to qom-cpu: https://github.com/afaerber/qemu-cpu/commits/qom-cpu Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 2/2] target-alpha: Copy implver to DisasContext
Am 01.07.2013 22:19, schrieb Richard Henderson: Which allows removing env from DisasContext. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Andreas Färber afaer...@suse.de I notice that implver is only ever assigned in CPUs' instance_init, so a candidate for moving to AlphaCPUClass as a follow-up. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH V2 2/2] Add tests for sync modes 'TOP' and 'NONE'
This patch adds tests for sync modes top and none.
Signed-off-by: Ian Main im...@redhat.com
---
tests/qemu-iotests/055| 67 ---
tests/qemu-iotests/055.out| 4 +--
tests/qemu-iotests/group | 2 +-
tests/qemu-iotests/iotests.py | 5
4 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iotests/055 b/tests/qemu-iotests/055
index c66f8db..06d1f77 100755
--- a/tests/qemu-iotests/055
+++ b/tests/qemu-iotests/055
@@ -23,8 +23,9 @@
import time
import os
import iotests
-from iotests import qemu_img, qemu_io
+from iotests import qemu_img, qemu_io, create_image
+backing_img = os.path.join(iotests.test_dir, 'backing.img')
test_img = os.path.join(iotests.test_dir, 'test.img')
target_img = os.path.join(iotests.test_dir, 'target.img')
@@ -34,7 +35,7 @@ class TestSingleDrive(iotests.QMPTestCase):
def setUp(self):
# Write data to the image so we can compare later
qemu_img('create', '-f', iotests.imgfmt, test_img,
str(TestSingleDrive.image_len))
-qemu_io('-c', 'write -P0x5d 0 64k', test_img)
+qemu_io('-c', 'write -P0x41 0 512', test_img)
qemu_io('-c', 'write -P0xd5 1M 32k', test_img)
qemu_io('-c', 'write -P0xdc 32M 124k', test_img)
qemu_io('-c', 'write -P0xdc 67043328 64k', test_img)
@@ -60,6 +61,22 @@ class TestSingleDrive(iotests.QMPTestCase):
event = self.cancel_and_wait()
self.assert_qmp(event, 'data/type', 'backup')
+def test_cancel_sync_none(self):
+self.assert_no_active_block_jobs()
+
+result = self.vm.qmp('drive-backup', device='drive0',
+ sync='none', format='raw', target=target_img)
+self.assert_qmp(result, 'return', {})
+time.sleep(1)
+self.vm.hmp_qemu_io('drive0', 'write -P0x5e 0 512')
+self.vm.hmp_qemu_io('drive0', 'aio_flush')
+time.sleep(1)
+# Verify that the original contents exist in the target image.
+self.assertEqual(-1, qemu_io('-c', 'read -P0x41 0 512',
target_img).find(verification failed))
+
+event = self.cancel_and_wait()
+self.assert_qmp(event, 'data/type', 'backup')
+
def test_pause(self):
self.assert_no_active_block_jobs()
@@ -102,6 +119,47 @@ class TestSingleDrive(iotests.QMPTestCase):
target=target_img, sync='full')
self.assert_qmp(result, 'error/class', 'DeviceNotFound')
+class TestSyncModeTop(iotests.QMPTestCase):
+image_len = 2 * 1024 * 1024 # MB
+
+def setUp(self):
+create_image(backing_img, TestSyncModeTop.image_len)
+qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, test_img)
+qemu_io('-c', 'write -P0x5d 0 64k', test_img)
+qemu_io('-c', 'write -P0xd5 1M 32k', test_img)
+qemu_io('-c', 'write -P0xdc 32M 124k', test_img)
+self.vm = iotests.VM().add_drive(test_img)
+self.vm.launch()
+
+def tearDown(self):
+self.vm.shutdown()
+os.remove(test_img)
+os.remove(backing_img)
+try:
+os.remove(target_img)
+except OSError:
+pass
+
+def test_complete_top(self):
+self.assert_no_active_block_jobs()
+result = self.vm.qmp('drive-backup', device='drive0', sync='top',
+ target=target_img)
+self.assert_qmp(result, 'return', {})
+
+# Custom completed check as we are not copying all data.
+completed = False
+while not completed:
+for event in self.vm.get_qmp_events(wait=True):
+if event['event'] == 'BLOCK_JOB_COMPLETED':
+self.assert_qmp(event, 'data/device', 'drive0')
+self.assert_qmp_absent(event, 'data/error')
+completed = True
+
+self.assert_no_active_block_jobs()
+self.vm.shutdown()
+self.assertTrue(iotests.compare_images(test_img, target_img),
+'target image does not match source after backup')
+
class TestSetSpeed(iotests.QMPTestCase):
image_len = 80 * 1024 * 1024 # MB
@@ -127,7 +185,8 @@ class TestSetSpeed(iotests.QMPTestCase):
self.assert_qmp(result, 'return[0]/device', 'drive0')
self.assert_qmp(result, 'return[0]/speed', 0)
-result = self.vm.qmp('block-job-set-speed', device='drive0', speed=8 *
1024 * 1024)
+result = self.vm.qmp('block-job-set-speed', device='drive0',
+ speed=8 * 1024 * 1024)
self.assert_qmp(result, 'return', {})
# Ensure the speed we set was accepted
@@ -285,4 +344,4 @@ class TestSingleTransaction(iotests.QMPTestCase):
self.assert_no_active_block_jobs()
if __name__ == '__main__':
-iotests.main(supported_fmts=['raw', 'qcow2'])
+iotests.main(supported_fmts=['qcow2', 'qed'])
diff --git a/tests/qemu-iotests/055.out b/tests/qemu-iotests/055.out
index
[Qemu-devel] [PATCH V2 1/2] Implement sync modes for drive-backup.
This patch adds sync-modes to the drive-backup interface and
implements the FULL, NONE and TOP modes of synchronization.
FULL performs as before copying the entire contents of the drive
while preserving the point-in-time using CoW.
NONE only copies new writes to the target drive.
TOP copies changes to the topmost drive image and preserves the
point-in-time using CoW.
Signed-off-by: Ian Main im...@redhat.com
---
block/backup.c| 90 +++
blockdev.c| 25 -
include/block/block_int.h | 4 ++-
qapi-schema.json | 4 +++
qmp-commands.hx | 1 +
5 files changed, 85 insertions(+), 39 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 16105d4..e72a5af 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -37,6 +37,7 @@ typedef struct CowRequest {
typedef struct BackupBlockJob {
BlockJob common;
BlockDriverState *target;
+MirrorSyncMode sync_mode;
RateLimit limit;
BlockdevOnError on_source_error;
BlockdevOnError on_target_error;
@@ -247,40 +248,68 @@ static void coroutine_fn backup_run(void *opaque)
bdrv_add_before_write_notifier(bs, before_write);
-for (; start end; start++) {
-bool error_is_read;
-
-if (block_job_is_cancelled(job-common)) {
-break;
+if (job-sync_mode == MIRROR_SYNC_MODE_NONE) {
+while (!block_job_is_cancelled(job-common)) {
+/* Yield until the job is cancelled. We just let our before_write
+ * notify callback service CoW requests. */
+job-common.busy = false;
+qemu_coroutine_yield();
+job-common.busy = true;
}
+} else {
+/* Both FULL and TOP SYNC_MODE's require copying.. */
+for (; start end; start++) {
+bool error_is_read;
-/* we need to yield so that qemu_aio_flush() returns.
- * (without, VM does not reboot)
- */
-if (job-common.speed) {
-uint64_t delay_ns = ratelimit_calculate_delay(
-job-limit, job-sectors_read);
-job-sectors_read = 0;
-block_job_sleep_ns(job-common, rt_clock, delay_ns);
-} else {
-block_job_sleep_ns(job-common, rt_clock, 0);
-}
+if (block_job_is_cancelled(job-common)) {
+break;
+}
-if (block_job_is_cancelled(job-common)) {
-break;
-}
+/* we need to yield so that qemu_aio_flush() returns.
+ * (without, VM does not reboot)
+ */
+if (job-common.speed) {
+uint64_t delay_ns = ratelimit_calculate_delay(
+job-limit, job-sectors_read);
+job-sectors_read = 0;
+block_job_sleep_ns(job-common, rt_clock, delay_ns);
+} else {
+block_job_sleep_ns(job-common, rt_clock, 0);
+}
-ret = backup_do_cow(bs, start * BACKUP_SECTORS_PER_CLUSTER,
-BACKUP_SECTORS_PER_CLUSTER, error_is_read);
-if (ret 0) {
-/* Depending on error action, fail now or retry cluster */
-BlockErrorAction action =
-backup_error_action(job, error_is_read, -ret);
-if (action == BDRV_ACTION_REPORT) {
+if (block_job_is_cancelled(job-common)) {
break;
-} else {
-start--;
-continue;
+}
+
+if (job-sync_mode == MIRROR_SYNC_MODE_TOP) {
+int n, alloced;
+
+/* Check to see if these blocks are already in the backing
file. */
+
+alloced =
+bdrv_co_is_allocated(bs, start *
BACKUP_SECTORS_PER_CLUSTER,
+ BACKUP_SECTORS_PER_CLUSTER, n);
+/* The above call returns true if the given sector is in the
+ * topmost image. If that is the case then we must copy it as
+ * it has been modified from the original backing file.
+ * Otherwise we skip it. */
+if (alloced == 0) {
+continue;
+}
+}
+/* FULL sync mode we copy the whole drive. */
+ret = backup_do_cow(bs, start * BACKUP_SECTORS_PER_CLUSTER,
+BACKUP_SECTORS_PER_CLUSTER, error_is_read);
+if (ret 0) {
+/* Depending on error action, fail now or retry cluster */
+BlockErrorAction action =
+backup_error_action(job, error_is_read, -ret);
+if (action == BDRV_ACTION_REPORT) {
+break;
+} else {
+start--;
+continue;
+}
}
}
}
@@ -300,7 +329,7 @@ static void coroutine_fn backup_run(void *opaque)
}
void
[Qemu-devel] [PATCH V2 0/2] Implement sync modes for drive-backup.
This patch adds sync modes on top of the work that Stefan Hajnoczi has done. These patches apply on kevin/block with '[PATCH] block: add drive_backup HMP command' also applied. Hopefully all is in order as this is my first QEMU patch. Many thanks to Stephan and Fam Zheng for their help. V2: - No longer poll, instead use qemu_coroutine_yield(). - Use bdrv_co_is_allocated(). - Much better SYNC_MODE_NONE test. Ian Main (2): Implement sync modes for drive-backup. Add tests for sync modes 'TOP' and 'NONE' block/backup.c| 90 --- blockdev.c| 25 include/block/block_int.h | 4 +- qapi-schema.json | 4 ++ qmp-commands.hx | 1 + tests/qemu-iotests/055| 67 ++-- tests/qemu-iotests/055.out| 4 +- tests/qemu-iotests/group | 2 +- tests/qemu-iotests/iotests.py | 5 +++ 9 files changed, 156 insertions(+), 46 deletions(-) -- 1.8.1.4
Re: [Qemu-devel] [PATCH V2 0/2] Implement sync modes for drive-backup.
On Fri, Jul 05, 2013 at 06:35:26PM -0700, Ian Main wrote: This patch adds sync modes on top of the work that Stefan Hajnoczi has done. These patches apply on kevin/block with '[PATCH] block: add drive_backup HMP command' also applied. Hopefully all is in order as this is my first QEMU patch. Many thanks to Stephan and Fam Zheng for their help. V2: - No longer poll, instead use qemu_coroutine_yield(). - Use bdrv_co_is_allocated(). - Much better SYNC_MODE_NONE test. FYI I'll be off camping for all next week so I won't get back to you until the following week. Thanks in advance for any reviews! Ian
Re: [Qemu-devel] [PATCH 0/2] target-alpha prep work for qom cpu changes
Am 01.07.2013 22:19, schrieb Richard Henderson: As discussed in the QOM thread. Thanks, applying to qom-cpu-next to rebase qom-cpu-11: https://github.com/afaerber/qemu-cpu/commits/qom-cpu-next Andreas Richard Henderson (2): target-alpha: Copy singlestep_enabled to DisasContext target-alpha: Copy implver to DisasContext target-alpha/translate.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
