[Bug 1921444] Re: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest
Alex, thanks for you response. I tried to create guest with multiple root ports, but qemu report error: # qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/hao/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:0d:e4:ab -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper -cpu host -machine q35 -device pcie-root-port,id=root1 -device pcie-root-port,id=root2 -daemonize qemu-system-x86_64: -device pcie-root-port,id=root2: Can't add chassis slot, error -16 Is the command wrong? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921444 Title: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest Status in QEMU: New Bug description: KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git branch: next, commit: 4a98623d Qemu: https://git.qemu.org/git/qemu.git branch: master, commit: 9e2e9fe3 Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add. If guest chipset is legacy i440fx, the 2 device can be added successfully. 1. Enable VT-d in BIOS 2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel 3. Bind 2 device to vfio-pci echo :b1:00.0 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id echo :b1:00.1 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 4. create guest with Q35 chipset: qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize 5. hot add the 1st device to guest successfully in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1" 6. hot add the 2nd device to guest in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1" The 2nd device doesn't be added in guest, and the 1st device is removed from guest. Guest partial log: [ 110.452272] pcieport :00:04.0: pciehp: Slot(0): Attention button pressed [ 110.453314] pcieport :00:04.0: pciehp: Slot(0) Powering on due to button press [ 110.454156] pcieport :00:04.0: pciehp: Slot(0): Card present [ 110.454792] pcieport :00:04.0: pciehp: Slot(0): Link Up [ 110.580927] pci :01:00.0: [8086:1572] type 00 class 0x02 [ 110.582560] pci :01:00.0: reg 0x10: [mem 0x-0x007f 64bit pref] [ 110.583453] pci :01:00.0: reg 0x1c: [mem 0x-0x7fff 64bit pref] [ 110.584278] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref] [ 110.585051] pci :01:00.0: Max Payload Size set to 128 (was 512, max 2048) [ 110.586621] pci :01:00.0: PME# supported from D0 D3hot D3cold [ 110.588140] pci :01:00.0: BAR 0: no space for [mem size 0x0080 64bit pref] [ 110.588954] pci :01:00.0: BAR 0: failed to assign [mem size 0x0080 64bit pref] [ 110.589797] pci :01:00.0: BAR 6: assigned [mem 0xfe80-0xfe87 pref] [ 110.590703] pci :01:00.0: BAR 3: assigned [mem 0xfe00-0xfe007fff 64bit pref] [ 110.592085] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.592755] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.594403] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.595847] pcieport :00:04.0: bridge window [mem 0xfe00-0xfe1f 64bit pref] [ 110.597867] PCI: No. 2 try to assign unassigned res [ 110.597870] release child resource [mem 0xfe00-0xfe007fff 64bit pref] [ 110.597871] pcieport :00:04.0: resource 15 [mem 0xfe00-0xfe1f 64bit pref] released [ 110.598881] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.600789] pcieport :00:04.0: BAR 15: assigned [mem 0x18000-0x180bf 64bit pref] [ 110.601731] pci :01:00.0: BAR 0: assigned [mem 0x18000-0x1807f 64bit pref] [ 110.602849] pci :01:00.0: BAR 3: assigned [mem 0x18080-0x180807fff 64bit pref] [ 110.604069] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.604941] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.606237] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.607401] pcieport :00:04.0: bridge window [mem 0x18000-0x180bf 64bit pref] [ 110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 110.655314] i40e :01:00.0: enabling device (0140 -> 0142) [ 110.672396] i40e :01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008] [ 110.750054] i40e
[Bug 1921444] Re: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest
** Attachment added: "guest_dmesg.log" https://bugs.launchpad.net/qemu/+bug/1921444/+attachment/5481022/+files/guest_dmesg.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921444 Title: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest Status in QEMU: New Bug description: KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git branch: next, commit: 4a98623d Qemu: https://git.qemu.org/git/qemu.git branch: master, commit: 9e2e9fe3 Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add. If guest chipset is legacy i440fx, the 2 device can be added successfully. 1. Enable VT-d in BIOS 2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel 3. Bind 2 device to vfio-pci echo :b1:00.0 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id echo :b1:00.1 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 4. create guest with Q35 chipset: qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize 5. hot add the 1st device to guest successfully in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1" 6. hot add the 2nd device to guest in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1" The 2nd device doesn't be added in guest, and the 1st device is removed from guest. Guest partial log: [ 110.452272] pcieport :00:04.0: pciehp: Slot(0): Attention button pressed [ 110.453314] pcieport :00:04.0: pciehp: Slot(0) Powering on due to button press [ 110.454156] pcieport :00:04.0: pciehp: Slot(0): Card present [ 110.454792] pcieport :00:04.0: pciehp: Slot(0): Link Up [ 110.580927] pci :01:00.0: [8086:1572] type 00 class 0x02 [ 110.582560] pci :01:00.0: reg 0x10: [mem 0x-0x007f 64bit pref] [ 110.583453] pci :01:00.0: reg 0x1c: [mem 0x-0x7fff 64bit pref] [ 110.584278] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref] [ 110.585051] pci :01:00.0: Max Payload Size set to 128 (was 512, max 2048) [ 110.586621] pci :01:00.0: PME# supported from D0 D3hot D3cold [ 110.588140] pci :01:00.0: BAR 0: no space for [mem size 0x0080 64bit pref] [ 110.588954] pci :01:00.0: BAR 0: failed to assign [mem size 0x0080 64bit pref] [ 110.589797] pci :01:00.0: BAR 6: assigned [mem 0xfe80-0xfe87 pref] [ 110.590703] pci :01:00.0: BAR 3: assigned [mem 0xfe00-0xfe007fff 64bit pref] [ 110.592085] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.592755] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.594403] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.595847] pcieport :00:04.0: bridge window [mem 0xfe00-0xfe1f 64bit pref] [ 110.597867] PCI: No. 2 try to assign unassigned res [ 110.597870] release child resource [mem 0xfe00-0xfe007fff 64bit pref] [ 110.597871] pcieport :00:04.0: resource 15 [mem 0xfe00-0xfe1f 64bit pref] released [ 110.598881] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.600789] pcieport :00:04.0: BAR 15: assigned [mem 0x18000-0x180bf 64bit pref] [ 110.601731] pci :01:00.0: BAR 0: assigned [mem 0x18000-0x1807f 64bit pref] [ 110.602849] pci :01:00.0: BAR 3: assigned [mem 0x18080-0x180807fff 64bit pref] [ 110.604069] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.604941] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.606237] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.607401] pcieport :00:04.0: bridge window [mem 0x18000-0x180bf 64bit pref] [ 110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 110.655314] i40e :01:00.0: enabling device (0140 -> 0142) [ 110.672396] i40e :01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008] [ 110.750054] i40e :01:00.0: MAC address: 3c:fd:fe:c0:59:98 [ 110.751792] i40e :01:00.0: FW LLDP is enabled [ 110.764644] i40e :01:00.0 eth1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None [ 110.779390] i40e :01:00.0: PCI-Express: Speed 8.0GT/s Width x8 [ 110.789841] i40e :01:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 4 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA [ 111.817553] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes
[Bug 1921444] [NEW] Q35 doesn't support to hot add the 2nd PCIe device to KVM guest
Public bug reported: KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git branch: next, commit: 4a98623d Qemu: https://git.qemu.org/git/qemu.git branch: master, commit: 9e2e9fe3 Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add. If guest chipset is legacy i440fx, the 2 device can be added successfully. 1. Enable VT-d in BIOS 2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel 3. Bind 2 device to vfio-pci echo :b1:00.0 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id echo :b1:00.1 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 4. create guest with Q35 chipset: qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize 5. hot add the 1st device to guest successfully in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1" 6. hot add the 2nd device to guest in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1" The 2nd device doesn't be added in guest, and the 1st device is removed from guest. Guest partial log: [ 110.452272] pcieport :00:04.0: pciehp: Slot(0): Attention button pressed [ 110.453314] pcieport :00:04.0: pciehp: Slot(0) Powering on due to button press [ 110.454156] pcieport :00:04.0: pciehp: Slot(0): Card present [ 110.454792] pcieport :00:04.0: pciehp: Slot(0): Link Up [ 110.580927] pci :01:00.0: [8086:1572] type 00 class 0x02 [ 110.582560] pci :01:00.0: reg 0x10: [mem 0x-0x007f 64bit pref] [ 110.583453] pci :01:00.0: reg 0x1c: [mem 0x-0x7fff 64bit pref] [ 110.584278] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref] [ 110.585051] pci :01:00.0: Max Payload Size set to 128 (was 512, max 2048) [ 110.586621] pci :01:00.0: PME# supported from D0 D3hot D3cold [ 110.588140] pci :01:00.0: BAR 0: no space for [mem size 0x0080 64bit pref] [ 110.588954] pci :01:00.0: BAR 0: failed to assign [mem size 0x0080 64bit pref] [ 110.589797] pci :01:00.0: BAR 6: assigned [mem 0xfe80-0xfe87 pref] [ 110.590703] pci :01:00.0: BAR 3: assigned [mem 0xfe00-0xfe007fff 64bit pref] [ 110.592085] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.592755] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.594403] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.595847] pcieport :00:04.0: bridge window [mem 0xfe00-0xfe1f 64bit pref] [ 110.597867] PCI: No. 2 try to assign unassigned res [ 110.597870] release child resource [mem 0xfe00-0xfe007fff 64bit pref] [ 110.597871] pcieport :00:04.0: resource 15 [mem 0xfe00-0xfe1f 64bit pref] released [ 110.598881] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.600789] pcieport :00:04.0: BAR 15: assigned [mem 0x18000-0x180bf 64bit pref] [ 110.601731] pci :01:00.0: BAR 0: assigned [mem 0x18000-0x1807f 64bit pref] [ 110.602849] pci :01:00.0: BAR 3: assigned [mem 0x18080-0x180807fff 64bit pref] [ 110.604069] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.604941] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.606237] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.607401] pcieport :00:04.0: bridge window [mem 0x18000-0x180bf 64bit pref] [ 110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 110.655314] i40e :01:00.0: enabling device (0140 -> 0142) [ 110.672396] i40e :01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008] [ 110.750054] i40e :01:00.0: MAC address: 3c:fd:fe:c0:59:98 [ 110.751792] i40e :01:00.0: FW LLDP is enabled [ 110.764644] i40e :01:00.0 eth1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None [ 110.779390] i40e :01:00.0: PCI-Express: Speed 8.0GT/s Width x8 [ 110.789841] i40e :01:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 4 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA [ 111.817553] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 205.130288] pcieport :00:04.0: pciehp: Slot(0): Attention button pressed [ 205.131743] pcieport :00:04.0: pciehp: Slot(0): Powering off due to button press [ 205.133233] pcieport :00:04.0: pciehp: Slot(0): Card not present [ 205.135728] i40e :01:00.0: i40e_ptp_stop: removed PHC on eth1 ** 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.
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
> -Original Message- > From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu- > devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd > Hoffmann > Sent: Tuesday, January 12, 2016 6:25 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Lars Kurth <lars.ku...@citrix.com>; xen-de...@lists.xensource.com; Stefano > Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.kurth@gmail.com>; Michael S. Tsirkin <m...@redhat.com>; qemu- > de...@nongnu.org; Cao jin <caoj.f...@cn.fujitsu.com>; Stefano Stabellini > <stefano.stabell...@citrix.com> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote: > > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't > boot up with IGD. > > There is another bug, using pci_default_write_config() doesn't fly as this > checks > writes against wmask and the registers in question are not whitelisted ... > > I've just rebased my igd patch series which (among other stuff) fixes that > bug: > https://www.kraxel.org/cgit/qemu/log/?h=work/igd > git://git.kraxel.org/qemu work/igd > > Can you give it a spin? The issue persist on this branch of tree (commit 1a0d06ce6), the VM kernel log attached in another mail while answered the following question. > > Also: what does "can't boot up" mean exactly? Guest doesn't boot at all? > Guest > boots, but igd/console/Xorg doesn't work? In case of the > latter: Any chance to login via network and get a kernel log? > > thanks, > Gerd >
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
> -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Monday, January 11, 2016 6:46 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.kurth@gmail.com>; Lars Kurth <lars.ku...@citrix.com>; Cao jin > <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; Stefano Stabellini > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. Tsirkin > <m...@redhat.com> > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > On Mon, 11 Jan 2016, Hao, Xudong wrote: > > Stefano, > > > > Patch http://marc.info/?l=qemu-devel=145137863501079 don't works for > qemu at all, some conflict when git apply. > > Patch http://marc.info/?l=qemu-devel=145137863501079 is based on > patch http://marc.info/?l=qemu-devel=145172165010604, right? > > > > I can boot up Linux VM with IGD pass-through with latest qemu (without any > additional patch), guest run 3D "nexuiz" and get 180fps. > > Very interesting, thanks for testing. > The Linux VM's kernel is 3.18. > > > Will try the two patch together later. > > That would be useful > With the two patch, Linux VM (with 3.18) boot up successfully. RHEL7.2(default kernel 3.10) and Windows8.1 VM boot up fail with IGD pass-through. The result is same w/o these two patches. > > > > -Original Message- > > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > > > Sent: Friday, January 8, 2016 7:57 PM > > > To: Hao, Xudong <xudong@intel.com> > > > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars > > > Kurth <lars.kurth@gmail.com>; Lars Kurth > > > <lars.ku...@citrix.com>; Cao jin <caoj.f...@cn.fujitsu.com>; > > > xen-de...@lists.xensource.com; Stefano Stabellini > > > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. > > > Tsirkin <m...@redhat.com> > > > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > > > to realize() > > > > > > Since you are at it, could you please let me know how well igd > > > passthrough works without this bugfix: > > > > > > http://marc.info/?l=qemu-devel=145172165010604 > > > > > > which is about to land in QEMU. I guess it doesn't work at all? > > > > > > I am asking because I would like to know the level of support we > > > need to provide to igd passthrough with the latest QEMU release (2.5). > > > > > > > > > On Thu, 7 Jan 2016, Hao, Xudong wrote: > > > > Sure. I'll test it soon. > > > > > > > > Thanks, > > > > -Xudong > > > > > > > > > -Original Message- > > > > > From: Stefano Stabellini > > > > > [mailto:stefano.stabell...@eu.citrix.com] > > > > > Sent: Wednesday, January 6, 2016 8:18 PM > > > > > To: Lars Kurth <lars.kurth@gmail.com> > > > > > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Hao, > > > > > Xudong <xudong@intel.com>; Lars Kurth > > > > > <lars.ku...@citrix.com>; Cao jin <caoj.f...@cn.fujitsu.com>; > > > > > xen-de...@lists.xensource.com; Stefano Stabellini > > > > > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael > > > > > S. Tsirkin <m...@redhat.com> > > > > > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > > > > > convert to realize() > > > > > > > > > > Hello Xudong, > > > > > > > > > > please test this patch: > > > > > > > > > > http://marc.info/?l=qemu-devel=145137863501079 > > > > > > > > > > with an intel graphic card assigned to a Xen guest. If > > > > > everything still works as expected, please reply with your Tested-by. > > > > > > > > > > Thanks, > > > > > > > > > > Stefano > > > > > > > > > > On Wed, 6 Jan 2016, Lars Kurth wrote: > > > > > > Hi folks, > > > > > > let me introduce you to Xudong from Intel, who is willing to help > > > > > > out. > > > > > > Best Regards > > > > > > Lars > > > > > > > > > > > > > On 4 Jan 2016, at 15:41, Stefano S
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't boot up with IGD. Thanks, -Xudong > -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, January 12, 2016 4:48 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Gerd Hoffmann <kra...@redhat.com>; Stefano Stabellini > <stefano.stabell...@eu.citrix.com>; Lars Kurth <lars.ku...@citrix.com>; xen- > de...@lists.xensource.com; Lars Kurth <lars.kurth@gmail.com>; qemu- > de...@nongnu.org; Cao jin <caoj.f...@cn.fujitsu.com>; Stefano Stabellini > <stefano.stabell...@citrix.com> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > OK - it's possible that this patch > commit 349a3b1cc9023f67f8fa336cb3c4a8f21a4aaaf3 > Author: Cao jin <caoj.f...@cn.fujitsu.com> > Date: Sat Jan 2 16:02:20 2016 +0800 > > igd-passthrough: fix use of host_pci_config_read > > is required for older guests. > This patch just went it - could you test latest master please? > > On Tue, Jan 12, 2016 at 08:41:13AM +, Hao, Xudong wrote: > > Yes, Linux VM update to a 3.18 kernel. > > The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD pass- > through, and Windows can't boot up either. > > > > Thanks, > > -Xudong > > > > > > > -Original Message- > > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > > Sent: Monday, January 11, 2016 6:32 PM > > > To: Hao, Xudong <xudong@intel.com> > > > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars > > > Kurth <lars.ku...@citrix.com>; xen-de...@lists.xensource.com; > > > Michael S. Tsirkin <m...@redhat.com>; Lars Kurth > > > <lars.kurth@gmail.com>; qemu- de...@nongnu.org; Cao jin > > > <caoj.f...@cn.fujitsu.com>; Stefano Stabellini > > > <stefano.stabell...@citrix.com> > > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > > > convert to realize() > > > > > > Hi, > > > > > > > I can boot up Linux VM with IGD pass-through with latest qemu > > > > (without any additional patch), guest run 3D "nexuiz" and get 180fps. > > > > > > That is a pretty recent linux guest I assume? > > > Tried older kernels too, possibly even the old userspace xorg driver? > > > Do windows guest work as well? > > > > > > cheers, > > > Gerd > >
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Yes, Linux VM update to a 3.18 kernel. The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD pass-through, and Windows can't boot up either. Thanks, -Xudong > -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Monday, January 11, 2016 6:32 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.ku...@citrix.com>; xen-de...@lists.xensource.com; Michael S. Tsirkin > <m...@redhat.com>; Lars Kurth <lars.kurth@gmail.com>; qemu- > de...@nongnu.org; Cao jin <caoj.f...@cn.fujitsu.com>; Stefano Stabellini > <stefano.stabell...@citrix.com> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > Hi, > > > I can boot up Linux VM with IGD pass-through with latest qemu (without > > any additional patch), guest run 3D "nexuiz" and get 180fps. > > That is a pretty recent linux guest I assume? > Tried older kernels too, possibly even the old userspace xorg driver? > Do windows guest work as well? > > cheers, > Gerd
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
"can't boot up" means guest doesn't boot at all, guest will stop to booting after adding vga device, detail log in attachment. Thanks, -Xudong > -Original Message- > From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu- > devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd > Hoffmann > Sent: Tuesday, January 12, 2016 6:25 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Lars Kurth <lars.ku...@citrix.com>; xen-de...@lists.xensource.com; Stefano > Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.kurth@gmail.com>; Michael S. Tsirkin <m...@redhat.com>; qemu- > de...@nongnu.org; Cao jin <caoj.f...@cn.fujitsu.com>; Stefano Stabellini > <stefano.stabell...@citrix.com> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote: > > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't > boot up with IGD. > > There is another bug, using pci_default_write_config() doesn't fly as this > checks > writes against wmask and the registers in question are not whitelisted ... > > I've just rebased my igd patch series which (among other stuff) fixes that > bug: > https://www.kraxel.org/cgit/qemu/log/?h=work/igd > git://git.kraxel.org/qemu work/igd > > Can you give it a spin? > > Also: what does "can't boot up" mean exactly? Guest doesn't boot at all? > Guest > boots, but igd/console/Xorg doesn't work? In case of the > latter: Any chance to login via network and get a kernel log? > > thanks, > Gerd > rhel7-default-kernel-boot.log Description: rhel7-default-kernel-boot.log
[Qemu-devel] Recall: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Hao, Xudong would like to recall the message, "[Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()".
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Stefano, Patch http://marc.info/?l=qemu-devel=145137863501079 don't works for qemu at all, some conflict when git apply. Patch http://marc.info/?l=qemu-devel=145137863501079 is based on patch http://marc.info/?l=qemu-devel=145172165010604, right? I can boot up Linux VM with IGD pass-through with latest qemu (without any additional patch), guest run 3D "nexuiz" and get 180fps. Will try the two patch together later. Thanks, -Xudong > -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Friday, January 8, 2016 7:57 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.kurth@gmail.com>; Lars Kurth <lars.ku...@citrix.com>; Cao jin > <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; Stefano Stabellini > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. Tsirkin > <m...@redhat.com> > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > Since you are at it, could you please let me know how well igd passthrough > works without this bugfix: > > http://marc.info/?l=qemu-devel=145172165010604 > > which is about to land in QEMU. I guess it doesn't work at all? > > I am asking because I would like to know the level of support we need to > provide > to igd passthrough with the latest QEMU release (2.5). > > > On Thu, 7 Jan 2016, Hao, Xudong wrote: > > Sure. I'll test it soon. > > > > Thanks, > > -Xudong > > > > > -Original Message- > > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > > > Sent: Wednesday, January 6, 2016 8:18 PM > > > To: Lars Kurth <lars.kurth@gmail.com> > > > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Hao, > > > Xudong <xudong@intel.com>; Lars Kurth <lars.ku...@citrix.com>; > > > Cao jin <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; > > > Stefano Stabellini <stefano.stabell...@citrix.com>; > > > qemu-devel@nongnu.org; Michael S. Tsirkin <m...@redhat.com> > > > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > > > to realize() > > > > > > Hello Xudong, > > > > > > please test this patch: > > > > > > http://marc.info/?l=qemu-devel=145137863501079 > > > > > > with an intel graphic card assigned to a Xen guest. If everything > > > still works as expected, please reply with your Tested-by. > > > > > > Thanks, > > > > > > Stefano > > > > > > On Wed, 6 Jan 2016, Lars Kurth wrote: > > > > Hi folks, > > > > let me introduce you to Xudong from Intel, who is willing to help out. > > > > Best Regards > > > > Lars > > > > > > > > > On 4 Jan 2016, at 15:41, Stefano Stabellini > > > > > <stefano.stabell...@eu.citrix.com> > > > wrote: > > > > > > > > > > On Mon, 4 Jan 2016, Lars Kurth wrote: > > > > >> On 04/01/2016 14:47, "Stefano Stabellini" > > > > >> <stefano.stabell...@eu.citrix.com> wrote: > > > > >> > > > > >>> Unfortunately I don't have a setup to test this either. Maybe > > > > >>> Lars can find out who should be involved on the Intel side on this. > > > > >> > > > > >> I can certainly help to this and get back to you. What exactly > > > > >> are we asking Intel to do? > > > > >> It is not clear to me from this email thread > > > > > > > > > > Tiejun Chen, the author of the Intel graphic card passthrough > > > > > patches for QEMU, seems to have left the company. It would be > > > > > nice if somebody else tested this patch with an intel graphic > > > > > card assigned to a guest VM. > > > > > > > > > > ___ > > > > > Xen-devel mailing list > > > > > xen-de...@lists.xen.org > > > > > http://lists.xen.org/xen-devel > > > > > >
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
I used 6bb9ead762bf749af11ea225fc2a74db1b93c105 yesterday, this version don't include commit 349a3b1cc. Thanks, -Xudong > -Original Message- > From: Cao jin [mailto:caoj.f...@cn.fujitsu.com] > Sent: Tuesday, January 12, 2016 10:01 AM > To: Hao, Xudong <xudong@intel.com>; Stefano Stabellini > <stefano.stabell...@eu.citrix.com> > Cc: Lars Kurth <lars.kurth@gmail.com>; Lars Kurth <lars.ku...@citrix.com>; > xen-de...@lists.xensource.com; Stefano Stabellini > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. Tsirkin > <m...@redhat.com> > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > Hi > > On 01/11/2016 05:53 PM, Hao, Xudong wrote: > > Stefano, > > > > Patch http://marc.info/?l=qemu-devel=145137863501079 don't works for > qemu at all, some conflict when git apply. > > Patch http://marc.info/?l=qemu-devel=145137863501079 is based on > patch http://marc.info/?l=qemu-devel=145172165010604, right? > > > > I can boot up Linux VM with IGD pass-through with latest qemu (without any > additional patch), guest run 3D "nexuiz" and get 180fps. > > > > Because commit: 349a3b1cc is already in the latest qemu(maybe the day before > yesterday?), so I guess that is why latest qemu works well with igd-passthru > and > also the same reason for git apply conflict? > > > Will try the two patch together later. > > > > Thanks, > > -Xudong > > > > > >> -Original Message- > >> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > >> Sent: Friday, January 8, 2016 7:57 PM > >> To: Hao, Xudong <xudong@intel.com> > >> Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > >> <lars.kurth@gmail.com>; Lars Kurth <lars.ku...@citrix.com>; Cao > >> jin <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; > >> Stefano Stabellini <stefano.stabell...@citrix.com>; > >> qemu-devel@nongnu.org; Michael S. Tsirkin <m...@redhat.com> > >> Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > >> to realize() > >> > >> Since you are at it, could you please let me know how well igd > >> passthrough works without this bugfix: > >> > >> http://marc.info/?l=qemu-devel=145172165010604 > >> > >> which is about to land in QEMU. I guess it doesn't work at all? > >> > >> I am asking because I would like to know the level of support we need > >> to provide to igd passthrough with the latest QEMU release (2.5). > >> > >> > >> On Thu, 7 Jan 2016, Hao, Xudong wrote: > >>> Sure. I'll test it soon. > >>> > >>> Thanks, > >>> -Xudong > >>> > >>>> -Original Message- > >>>> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > >>>> Sent: Wednesday, January 6, 2016 8:18 PM > >>>> To: Lars Kurth <lars.kurth@gmail.com> > >>>> Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Hao, > >>>> Xudong <xudong@intel.com>; Lars Kurth <lars.ku...@citrix.com>; > >>>> Cao jin <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; > >>>> Stefano Stabellini <stefano.stabell...@citrix.com>; > >>>> qemu-devel@nongnu.org; Michael S. Tsirkin <m...@redhat.com> > >>>> Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > >>>> to realize() > >>>> > >>>> Hello Xudong, > >>>> > >>>> please test this patch: > >>>> > >>>> http://marc.info/?l=qemu-devel=145137863501079 > >>>> > >>>> with an intel graphic card assigned to a Xen guest. If everything > >>>> still works as expected, please reply with your Tested-by. > >>>> > >>>> Thanks, > >>>> > >>>> Stefano > >>>> > >>>> On Wed, 6 Jan 2016, Lars Kurth wrote: > >>>>> Hi folks, > >>>>> let me introduce you to Xudong from Intel, who is willing to help out. > >>>>> Best Regards > >>>>> Lars > >>>>> > >>>>>> On 4 Jan 2016, at 15:41, Stefano Stabellini > >>>>>> <stefano.stabell...@eu.citrix.com> > >>>> wrote: > >>>>>> > >>>>>> On Mon, 4 Jan 2016, Lars Kurth wrote: > >>>>>>> On 04/01/2016 14:47, "Stefano Stabellini" > >>>>>>> <stefano.stabell...@eu.citrix.com> wrote: > >>>>>>> > >>>>>>>> Unfortunately I don't have a setup to test this either. Maybe > >>>>>>>> Lars can find out who should be involved on the Intel side on this. > >>>>>>> > >>>>>>> I can certainly help to this and get back to you. What exactly > >>>>>>> are we asking Intel to do? > >>>>>>> It is not clear to me from this email thread > >>>>>> > >>>>>> Tiejun Chen, the author of the Intel graphic card passthrough > >>>>>> patches for QEMU, seems to have left the company. It would be > >>>>>> nice if somebody else tested this patch with an intel graphic > >>>>>> card assigned to a guest VM. > >>>>>> > >>>>>> ___ > >>>>>> Xen-devel mailing list > >>>>>> xen-de...@lists.xen.org > >>>>>> http://lists.xen.org/xen-devel > >>>>> > >>> > > > > > > . > > > > -- > Yours Sincerely, > > Cao jin >
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Qemu with the patch can't boot VM with IGD pass-through, I'm checking if it works w/o this patch to eliminate the environment influence. Thanks, -Xudong > -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Friday, January 8, 2016 7:57 PM > To: Hao, Xudong <xudong@intel.com> > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Lars Kurth > <lars.kurth@gmail.com>; Lars Kurth <lars.ku...@citrix.com>; Cao jin > <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; Stefano Stabellini > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. Tsirkin > <m...@redhat.com> > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > Since you are at it, could you please let me know how well igd passthrough > works without this bugfix: > > http://marc.info/?l=qemu-devel=145172165010604 > > which is about to land in QEMU. I guess it doesn't work at all? > > I am asking because I would like to know the level of support we need to > provide > to igd passthrough with the latest QEMU release (2.5). > > > On Thu, 7 Jan 2016, Hao, Xudong wrote: > > Sure. I'll test it soon. > > > > Thanks, > > -Xudong > > > > > -Original Message- > > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > > > Sent: Wednesday, January 6, 2016 8:18 PM > > > To: Lars Kurth <lars.kurth@gmail.com> > > > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Hao, > > > Xudong <xudong@intel.com>; Lars Kurth <lars.ku...@citrix.com>; > > > Cao jin <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; > > > Stefano Stabellini <stefano.stabell...@citrix.com>; > > > qemu-devel@nongnu.org; Michael S. Tsirkin <m...@redhat.com> > > > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > > > to realize() > > > > > > Hello Xudong, > > > > > > please test this patch: > > > > > > http://marc.info/?l=qemu-devel=145137863501079 > > > > > > with an intel graphic card assigned to a Xen guest. If everything > > > still works as expected, please reply with your Tested-by. > > > > > > Thanks, > > > > > > Stefano > > > > > > On Wed, 6 Jan 2016, Lars Kurth wrote: > > > > Hi folks, > > > > let me introduce you to Xudong from Intel, who is willing to help out. > > > > Best Regards > > > > Lars > > > > > > > > > On 4 Jan 2016, at 15:41, Stefano Stabellini > > > > > <stefano.stabell...@eu.citrix.com> > > > wrote: > > > > > > > > > > On Mon, 4 Jan 2016, Lars Kurth wrote: > > > > >> On 04/01/2016 14:47, "Stefano Stabellini" > > > > >> <stefano.stabell...@eu.citrix.com> wrote: > > > > >> > > > > >>> Unfortunately I don't have a setup to test this either. Maybe > > > > >>> Lars can find out who should be involved on the Intel side on this. > > > > >> > > > > >> I can certainly help to this and get back to you. What exactly > > > > >> are we asking Intel to do? > > > > >> It is not clear to me from this email thread > > > > > > > > > > Tiejun Chen, the author of the Intel graphic card passthrough > > > > > patches for QEMU, seems to have left the company. It would be > > > > > nice if somebody else tested this patch with an intel graphic > > > > > card assigned to a guest VM. > > > > > > > > > > ___ > > > > > Xen-devel mailing list > > > > > xen-de...@lists.xen.org > > > > > http://lists.xen.org/xen-devel > > > > > >
Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Sure. I'll test it soon. Thanks, -Xudong > -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Wednesday, January 6, 2016 8:18 PM > To: Lars Kurth <lars.kurth@gmail.com> > Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>; Hao, Xudong > <xudong@intel.com>; Lars Kurth <lars.ku...@citrix.com>; Cao jin > <caoj.f...@cn.fujitsu.com>; xen-de...@lists.xensource.com; Stefano Stabellini > <stefano.stabell...@citrix.com>; qemu-devel@nongnu.org; Michael S. Tsirkin > <m...@redhat.com> > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > Hello Xudong, > > please test this patch: > > http://marc.info/?l=qemu-devel=145137863501079 > > with an intel graphic card assigned to a Xen guest. If everything still works > as > expected, please reply with your Tested-by. > > Thanks, > > Stefano > > On Wed, 6 Jan 2016, Lars Kurth wrote: > > Hi folks, > > let me introduce you to Xudong from Intel, who is willing to help out. > > Best Regards > > Lars > > > > > On 4 Jan 2016, at 15:41, Stefano Stabellini > > > <stefano.stabell...@eu.citrix.com> > wrote: > > > > > > On Mon, 4 Jan 2016, Lars Kurth wrote: > > >> On 04/01/2016 14:47, "Stefano Stabellini" > > >> <stefano.stabell...@eu.citrix.com> wrote: > > >> > > >>> Unfortunately I don't have a setup to test this either. Maybe Lars > > >>> can find out who should be involved on the Intel side on this. > > >> > > >> I can certainly help to this and get back to you. What exactly are > > >> we asking Intel to do? > > >> It is not clear to me from this email thread > > > > > > Tiejun Chen, the author of the Intel graphic card passthrough > > > patches for QEMU, seems to have left the company. It would be nice > > > if somebody else tested this patch with an intel graphic card > > > assigned to a guest VM. > > > > > > ___ > > > Xen-devel mailing list > > > xen-de...@lists.xen.org > > > http://lists.xen.org/xen-devel > >
Re: [Qemu-devel] [PATCH] qemu-kvm: fix unmatched RAM alloction/free
-Original Message- From: Michael Tokarev [mailto:m...@tls.msk.ru] Sent: Wednesday, May 29, 2013 2:34 AM To: Hao, Xudong Cc: k...@vger.kernel.org; g...@redhat.com; pbonz...@redhat.com; qemu-devel@nongnu.org Subject: Re: [PATCH] qemu-kvm: fix unmatched RAM alloction/free Um, something's wrong with the Date. Care to resend with that fixed? Because the similar fix are already in qemu upstream, seems we need not this patch longer. Thanks, /mjt 18.01.2009 02:13, Xudong Hao wrote: mmap is used in qemu_vmalloc function instead of qemu_memalign(commit 7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched issue. [...]
Re: [Qemu-devel] [PATCH] qemu-kvm: fix unmatched RAM alloction/free
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Friday, May 24, 2013 1:13 AM
To: Hao, Xudong
Cc: k...@vger.kernel.org; g...@redhat.com; qemu-devel@nongnu.org
Subject: Re: [PATCH] qemu-kvm: fix unmatched RAM alloction/free
mmap is used in qemu_vmalloc function instead of qemu_memalign(commit
7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched
issue.
This issue appears when a PCI device is being assigned to KVM guest,
failure to read PCI rom file will bring RAM free, then the incorrect
qemu_vfree calling will cause a segment fault.
Signed-off-by: Xudong Hao xudong@intel.com
---
exec.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/exec.c b/exec.c
index fa1e0c3..d40d237 100644
--- a/exec.c
+++ b/exec.c
@@ -1152,15 +1152,11 @@ void qemu_ram_free(ram_addr_t addr)
abort();
#endif
} else {
-#if defined(TARGET_S390X) defined(CONFIG_KVM)
-munmap(block-host, block-length);
-#else
if (xen_enabled()) {
xen_invalidate_map_cache_entry(block-host);
} else {
-qemu_vfree(block-host);
+munmap(block-host, block-length);
}
-#endif
}
g_free(block);
break;
Just git pull. :) This is very similar to commit e7a09b9 (osdep: introduce
qemu_anon_ram_free to free qemu_anon_ram_alloc-ed memory, 2013-05-13)
OK, this commit do the same thing as my patch, I did not notice qemu upstream
tree, just take a look at qemu-kvm tree, but I think this commit should be
backport to qemu-kvm tree, because many user are using qemu-kvm for KVM.
Anyway please ignore this patch.
Thanks,
-Xudong
[Qemu-devel] [PATCH] qemu-kvm: fix unmatched RAM alloction/free
mmap is used in qemu_vmalloc function instead of qemu_memalign(commit
7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched
issue.
This issue appears when a PCI device is being assigned to KVM guest,
failure to read PCI rom file will bring RAM free, then the incorrect
qemu_vfree calling will cause a segment fault.
Signed-off-by: Xudong Hao xudong@intel.com
---
exec.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/exec.c b/exec.c
index fa1e0c3..d40d237 100644
--- a/exec.c
+++ b/exec.c
@@ -1152,15 +1152,11 @@ void qemu_ram_free(ram_addr_t addr)
abort();
#endif
} else {
-#if defined(TARGET_S390X) defined(CONFIG_KVM)
-munmap(block-host, block-length);
-#else
if (xen_enabled()) {
xen_invalidate_map_cache_entry(block-host);
} else {
-qemu_vfree(block-host);
+munmap(block-host, block-length);
}
-#endif
}
g_free(block);
break;
--
1.5.6
Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI
-Original Message- From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu-devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Ian Campbell Sent: Wednesday, February 27, 2013 7:07 PM To: Zhang, Xiantao Cc: aligu...@us.ibm.com; m...@redhat.com; Stefano Stabellini; Hao, Xudong; qemu-devel@nongnu.org; xen-de...@lists.xen.org; jbeul...@suse.com; afaer...@suse.de Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI I'm not sure about qemu-devel but on xen-devel the policy is not to top post so please could you avoid doping so. On Wed, 2013-02-27 at 09:49 +, Zhang, Xiantao wrote: Given that Xen has at least two other mechanisms (xenstore and hvmparams) for passing this sort of information around I'm not sure why hacking the emulated i440fx device should be the preferred option. Actually, even in hardware, I believe there are many registers which are implemented with write-once attributes, and they are only used by firmware and reserved for OS. The i440fx does not have this register (be it write once or otherwise), which is my actual point -- you are adding a magic property to the emulation of this device which the real hardware doesn't have. Sorry to response later. But why faking a register that the real hardware doesn't have is not acceptant? I440fx device don't need this register for native environment, but for virtualization, adding such a register can simplify things. It isn't really relevant that other hardware could implement write once registers, that's obviously the case. In addition, with this change, it can benefit all VMMs (not just Xen) which use Qemu as device model. If adopt xenstore way, perhaps other VMMs also have to write similar and duplicate logic for the same purpose. Which other VMM? AIUI qemu/kvm doesn't have a requirement to communicate this information from the VMM to qemu because qemu is the VMM and controls all of the hardware resources. I think our changes have better compatibility, we can't predict qemu will not be used for other VMMs, although changes only benefit xen till now.
Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Wednesday, February 27, 2013 6:50 PM
To: Hao, Xudong
Cc: aligu...@us.ibm.com; qemu-devel@nongnu.org;
stefano.stabell...@eu.citrix.com; xen-de...@lists.xen.org; afaer...@suse.de;
jbeul...@suse.com; Zhang, Xiantao
Subject: Re: [PATCH v2] piix: define a TOM register to report the base of PCI
On Mon, Feb 25, 2013 at 02:53:37PM +0800, Xudong Hao wrote:
v2:
* Use piix: in the subject rather than qemu:
* Define TOM register as one byte
* Define default TOM value instead of hardcode 0xe000 in more that one
place
* Use API pci_set_byte for pci config access
* Use dev-config instead of the indirect d-dev.config
Define a TOM(top of memory) register to report the base of PCI memory,
update
memory region dynamically. TOM register are defined to one byte in PCI
configure
space, because that only upper 4 bit of PCI memory takes effect for Xen, so
it requires bios set TOM with 16M-aligned.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
Could you supply some motivation for this patch?
It's a fix for Xen. Qemu want more information from Xen, copy Stefano's
comments:
QEMU needs to know where the end of the guest's RAM is (because there is
where it allocates the videoram and other stuff), so at least the size
of the MMIO hole is important.
Thanks,
-Xudong
---
hw/pc.h | 7 +++---
hw/pc_piix.c | 12 +++---
hw/piix_pci.c | 73
+++
3 files changed, 59 insertions(+), 33 deletions(-)
diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..62adcc5 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -129,15 +129,14 @@ extern int no_hpet;
struct PCII440FXState;
typedef struct PCII440FXState PCII440FXState;
+#define I440FX_TOM 0xe000
+#define I440FX_XEN_TOM 0xf000
+
PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
ISABus **isa_bus, qemu_irq *pic,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
-hwaddr pci_hole_start,
-hwaddr pci_hole_size,
-hwaddr pci_hole64_start,
-hwaddr pci_hole64_size,
MemoryRegion *pci_memory,
MemoryRegion *ram_memory);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..2eef510 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
kvmclock_create();
}
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
-below_4g_mem_size = 0xe000;
+if (ram_size = I440FX_TOM) {
+above_4g_mem_size = ram_size - I440FX_TOM;
+below_4g_mem_size = I440FX_TOM;
} else {
above_4g_mem_size = 0;
below_4g_mem_size = ram_size;
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
*system_memory,
if (pci_enabled) {
pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_bus, gsi,
system_memory, system_io,
ram_size,
- below_4g_mem_size,
- 0x1ULL -
below_4g_mem_size,
- 0x1ULL +
above_4g_mem_size,
- (sizeof(hwaddr) == 4
- ? 0
- : ((uint64_t)1 62)),
pci_memory, ram_memory);
} else {
pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..3e5a25c 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
#define I440FX_PAM_SIZE 7
#define I440FX_SMRAM0x72
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use one byte 0xb0 for the upper 8 bit, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
Do you have to use a fixed address? As others said, it's a hack.
How about adding a special device for this hackery?
+
static void piix3_set_irq(void *opaque, int pirq, int level);
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
pci_intx);
static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
pci_intx)
return (pci_intx + slot_addend) 3;
}
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+ram_addr_t above_4g_mem_size;
+hwaddr pci_hole_start, pci_hole_size
Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI
-Original Message-
From: qemu-devel-bounces+xudong.hao=intel@nongnu.org
[mailto:qemu-devel-bounces+xudong.hao=intel@nongnu.org] On Behalf
Of Stefano Stabellini
Sent: Tuesday, February 26, 2013 12:06 AM
To: Hao, Xudong
Cc: aligu...@us.ibm.com; Stefano Stabellini; m...@redhat.com;
qemu-devel@nongnu.org; xen-de...@lists.xen.org; jbeul...@suse.com;
afaer...@suse.de
Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
base of PCI
On Mon, 25 Feb 2013, Xudong Hao wrote:
v2:
* Use piix: in the subject rather than qemu:
* Define TOM register as one byte
* Define default TOM value instead of hardcode 0xe000 in more that one
place
* Use API pci_set_byte for pci config access
* Use dev-config instead of the indirect d-dev.config
Define a TOM(top of memory) register to report the base of PCI memory,
update
memory region dynamically. TOM register are defined to one byte in PCI
configure
space, because that only upper 4 bit of PCI memory takes effect for Xen, so
it requires bios set TOM with 16M-aligned.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
The patch is OK from my POV, but I think that Ian raised a valid
concern: we are supposed to emulate a real piece of hardware, maybe
another mechanism (xenbus? hvmop?) to pass the information from
hvmloader to QEMU would be a better fit than this.
Otherwise at least we would need to advertize this feature somehow: if
hvmloader can use it, the guest kernel can use it too...
Hi, Ian and Stefano
Here adding this faking register in bios is a hack way.
However, what we emulated is not full real piece of hardware at all times, the
max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
The faking register is only effective by bios and device model. This register
is reserved by host bridge, so guest can't access this register, guest kernel
should handle well when accessing a reserved region.
-Thanks
Xudong
hw/pc.h | 7 +++---
hw/pc_piix.c | 12 +++---
hw/piix_pci.c | 73
+++
3 files changed, 59 insertions(+), 33 deletions(-)
diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..62adcc5 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -129,15 +129,14 @@ extern int no_hpet;
struct PCII440FXState;
typedef struct PCII440FXState PCII440FXState;
+#define I440FX_TOM 0xe000
+#define I440FX_XEN_TOM 0xf000
+
PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
ISABus **isa_bus, qemu_irq *pic,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
-hwaddr pci_hole_start,
-hwaddr pci_hole_size,
-hwaddr pci_hole64_start,
-hwaddr pci_hole64_size,
MemoryRegion *pci_memory,
MemoryRegion *ram_memory);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..2eef510 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
kvmclock_create();
}
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
-below_4g_mem_size = 0xe000;
+if (ram_size = I440FX_TOM) {
+above_4g_mem_size = ram_size - I440FX_TOM;
+below_4g_mem_size = I440FX_TOM;
} else {
above_4g_mem_size = 0;
below_4g_mem_size = ram_size;
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
*system_memory,
if (pci_enabled) {
pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_bus, gsi,
system_memory, system_io,
ram_size,
- below_4g_mem_size,
- 0x1ULL -
below_4g_mem_size,
- 0x1ULL +
above_4g_mem_size,
- (sizeof(hwaddr) == 4
- ? 0
- : ((uint64_t)1 62)),
pci_memory, ram_memory);
} else {
pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..3e5a25c 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
#define I440FX_PAM_SIZE 7
#define I440FX_SMRAM0x72
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use one byte 0xb0 for the upper 8 bit, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
static void piix3_set_irq(void *opaque, int
[Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI
v2:
* Use piix: in the subject rather than qemu:
* Define TOM register as one byte
* Define default TOM value instead of hardcode 0xe000 in more that one place
* Use API pci_set_byte for pci config access
* Use dev-config instead of the indirect d-dev.config
Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically. TOM register are defined to one byte in PCI configure
space, because that only upper 4 bit of PCI memory takes effect for Xen, so
it requires bios set TOM with 16M-aligned.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
hw/pc.h | 7 +++---
hw/pc_piix.c | 12 +++---
hw/piix_pci.c | 73 +++
3 files changed, 59 insertions(+), 33 deletions(-)
diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..62adcc5 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -129,15 +129,14 @@ extern int no_hpet;
struct PCII440FXState;
typedef struct PCII440FXState PCII440FXState;
+#define I440FX_TOM 0xe000
+#define I440FX_XEN_TOM 0xf000
+
PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
ISABus **isa_bus, qemu_irq *pic,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
-hwaddr pci_hole_start,
-hwaddr pci_hole_size,
-hwaddr pci_hole64_start,
-hwaddr pci_hole64_size,
MemoryRegion *pci_memory,
MemoryRegion *ram_memory);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..2eef510 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
kvmclock_create();
}
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
-below_4g_mem_size = 0xe000;
+if (ram_size = I440FX_TOM) {
+above_4g_mem_size = ram_size - I440FX_TOM;
+below_4g_mem_size = I440FX_TOM;
} else {
above_4g_mem_size = 0;
below_4g_mem_size = ram_size;
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
if (pci_enabled) {
pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_bus, gsi,
system_memory, system_io, ram_size,
- below_4g_mem_size,
- 0x1ULL - below_4g_mem_size,
- 0x1ULL + above_4g_mem_size,
- (sizeof(hwaddr) == 4
- ? 0
- : ((uint64_t)1 62)),
pci_memory, ram_memory);
} else {
pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..3e5a25c 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
#define I440FX_PAM_SIZE 7
#define I440FX_SMRAM0x72
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use one byte 0xb0 for the upper 8 bit, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
static void piix3_set_irq(void *opaque, int pirq, int level);
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
pci_intx)
return (pci_intx + slot_addend) 3;
}
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+ram_addr_t above_4g_mem_size;
+hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+pci_hole_start = pci_default_read_config(f-dev, I440FX_PCI_HOLE_BASE, 1)
24;
+pci_hole_size = 0x1ULL - pci_hole_start;
+
+if (ram_size = pci_hole_start) {
+above_4g_mem_size = ram_size - pci_hole_start;
+} else {
+above_4g_mem_size = 0;
+}
+pci_hole64_start = 0x1ULL + above_4g_mem_size;
+pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 62);
+
+if (del) {
+memory_region_del_subregion(f-system_memory, f-pci_hole);
+if (pci_hole64_size) {
+memory_region_del_subregion(f-system_memory, f-pci_hole_64bit);
+}
+}
+
+memory_region_init_alias(f-pci_hole, pci-hole, f-pci_address_space,
+ pci_hole_start, pci_hole_size);
+memory_region_add_subregion(f-system_memory, pci_hole_start,
f-pci_hole);
+memory_region_init_alias(f-pci_hole_64bit, pci-hole64,
+ f-pci_address_space,
+ pci_hole64_start, pci_hole64_size);
+if (pci_hole64_size
Re: [Qemu-devel] [Xen-devel] [PATCH] qemu: define a TOM register to report the base of PCI
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, February 22, 2013 5:04 PM
To: Hao, Xudong
Cc: stefano.stabell...@eu.citrix.com; Zhang, Xiantao; xen-de...@lists.xen.org;
qemu-devel@nongnu.org; m...@redhat.com; aligu...@us.ibm.com
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
base of PCI
On 22.02.13 at 04:23, Xudong Hao xudong@intel.com wrote:
@@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
d-dev.config[I440FX_SMRAM] = 0x02;
+/* Emulate top of memory, here use 0xe000 as default val*/
+if (xen_enabled()) {
+d-dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
+} else {
+d-dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
+}
+d-dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
+d-dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
+d-dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
+
cpu_smm_register(i440fx_set_smm, d);
return 0;
}
Isn't this the wrong way round (big endian, when it needs to be
little)?
Jan,
Here it should be little endian since the following config reading is little
endian, I'll correct it. Thanks your comments.
Or else, this read and calculation
+pci_hole_start = pci_default_read_config(f-dev,
I440FX_PCI_HOLE_BASE, 4);
+pci_hole_size = 0x1ULL - pci_hole_start;
would seem wrong (e.g. if the granularity is meant to be 16M).
And then again, wasting 4 bytes of config space on something that
one ought to be allowed to expect to be at least 64k-aligned seems
questionable too. hvmloader surely could align the value up to the
next 64k boundary before writing the - then only word size - field.
Hvmloader did 64k-aligned, I'm not quite understand, could you help to point
out?
If considering wasting of config space, actually hvmloader only write 4 values
in this register: 3.75G(0xf000), 3.5G(0xe000), 3G(0xc000),
2G(0x8000), then 1 byte is enough for xen.
That would come closer to how real chipsets normally implement
things like this.
Jan
Re: [Qemu-devel] [PATCH] qemu: define a TOM register to report the base of PCI
-Original Message- From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] Sent: Friday, February 22, 2013 8:35 PM To: Hao, Xudong Cc: aligu...@us.ibm.com; m...@redhat.com; qemu-devel@nongnu.org; Stefano Stabellini; xen-de...@lists.xen.org; Zhang, Xiantao Subject: Re: [PATCH] qemu: define a TOM register to report the base of PCI On Fri, 22 Feb 2013, Xudong Hao wrote: Define a TOM(top of memory) register to report the base of PCI memory, update memory region dynamically. The use case of this register defination is for Xen till now. Signed-off-by: Xudong Hao xudong@intel.com Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com Thanks for the patch! Aside from Jan's comment on the pci config endianness, I would also like to see an #define somewhere in QEMU to specific what's the default TOM. In particular I wouldn't want 0xe000 (and 0xf000) to be hardcoded in more than one place. Good comments, I'll define the default TOM out and replace the hardcode. Thanks, -Xudong
[Qemu-devel] [PATCH] qemu: define a TOM register to report the base of PCI
Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically.
The use case of this register defination is for Xen till now.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
hw/pc.h | 4 ---
hw/pc_piix.c | 6 -
hw/piix_pci.c | 79 ---
3 files changed, 59 insertions(+), 30 deletions(-)
diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..2a60490 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -134,10 +134,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
*piix_devfn,
MemoryRegion *address_space_mem,
MemoryRegion *address_space_io,
ram_addr_t ram_size,
-hwaddr pci_hole_start,
-hwaddr pci_hole_size,
-hwaddr pci_hole64_start,
-hwaddr pci_hole64_size,
MemoryRegion *pci_memory,
MemoryRegion *ram_memory);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..98cf467 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
if (pci_enabled) {
pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_bus, gsi,
system_memory, system_io, ram_size,
- below_4g_mem_size,
- 0x1ULL - below_4g_mem_size,
- 0x1ULL + above_4g_mem_size,
- (sizeof(hwaddr) == 4
- ? 0
- : ((uint64_t)1 62)),
pci_memory, ram_memory);
} else {
pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..88bd688 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
#define I440FX_PAM_SIZE 7
#define I440FX_SMRAM0x72
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use four bytes 0xb0-0xb3 for this purpose, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
static void piix3_set_irq(void *opaque, int pirq, int level);
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
pci_intx)
return (pci_intx + slot_addend) 3;
}
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+ram_addr_t above_4g_mem_size;
+hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+pci_hole_start = pci_default_read_config(f-dev, I440FX_PCI_HOLE_BASE, 4);
+pci_hole_size = 0x1ULL - pci_hole_start;
+
+if (ram_size = pci_hole_start) {
+above_4g_mem_size = ram_size - pci_hole_start;
+} else {
+above_4g_mem_size = 0;
+}
+pci_hole64_start = 0x1ULL + above_4g_mem_size;
+pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 62);
+
+if (del) {
+memory_region_del_subregion(f-system_memory, f-pci_hole);
+if (pci_hole64_size) {
+memory_region_del_subregion(f-system_memory, f-pci_hole_64bit);
+}
+}
+
+memory_region_init_alias(f-pci_hole, pci-hole, f-pci_address_space,
+ pci_hole_start, pci_hole_size);
+memory_region_add_subregion(f-system_memory, pci_hole_start,
f-pci_hole);
+memory_region_init_alias(f-pci_hole_64bit, pci-hole64,
+ f-pci_address_space,
+ pci_hole64_start, pci_hole64_size);
+if (pci_hole64_size) {
+memory_region_add_subregion(f-system_memory, pci_hole64_start,
+f-pci_hole_64bit);
+}
+}
+
+
static void i440fx_update_memory_mappings(PCII440FXState *d)
{
int i;
@@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
range_covers_byte(address, len, I440FX_SMRAM)) {
i440fx_update_memory_mappings(d);
}
+if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
+i440fx_update_pci_mem_hole(d, true);
+}
}
static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
@@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
d-dev.config[I440FX_SMRAM] = 0x02;
+/* Emulate top of memory, here use 0xe000 as default val*/
+if (xen_enabled()) {
+d-dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
+} else {
+d-dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
+}
+d-dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
+d-dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
+d-dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00
[Qemu-devel] [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
Enable 64 bits bar emulation.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..fb58ca9 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL, cur_region-size,
@@ -468,10 +473,10 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64 has
- size 0x% PRIx64 , which is not a multiple of
- 4K. You might experience some performance hit
- due to that.,
+error_report(PCI region %d at address 0x%016 PRIx64 has
+ size 0x%016 PRIx64 , which is not a multiple
+ of 4K. You might experience some performance
+ hit due to that.,
i, cur_region-base_addr, cur_region-size);
memory_region_init_io(pci_dev-v_addrs[i].real_iomem,
slow_bar_ops, pci_dev-v_addrs[i],
@@ -632,7 +637,8 @@ again:
rp-valid = 0;
rp-resource_fd = -1;
size = end - start + 1;
-flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
+flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH
+ | IORESOURCE_MEM_64;
if (size == 0 || (flags ~IORESOURCE_PREFETCH) == 0) {
continue;
}
--
1.5.5
Re: [Qemu-devel] [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 12:06 AM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
k...@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Wed, 2012-12-19 at 16:47 +0800, Xudong Hao wrote:
Enable 64 bits bar emulation.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..fb58ca9 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,10 +473,10 @@ static int
assigned_dev_register_regions(PCIRegion *io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
- 4K. You might experience some
performance hit
- due to that.,
+error_report(PCI region %d at address 0x%016 PRIx64
has
+ size 0x%016 PRIx64 , which is not a
multiple
+ of 4K. You might experience some
performance
+ hit due to that.,
nit, these changes to %016 don't make sense. If the size is not a
multiple of 4k, then it's less than 4k, so adding leading zeros is just
a waste. Also, are BARs that small likely to be 64bit? Seems like not,
so more unnecessary zeros. Thanks,
Alex,
You're right for this error_report print less than 4k. So your comments is
removing 016 and just remain the original code is fine, right?
Re: [Qemu-devel] [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 10:39 AM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
k...@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Thu, 2012-12-20 at 01:52 +, Hao, Xudong wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 12:06 AM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
k...@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Wed, 2012-12-19 at 16:47 +0800, Xudong Hao wrote:
Enable 64 bits bar emulation.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..fb58ca9 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int
assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,10 +473,10 @@ static int
assigned_dev_register_regions(PCIRegion *io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
- 4K. You might experience some
performance hit
- due to that.,
+error_report(PCI region %d at address 0x%016
PRIx64
has
+ size 0x%016 PRIx64 , which is not
a
multiple
+ of 4K. You might experience some
performance
+ hit due to that.,
nit, these changes to %016 don't make sense. If the size is not a
multiple of 4k, then it's less than 4k, so adding leading zeros is just
a waste. Also, are BARs that small likely to be 64bit? Seems like not,
so more unnecessary zeros. Thanks,
Alex,
You're right for this error_report print less than 4k. So your comments is
removing 016 and just remain the original code is fine, right?
Yes, I'd just drop that chunk and leave the original error string.
I'll send next version to remove it.
Thanks,
Alex
[Qemu-devel] [PATCH v3] qemu-kvm/pci-assign: 64 bits bar emulation
Enable 64 bits bar emulation.
v3 changes from v2:
- Leave original error string and drop the leading 016.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..2271a2e 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL, cur_region-size,
@@ -632,7 +637,8 @@ again:
rp-valid = 0;
rp-resource_fd = -1;
size = end - start + 1;
-flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
+flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH
+ | IORESOURCE_MEM_64;
if (size == 0 || (flags ~IORESOURCE_PREFETCH) == 0) {
continue;
}
--
1.5.5
Re: [Qemu-devel] [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Saturday, November 03, 2012 6:55 PM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; a...@redhat.com; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-02 06:38, Xudong Hao wrote:
For 64 bit processor, emulate 40 bits physical address if the host physical
address space = 40bits, else guest physical is same as host.
Signed-off-by: Xudong Hao xudong@intel.com
---
target-i386/cpu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 423e009..3a78881 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t
index, uint32_t count,
if (env-cpuid_ext2_features CPUID_EXT2_LM) {
/* 64 bit processor */
/* XXX: The physical address space is limited to 42 bits in exec.c. */
-*eax = 0x3028; /* 48 bits virtual, 40 bits physical */
+/* XXX: 40 bits physical if host physical address space = 40 bits */
+uint32_t a, b, c, d;
+host_cpuid(0x8008, 0, a, b, c, d);
+*eax = a 0x3028 ? a : 0x3028;
This variation will not only affect -cpu host, right? That can create
problems when migrating between hosts with different address widths, and
then we will need some control knob to adjust what it reported to the guest.
Oh, I did not consider migrating to different platform(addr widths).
But I think the fixed value 40 bits may cause problem: in VT-d case, when a
host support GAW 40 bits, and qemu emulate 40 bits guest physical address
space, will bring bug on:
drivers/iommu/intel-iommu.c
static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
unsigned long pfn, int target_level)
{
int addr_width = agaw_to_width(domain-agaw) - VTD_PAGE_SHIFT;
...
BUG_ON(!domain-pgd);
BUG_ON(addr_width BITS_PER_LONG pfn addr_width);
Jan
} else {
if (env-cpuid_features CPUID_PSE36)
*eax = 0x0024; /* 36 bits physical */
Re: [Qemu-devel] [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Sunday, November 04, 2012 8:55 PM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; a...@redhat.com; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-04 13:15, Hao, Xudong wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Saturday, November 03, 2012 6:55 PM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; a...@redhat.com; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-02 06:38, Xudong Hao wrote:
For 64 bit processor, emulate 40 bits physical address if the host
physical
address space = 40bits, else guest physical is same as host.
Signed-off-by: Xudong Hao xudong@intel.com
---
target-i386/cpu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 423e009..3a78881 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env,
uint32_t
index, uint32_t count,
if (env-cpuid_ext2_features CPUID_EXT2_LM) {
/* 64 bit processor */
/* XXX: The physical address space is limited to 42 bits in exec.c. */
-*eax = 0x3028; /* 48 bits virtual, 40 bits physical
*/
+/* XXX: 40 bits physical if host physical address space = 40 bits */
+uint32_t a, b, c, d;
+host_cpuid(0x8008, 0, a, b, c, d);
+*eax = a 0x3028 ? a : 0x3028;
This variation will not only affect -cpu host, right? That can create
problems when migrating between hosts with different address widths, and
then we will need some control knob to adjust what it reported to the
guest.
Oh, I did not consider migrating to different platform(addr widths).
But I think the fixed value 40 bits may cause problem: in VT-d case, when a
host support GAW 40 bits, and qemu emulate 40 bits guest physical address
space, will bring bug on:
drivers/iommu/intel-iommu.c
static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
unsigned long pfn, int target_level)
{
int addr_width = agaw_to_width(domain-agaw) - VTD_PAGE_SHIFT;
...
BUG_ON(!domain-pgd);
BUG_ON(addr_width BITS_PER_LONG pfn addr_width);
Does it mean that buggy or malicious user space can trigger a kernel
bug? Then this must be fixed of course.
Probably yes, when guest RAM is large enough or allocate MMIO to very high
address.
Jan, I'm not familiar the migration, do you have interest to add the migration
part fixing?
Re: [Qemu-devel] [PATCH 2/2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: Saturday, November 03, 2012 6:44 PM
To: Hao, Xudong
Cc: qemu-devel@nongnu.org; a...@redhat.com; k...@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-kvm/pci-assign: 64 bits bar
emulation
On Fri, Nov 2, 2012 at 5:38 AM, Xudong Hao xudong@intel.com wrote:
Enable 64 bits bar emulation.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 05b93d9..f1f8d1e 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,8 +473,8 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
+error_report(PCI region %d at address 0lx% PRIx64
has
+ size 0lx% PRIx64 , which is not a
multiple of
Adding 'l' to '0x' prefix does not make sense.
Thanks review it, changes to:
+error_report(PCI region %d at address 0x%016 PRIx64 has
+ size 0x%016 PRIx64 , which is not a multiple
of
[Qemu-devel] [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space
For 64 bit processor, emulate 40 bits physical address if the host physical
address space = 40bits, else guest physical is same as host.
Signed-off-by: Xudong Hao xudong@intel.com
---
target-i386/cpu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 423e009..3a78881 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
if (env-cpuid_ext2_features CPUID_EXT2_LM) {
/* 64 bit processor */
/* XXX: The physical address space is limited to 42 bits in exec.c. */
-*eax = 0x3028; /* 48 bits virtual, 40 bits physical */
+/* XXX: 40 bits physical if host physical address space = 40 bits */
+uint32_t a, b, c, d;
+host_cpuid(0x8008, 0, a, b, c, d);
+*eax = a 0x3028 ? a : 0x3028;
} else {
if (env-cpuid_features CPUID_PSE36)
*eax = 0x0024; /* 36 bits physical */
--
1.5.5
[Qemu-devel] [PATCH 2/2] qemu-kvm/pci-assign: 64 bits bar emulation
Enable 64 bits bar emulation.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 05b93d9..f1f8d1e 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL, cur_region-size,
@@ -468,8 +473,8 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64 has
- size 0x% PRIx64 , which is not a multiple of
+error_report(PCI region %d at address 0lx% PRIx64 has
+ size 0lx% PRIx64 , which is not a multiple of
4K. You might experience some performance hit
due to that.,
i, cur_region-base_addr, cur_region-size);
@@ -638,7 +643,8 @@ again:
rp-valid = 0;
rp-resource_fd = -1;
size = end - start + 1;
-flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
+flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH
+ | IORESOURCE_MEM_64;
if (size == 0 || (flags ~IORESOURCE_PREFETCH) == 0) {
continue;
}
--
1.5.5
Re: [Qemu-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
-Original Message-
From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
Sent: Tuesday, September 25, 2012 6:52 PM
To: Hao, Xudong
Cc: Stefano Stabellini; xen-de...@lists.xen.org; qemu-devel@nongnu.org;
Zhang, Xiantao
Subject: Re: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
On Tue, 25 Sep 2012, Xudong Hao wrote:
Changes from v1:
- Rebase to qemu upstream from qemu-xen
Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
some cody style issues that need to be fixed.
OK, will use this scripts to check code style.
Currently it is assumed PCI device BAR access 4G memory. If there is such
a
device whose BAR size is larger than 4G, it must access 4G memory
address.
This patch enable the 64bits big BAR support on qemu.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
hw/xen_pt.c | 16
hw/xen_pt_config_init.c | 42
+-
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..2a8bcf3 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -403,21 +403,21 @@ static int
xen_pt_register_regions(XenPCIPassthroughState *s)
s-bases[i].access.u = r-base_addr;
-if (r-type XEN_HOST_PCI_REGION_TYPE_IO) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_IO)
type = PCI_BASE_ADDRESS_SPACE_IO;
-} else {
+else if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64)
+type = PCI_BASE_ADDRESS_MEM_TYPE_64;
+else if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH)
+type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+else
type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
-type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-}
-}
Aside from the cody style issue here, this changes the behavior for type
PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:
type =
PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;
now we cannot anymore.
Will change to:
-if (r-type XEN_HOST_PCI_REGION_TYPE_IO) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_IO)
type = PCI_BASE_ADDRESS_SPACE_IO;
-} else {
+else
type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64)
+type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+ else if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH)
type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-}
-}
memory_region_init_io(s-bar[i], ops, s-dev,
xen-pci-pt-bar, r-size);
pci_register_bar(s-dev, i, type, s-bar[i]);
-XEN_PT_LOG(s-dev, IO region %i registered
(size=0x%08PRIx64
-base_addr=0x%08PRIx64 type: %#x)\n,
+XEN_PT_LOG(s-dev, IO region %i registered
(size=0x%lxPRIx64
+base_addr=0x%lxPRIx64 type: %#x)\n,
i, r-size, r-base_addr, type);
}
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..5e7ca22 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,7 @@ static int
xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
#define XEN_PT_BAR_IO_RO_MASK 0x0003 /* BAR ReadOnly
mask(I/O) */
#define XEN_PT_BAR_IO_EMU_MASK0xFFFC /* BAR emul
mask(I/O) */
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r);
there is just one user of xen_pt_get_bar_size, maybe you can just
move the implementation here
Ok, thanks.
static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
XenPTRegInfo *reg)
{
@@ -366,7 +367,7 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
/* check unused BAR */
r = d-io_regions[index];
-if (r-size == 0) {
+if (!xen_pt_get_bar_size(r)) {
return XEN_PT_BAR_FLAG_UNUSED;
}
@@ -383,6 +384,24 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
}
}
+static bool is_64bit_bar(PCIIORegion *r)
+{
+return !!(r-type PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+if (is_64bit_bar(r))
+{
+uint64_t size64;
+size64 = (r + 1)-size;
+size64 = 32;
+size64 += r-size;
+return size64;
+}
+return r-size;
+}
+
static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
{
if (hr-type XEN_HOST_PCI_REGION_TYPE_IO) {
@@ -481,7 +500,10 @@ static int
xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
switch (s-bases[index
Re: [Qemu-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
-Original Message-
From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
Sent: Wednesday, September 26, 2012 6:57 PM
To: Hao, Xudong
Cc: Stefano Stabellini; xen-de...@lists.xen.org; qemu-devel@nongnu.org;
Zhang, Xiantao
Subject: RE: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Will change to:
-if (r-type XEN_HOST_PCI_REGION_TYPE_IO) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_IO)
type = PCI_BASE_ADDRESS_SPACE_IO;
-} else {
+else
type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64)
+type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+ else if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH)
type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-}
-}
Isn't it possible that both XEN_HOST_PCI_REGION_TYPE_MEM_64 and
XEN_HOST_PCI_REGION_TYPE_PREFETCH are set? It doesn't look like this can
cover that case.
It's possible. Thanks comments.
The following seems to be what you are looking for:
if (r-type XEN_HOST_PCI_REGION_TYPE_IO) {
type = PCI_BASE_ADDRESS_SPACE_IO;
} else {
type = PCI_BASE_ADDRESS_SPACE_MEMORY;
if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
}
if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64) {
type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
}
}
static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState
*s,
XenPTRegInfo *reg)
{
@@ -366,7 +367,7 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
/* check unused BAR */
r = d-io_regions[index];
-if (r-size == 0) {
+if (!xen_pt_get_bar_size(r)) {
return XEN_PT_BAR_FLAG_UNUSED;
}
@@ -383,6 +384,24 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
}
}
+static bool is_64bit_bar(PCIIORegion *r)
+{
+return !!(r-type PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+if (is_64bit_bar(r))
+{
+uint64_t size64;
+size64 = (r + 1)-size;
+size64 = 32;
+size64 += r-size;
+return size64;
+}
+return r-size;
+}
+
static inline uint32_t base_address_with_flags(XenHostPCIIORegion
*hr)
{
if (hr-type XEN_HOST_PCI_REGION_TYPE_IO) {
@@ -481,7 +500,10 @@ static int
xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
switch (s-bases[index].bar_flag) {
case XEN_PT_BAR_FLAG_MEM:
bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
-bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+if (!r_size)
+bar_ro_mask = XEN_PT_BAR_ALLF;
+else
+bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size -
1);
break;
Is this an actual mistake everywhere?
It's low 32bit mask for 64 bit bars.
I see. It is a good idea to add a line of comment in the code saying
that.
OK, I'll add code comment.
[Qemu-devel] [PATCH v3] qemu/xen: Add 64 bits big bar support on qemu
v3 changes from v2:
- Refine code following by the qemu code style
- As suggestion by Stefano, cheanup code, add some code comment
v2 changes from v1:
- Rebase to qemu upstream from qemu-xen
Currently it is assumed PCI device BAR access 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access 4G memory address.
This patch enable the 64bits big BAR support on qemu.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
hw/xen_pt.c |7 +--
hw/xen_pt_config_init.c | 39 ++-
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..838bcea 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -410,14 +410,17 @@ static int xen_pt_register_regions(XenPCIPassthroughState
*s)
if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
}
+if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64) {
+type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
}
memory_region_init_io(s-bar[i], ops, s-dev,
xen-pci-pt-bar, r-size);
pci_register_bar(s-dev, i, type, s-bar[i]);
-XEN_PT_LOG(s-dev, IO region %i registered (size=0x%08PRIx64
-base_addr=0x%08PRIx64 type: %#x)\n,
+XEN_PT_LOG(s-dev, IO region %i registered (size=0x%lxPRIx64
+base_addr=0x%lxPRIx64 type: %#x)\n,
i, r-size, r-base_addr, type);
}
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..0a5f82c 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,23 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
#define XEN_PT_BAR_IO_RO_MASK 0x0003 /* BAR ReadOnly mask(I/O) */
#define XEN_PT_BAR_IO_EMU_MASK0xFFFC /* BAR emul mask(I/O) */
+static bool is_64bit_bar(PCIIORegion *r)
+{
+return !!(r-type PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+if (is_64bit_bar(r)) {
+uint64_t size64;
+size64 = (r + 1)-size;
+size64 = 32;
+size64 += r-size;
+return size64;
+}
+return r-size;
+}
+
static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
XenPTRegInfo *reg)
{
@@ -366,7 +383,7 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
/* check unused BAR */
r = d-io_regions[index];
-if (r-size == 0) {
+if (!xen_pt_get_bar_size(r)) {
return XEN_PT_BAR_FLAG_UNUSED;
}
@@ -481,7 +498,12 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
switch (s-bases[index].bar_flag) {
case XEN_PT_BAR_FLAG_MEM:
bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
-bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+if (!r_size) {
+/* low 32 bits mask for 64 bit bars */
+bar_ro_mask = XEN_PT_BAR_ALLF;
+} else {
+bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+}
break;
case XEN_PT_BAR_FLAG_IO:
bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
@@ -489,7 +511,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
break;
case XEN_PT_BAR_FLAG_UPPER:
bar_emu_mask = XEN_PT_BAR_ALLF;
-bar_ro_mask = 0;/* all upper 32bit are R/W */
+bar_ro_mask = r_size ? r_size - 1 : 0;
break;
default:
break;
@@ -501,22 +523,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState
*s, XenPTReg *cfg_entry,
/* check whether we need to update the virtual region address or not */
switch (s-bases[index].bar_flag) {
+case XEN_PT_BAR_FLAG_UPPER:
case XEN_PT_BAR_FLAG_MEM:
/* nothing to do */
break;
case XEN_PT_BAR_FLAG_IO:
/* nothing to do */
break;
-case XEN_PT_BAR_FLAG_UPPER:
-if (cfg_entry-data) {
-if (cfg_entry-data != (XEN_PT_BAR_ALLF ~bar_ro_mask)) {
-XEN_PT_WARN(d, Guest attempt to set high MMIO Base Address.
-Ignore mapping.
-(offset: 0x%02x, high address: 0x%08x)\n,
-reg-offset, cfg_entry-data);
-}
-}
-break;
default:
break;
}
--
1.5.5
[Qemu-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Changes from v1:
- Rebase to qemu upstream from qemu-xen
Currently it is assumed PCI device BAR access 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access 4G memory address.
This patch enable the 64bits big BAR support on qemu.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
hw/xen_pt.c | 16
hw/xen_pt_config_init.c | 42 +-
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..2a8bcf3 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -403,21 +403,21 @@ static int xen_pt_register_regions(XenPCIPassthroughState
*s)
s-bases[i].access.u = r-base_addr;
-if (r-type XEN_HOST_PCI_REGION_TYPE_IO) {
+if (r-type XEN_HOST_PCI_REGION_TYPE_IO)
type = PCI_BASE_ADDRESS_SPACE_IO;
-} else {
+else if (r-type XEN_HOST_PCI_REGION_TYPE_MEM_64)
+type = PCI_BASE_ADDRESS_MEM_TYPE_64;
+else if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH)
+type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+else
type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-if (r-type XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
-type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
-}
-}
memory_region_init_io(s-bar[i], ops, s-dev,
xen-pci-pt-bar, r-size);
pci_register_bar(s-dev, i, type, s-bar[i]);
-XEN_PT_LOG(s-dev, IO region %i registered (size=0x%08PRIx64
-base_addr=0x%08PRIx64 type: %#x)\n,
+XEN_PT_LOG(s-dev, IO region %i registered (size=0x%lxPRIx64
+base_addr=0x%lxPRIx64 type: %#x)\n,
i, r-size, r-base_addr, type);
}
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..5e7ca22 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,7 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
#define XEN_PT_BAR_IO_RO_MASK 0x0003 /* BAR ReadOnly mask(I/O) */
#define XEN_PT_BAR_IO_EMU_MASK0xFFFC /* BAR emul mask(I/O) */
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r);
static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
XenPTRegInfo *reg)
{
@@ -366,7 +367,7 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
/* check unused BAR */
r = d-io_regions[index];
-if (r-size == 0) {
+if (!xen_pt_get_bar_size(r)) {
return XEN_PT_BAR_FLAG_UNUSED;
}
@@ -383,6 +384,24 @@ static XenPTBarFlag
xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
}
}
+static bool is_64bit_bar(PCIIORegion *r)
+{
+return !!(r-type PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+if (is_64bit_bar(r))
+{
+uint64_t size64;
+size64 = (r + 1)-size;
+size64 = 32;
+size64 += r-size;
+return size64;
+}
+return r-size;
+}
+
static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
{
if (hr-type XEN_HOST_PCI_REGION_TYPE_IO) {
@@ -481,7 +500,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
switch (s-bases[index].bar_flag) {
case XEN_PT_BAR_FLAG_MEM:
bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
-bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+if (!r_size)
+bar_ro_mask = XEN_PT_BAR_ALLF;
+else
+bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
break;
case XEN_PT_BAR_FLAG_IO:
bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
@@ -489,7 +511,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
break;
case XEN_PT_BAR_FLAG_UPPER:
bar_emu_mask = XEN_PT_BAR_ALLF;
-bar_ro_mask = 0;/* all upper 32bit are R/W */
+if (!r_size)
+bar_ro_mask = 0;
+else
+bar_ro_mask = r_size - 1;
break;
default:
break;
@@ -501,22 +526,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState
*s, XenPTReg *cfg_entry,
/* check whether we need to update the virtual region address or not */
switch (s-bases[index].bar_flag) {
+case XEN_PT_BAR_FLAG_UPPER:
case XEN_PT_BAR_FLAG_MEM:
/* nothing to do */
break;
case XEN_PT_BAR_FLAG_IO:
/* nothing to do */
break;
-case XEN_PT_BAR_FLAG_UPPER:
-if (cfg_entry-data) {
-if (cfg_entry-data != (XEN_PT_BAR_ALLF ~bar_ro_mask)) {
-XEN_PT_WARN(d, Guest attempt to set high MMIO Base Address.
-Ignore mapping.
-(offset: 0x%02x, high address: 0x%08x)\n,
-reg-offset, cfg_entry-data
[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image
Fixed patch in qemu-kvm: 96df67d1c3928704cd76d0b2e76372ef18658e85, close this bug. ** Changed in: qemu Status: Confirmed = Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/706766 Title: [Qemu-kvm] qemu-img fail to create qcow image Status in QEMU: Fix Committed Bug description: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error qemu-img: Could not open './qcow.img'
[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image
Patch worked with testing. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/706766 Title: [Qemu-kvm] qemu-img fail to create qcow image Status in QEMU: Confirmed Bug description: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error qemu-img: Could not open './qcow.img'
[Qemu-devel] [Bug 706766] [NEW] [Qemu-kvm] qemu-img fail to create qcow image
Public bug reported: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error qemu-img: Could not open './qcow.img' ** 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/706766 Title: [Qemu-kvm] qemu-img fail to create qcow image Status in QEMU: New Bug description: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error qemu-img: Could not open './qcow.img'
[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image
The latest qemu tree e10990c3f0c39e92ab5f74004b89a24fcc36fa14 also has this issue. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/706766 Title: [Qemu-kvm] qemu-img fail to create qcow image Status in QEMU: New Bug description: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error qemu-img: Could not open './qcow.img'
RE: [Qemu-devel] qemu-kvm build issue on RHEL5.1
Hidetoshi Seto wrote:
(Add CC to k...@vger)
(2010/10/12 10:52), Hao, Xudong wrote:
Hi,
Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can
pass on Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system?
Gcc: 4.1.2
system: RHEL5.1
qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd
...
LINK qemu-img
LINK qemu-io
CClibhw64/virtio-9p-local.o
cc1: warnings being treated as errors
/home/source/qemu-kvm/hw/virtio-9p-local.c: In function
'local_utimensat': /home/source/qemu-kvm/hw/virtio-9p-local.c:479:
warning: implicit declaration of function 'utimensat'
/home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested
extern declaration of 'utimensat'
make[1]: *** [virtio-9p-local.o] Error 1
make: *** [subdir-libhw64] Error 2
Best Regards,
Xudong Hao
It seems that this issue is caused by the old glibc.
Though I don't know well about virtio-9p and suppose there
should be better fix, I confirmed that following change
removed the warnings.
Thanks,
H.Seto
=
[PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT
This removes following warnings on RHEL5, which has utimensat syscall
but has old glibc that doesn't have support for it:
hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function
'utimensat' hw/virtio-9p-local.c:479: warning: nested extern
declaration of 'utimensat'
and
hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
reported only once hw/virtio-9p.c:1410: error: for each function it
appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in
this function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in
this function)
Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
---
hw/virtio-9p-local.c |8
hw/virtio-9p.c |9 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 57f9243..e075c27 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -18,6 +18,9 @@
#include sys/socket.h
#include sys/un.h
#include attr/xattr.h
+#ifndef CONFIG_UTIMENSAT
+#include syscall.h
+#endif
static const char *rpath(FsContext *ctx, const char *path)
{
@@ -476,7 +479,12 @@ static int local_chown(FsContext *fs_ctx, const
char *path, FsCred *credp) static int local_utimensat(FsContext *s,
const char *path, const struct timespec *buf)
{
+#ifndef CONFIG_UTIMENSAT
+return syscall(SYS_utimensat, AT_FDCWD, rpath(s, path), buf,
+ AT_SYMLINK_NOFOLLOW);
+#else
return utimensat(AT_FDCWD, rpath(s, path), buf,
AT_SYMLINK_NOFOLLOW); +#endif
}
static int local_remove(FsContext *ctx, const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 32fa3bc..efe5c51 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1393,6 +1393,15 @@ out:
qemu_free(vs);
}
+#ifndef CONFIG_UTIMENSAT
+#ifndef UTIME_NOW
+# define UTIME_NOW ((1l 30) - 1l)
+#endif
+#ifndef UTIME_OMIT
+# define UTIME_OMIT ((1l 30) - 2l)
+#endif
+#endif
+
static void v9fs_setattr_post_chmod(V9fsState *s, V9fsSetattrState
*vs, int err) {
if (err == -1) {
Seto, your patch works fine for me, verified on my RHEL5 system.
Thanks,
Xudong
[Qemu-devel] qemu-kvm build issue on RHEL5.1
Hi, Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can pass on Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system? Gcc: 4.1.2 system: RHEL5.1 qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd ... LINK qemu-img LINK qemu-io CClibhw64/virtio-9p-local.o cc1: warnings being treated as errors /home/source/qemu-kvm/hw/virtio-9p-local.c: In function 'local_utimensat': /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat' /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat' make[1]: *** [virtio-9p-local.o] Error 1 make: *** [subdir-libhw64] Error 2 Best Regards, Xudong Hao
[Qemu-devel] RE: [PATCH] ivshmem: remove unnecessary checks for unsigned
Avi Kivity wrote: On 09/03/2010 05:54 AM, Hidetoshi Seto wrote: Oops, since I've registered qemu-kvm ML but not qemu-devel ML, I could not noticed that Jes have already posted same patch to qemu-devel. Now build of ivshmem is enabled only on KVM systems, please apply this patch to qemu-kvm.git asap. This was already applied to qemu.git; I'll pull it into qemu-kvm.git to fix the build. Qemu-kvm 6ee63ef38696aa3b0518f6aa6b85bc111ba7ca4e can build successfully now, thanks all. -Xudong
[Qemu-devel] RE: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
There is no need to check for dest 0 or vector = 0 as both are
uint16_t.
This should fix problems with broken build with aggressive compiler
flags. Reported by Xudong Hao xudong@intel.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
hw/ivshmem.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index bbb5cba..afebbc3 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -199,13 +199,13 @@ static void ivshmem_io_writel(void *opaque,
target_phys_addr_t addr,
case DOORBELL:
/* check that dest VM ID is reasonable */
-if ((dest 0) || (dest s-max_peer)) {
+if (dest s-max_peer) {
IVSHMEM_DPRINTF(Invalid destination VM ID (%d)\n,
dest); break;
}
/* check doorbell range */
-if ((vector = 0) (vector
s-peers[dest].nb_eventfds)) { +if (vector
s-peers[dest].nb_eventfds) {
IVSHMEM_DPRINTF(Writing % PRId64 to VM %d on
vector %d\n, write_one, dest, vector); if
(write(s-peers[dest].eventfds[vector],
This patch works for me.
Thanks,
Xudong
[Qemu-devel] RE: [PATCH] hw/ivshmem.c don't check for negative values on unsigned data types
Hao, Xudong wrote:
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
There is no need to check for dest 0 or vector = 0 as both are
uint16_t.
This should fix problems with broken build with aggressive compiler
flags. Reported by Xudong Hao xudong@intel.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com ---
hw/ivshmem.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index bbb5cba..afebbc3 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -199,13 +199,13 @@ static void ivshmem_io_writel(void *opaque,
target_phys_addr_t addr,
case DOORBELL:
/* check that dest VM ID is reasonable */
-if ((dest 0) || (dest s-max_peer)) {
+if (dest s-max_peer) {
IVSHMEM_DPRINTF(Invalid destination VM ID (%d)\n,
dest); break;
}
/* check doorbell range */
-if ((vector = 0) (vector
s-peers[dest].nb_eventfds)) { +if (vector
s-peers[dest].nb_eventfds) {
IVSHMEM_DPRINTF(Writing % PRId64 to VM %d on
vector %d\n, write_one, dest, vector); if
(write(s-peers[dest].eventfds[vector],
This patch works for me.
Jes, correct result is this patch works for me on x86_64 system. However, in
i386 system, there is another bug:
...
CCx86_64-softmmu/ivshmem.o
CCx86_64-softmmu/fpu/softfloat-native.o
CCx86_64-softmmu/op_helper.o
cc1: warnings being treated as errors
/home/build/gitrepo/qemu/hw/ivshmem.c: In function 'check_shm_size.
/home/build/gitrepo/qemu/hw/ivshmem.c:357: warning: format '%ld' expects type
'long int', but argt 5 has type '__off64_t
make[1]: *** [ivshmem.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [subdir-x86_64-softmmu] Error 2
Thanks,
Xudong
[Qemu-devel] RE: [qemu-kvm] build fail on i386 RHEL5u4
Avi Kivity wrote: On 08/16/2010 11:46 AM, Avi Kivity wrote: On 08/16/2010 04:27 AM, Hao, Xudong wrote: Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Should be easy to add a ./configure test for this. Or, just use --extra-cflags=-march=i686 or similar. Yes, both of two methods can work. Thanks, Xudong
[Qemu-devel] RE: [qemu-kvm] build fail on i386 RHEL5u4
Avi Kivity wrote: On 08/11/2010 04:49 AM, Hao, Xudong wrote: Hi, Recently I build qemu-kvm on 32bit RHEL5u4/RHEL5u5, it will fail on fuction vhost_dev_sync_region. But RHEL5u1 system is fine to build. Did anyone meet similar issue? qemu-kvm commit: 59d71ddb432db04b57ee2658ce50a3e35d7db97e build error: ... CCx86_64-softmmu/i8254.o CCx86_64-softmmu/i8254-kvm.o CCx86_64-softmmu/device-assignment.o LINK x86_64-softmmu/qemu-system-x86_64 vhost.o: In function `vhost_dev_sync_region': /home/source/qemu-kvm/hw/vhost.c:47: undefined reference to `__sync_fetch_and_and_4' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Thanks, Xudong
[Qemu-devel] [qemu-kvm] build fail on i386 RHEL5u4
Hi, Recently I build qemu-kvm on 32bit RHEL5u4/RHEL5u5, it will fail on fuction vhost_dev_sync_region. But RHEL5u1 system is fine to build. Did anyone meet similar issue? qemu-kvm commit: 59d71ddb432db04b57ee2658ce50a3e35d7db97e build error: ... CCx86_64-softmmu/i8254.o CCx86_64-softmmu/i8254-kvm.o CCx86_64-softmmu/device-assignment.o LINK x86_64-softmmu/qemu-system-x86_64 vhost.o: In function `vhost_dev_sync_region': /home/source/qemu-kvm/hw/vhost.c:47: undefined reference to `__sync_fetch_and_and_4' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Best Regards, Xudong Hao
[Qemu-devel] [Bug 599617] Re: qemu fail to parse command -net none
This issue has gone with qemu-kvm commit d4adede84de96d631f2c6eff2c01eae00b14a110. ** Changed in: qemu Status: Invalid = Fix Released ** Changed in: qemu-kvm (Ubuntu) Status: Triaged = Fix Released -- qemu fail to parse command -net none https://bugs.launchpad.net/bugs/599617 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -net none to boot up a guest, guest cannot boot up. and no error message displayed.
[Qemu-devel] [Bug 597932] Re: qemu fail to parse command line with -pcidevice B:D.F
Now we use new command to do VT-d device assignment: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -device pci-assign,host=00:19.0 ** Changed in: qemu Status: New = Fix Released -- qemu fail to parse command line with -pcidevice B:D.F https://bugs.launchpad.net/bugs/597932 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Hardware:Gulftown-HEDT Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest, guest cannot boot up, and display error message: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 It's caused by commit: b560a9ab9be06afcbb78b3791ab836dad208a239. It took 00:19.0 alike form as illegal. Reproduce steps: 1. boot up into host 2. use pcistub hide a nic: #sh pcistub.sh -h 00:19.0 3. when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest
[Qemu-devel] [Bug 599617] [NEW] qemu fail to parse command -net none
Public bug reported: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -net none to boot up a guest, guest cannot boot up. and no error message displayed. ** Affects: qemu Importance: Undecided Status: New -- qemu fail to parse command -net none https://bugs.launchpad.net/bugs/599617 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -net none to boot up a guest, guest cannot boot up. and no error message displayed.
[Qemu-devel] [Bug 599617] Re: qemu fail to parse command -net none
qemu upstream has fix patch:
Signed-off-by: Amit Shah amit.s...@redhat.com
---
net.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 4cb93ed..b681233 100644
--- a/net.c
+++ b/net.c
@@ -1119,7 +1119,7 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
vlan = qemu_find_vlan(qemu_opt_get_number(opts, vlan, 0), 1);
}
-ret = -1;
+ret = 0;
if (net_client_types[i].init) {
ret = net_client_types[i].init(opts, mon, name, vlan);
if (ret 0) {
--
qemu fail to parse command -net none
https://bugs.launchpad.net/bugs/599617
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Host OS:ia32e
Guest OS :32e and pae
kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2
qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9
Host Kernel Version:2.6.35-rc3
Bug detailed description:
--
when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -net none
to boot up a guest, guest cannot boot up. and no error message displayed.
[Qemu-devel] RE: qemu fail to parse command line with -pcidevice 00:19.0
Thanks, Mark. -Original Message- From: Markus Armbruster [mailto:arm...@redhat.com] Sent: 2010年6月25日 12:58 To: Hao, Xudong Cc: qemu-devel@nongnu.org; aligu...@us.ibm.com; k...@vger.kernel.org Subject: Re: qemu fail to parse command line with -pcidevice 00:19.0 Hao, Xudong xudong@intel.com writes: Work-around: -device pci-assign,host=00:19.1 OK, this new way can work when create guest with static assignment. But how to hot add a pci device to guest? the old hot add command pci_add pci_addr=auto host host=00:19.0 has the same parse error. Command line's -device becomes monitor's device_add: device_add pci-assign,host=00:19.1 BTW: if we use add -net none in qemu command, guest can not be created and nothing error printed. Do you have plan to fix this parse issue? Separate issue. Fix posted: Subject: [Qemu-devel] [PATCH] net: Fix VM start with '-net none' Date: Tue, 15 Jun 2010 13:30:39 +0530 Message-Id: 22a96312232a0458fc04268b79d17828c824df42.1276588830.git.amit.s...@redhat.com You could have found this yourself :)
[Qemu-devel] RE: qemu fail to parse command line with -pcidevice 00:19.0
Work-around: -device pci-assign,host=00:19.1 OK, this new way can work when create guest with static assignment. But how to hot add a pci device to guest? the old hot add command pci_add pci_addr=auto host host=00:19.0 has the same parse error. BTW: if we use add -net none in qemu command, guest can not be created and nothing error printed. Do you have plan to fix this parse issue? Thanks, Xudong -Original Message- From: Markus Armbruster [mailto:arm...@redhat.com] Sent: 2010年6月24日 14:08 To: Hao, Xudong Cc: qemu-devel@nongnu.org; aligu...@us.ibm.com; k...@vger.kernel.org Subject: Re: qemu fail to parse command line with -pcidevice 00:19.0 Note to qemu-devel: this issue is qemu-kvm only. Hao, Xudong xudong@intel.com writes: When assign one PCI device, qemu fail to parse the command line: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 Error: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 https://bugs.launchpad.net/qemu/+bug/597932 This issue caused by qemu-kvm commit b560a9ab9be06afcbb78b3791ab836dad208a239. The bug is in add_assigned_device(): r = get_param_value(id, sizeof(id), id, arg); if (!r) r = get_param_value(id, sizeof(id), name, arg); if (!r) r = get_param_value(id, sizeof(id), host, arg); We end up with invalid ID 00:19.0. Is there a technical reason why we must have an ID? I doubt it. Work-around: -device pci-assign,host=00:19.1 See the last section of docs/qdev-device-use.txt for details.
[Qemu-devel] [Bug 592056] Re: qemu segmentation fault when create qcow2 image with qemu-img command
This bug has been fixed on commit:
kvm-commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2, qemu-kvm
commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9.
qcow.img file can be created by qemu-img successfully.
fixed patch:
diff --git a/qemu-option.c b/qemu-option.c
index acd74f9..f884865 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -378,6 +378,7 @@ QEMUOptionParameter
*append_option_parameters(QEMUOptionParameter *dest,
num_options += count_option_parameters(list);
dest = qemu_realloc(dest, (num_options + 1) *
sizeof(QEMUOptionParameter));
+dest[num_dest_options].name = NULL;
while (list list-name) {
if (get_option_parameter(dest, list-name) == NULL) {
--
qemu segmentation fault when create qcow2 image with qemu-img command
https://bugs.launchpad.net/bugs/592056
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Host OS: ia32e
kvm.git Commit:cf18597a046413e9f0dd8df3ad6715a88766be51
qemu-kvm Commit:3f505ec990599aeb960ed7031a2bb7b233ea4927
Host Kernel Version:2.6.35-rc2+
Hardware:Westmere-HEDT
Bug detailed description:
--
when use qemu-img command to create qcow image, segmentation fault will
happen.
dmesg: qemu-img[1883] general protection ip:32f0477d20 sp:7fff9c89b308
error:0 in libc-2.5.so[32f040+14a000]
Bisected commit ea25559830a1a025e534dea634158c0141c71894 in qemu-kvm tree bring
up this
issue.
Reproduce steps:
1.boot up into KVM ia32e host
2.use command: qemu-img create -b /path/to/file.img -f qcow2 /path/to/qcow.img
3.it displays: segmentation fault
[Qemu-devel] [Bug 597932] [NEW] qemu fail to parse command line with -pcidevice B:D.F
Public bug reported: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Hardware:Gulftown-HEDT Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest, guest cannot boot up, and display error message: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 It's caused by commit: b560a9ab9be06afcbb78b3791ab836dad208a239. It took 00:19.0 alike form as illegal. Reproduce steps: 1. boot up into host 2. use pcistub hide a nic: #sh pcistub.sh -h 00:19.0 3. when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest ** Affects: qemu Importance: Undecided Status: New -- qemu fail to parse command line with -pcidevice B:D.F https://bugs.launchpad.net/bugs/597932 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Hardware:Gulftown-HEDT Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest, guest cannot boot up, and display error message: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 It's caused by commit: b560a9ab9be06afcbb78b3791ab836dad208a239. It took 00:19.0 alike form as illegal. Reproduce steps: 1. boot up into host 2. use pcistub hide a nic: #sh pcistub.sh -h 00:19.0 3. when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest
[Qemu-devel] qemu fail to parse command line with -pcidevice 00:19.0
When assign one PCI device, qemu fail to parse the command line: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 Error: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 https://bugs.launchpad.net/qemu/+bug/597932 This issue caused by qemu-kvm commit b560a9ab9be06afcbb78b3791ab836dad208a239. Best Regards, Xudong Hao
[Qemu-devel] [Bug 592056] Re: qemu segmentation fault when create qcow2 image with qemu-img command
** Changed in: qemu Status: New = Fix Committed -- qemu segmentation fault when create qcow2 image with qemu-img command https://bugs.launchpad.net/bugs/592056 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Committed Bug description: Host OS: ia32e kvm.git Commit:cf18597a046413e9f0dd8df3ad6715a88766be51 qemu-kvm Commit:3f505ec990599aeb960ed7031a2bb7b233ea4927 Host Kernel Version:2.6.35-rc2+ Hardware:Westmere-HEDT Bug detailed description: -- when use qemu-img command to create qcow image, segmentation fault will happen. dmesg: qemu-img[1883] general protection ip:32f0477d20 sp:7fff9c89b308 error:0 in libc-2.5.so[32f040+14a000] Bisected commit ea25559830a1a025e534dea634158c0141c71894 in qemu-kvm tree bring up this issue. Reproduce steps: 1.boot up into KVM ia32e host 2.use command: qemu-img create -b /path/to/file.img -f qcow2 /path/to/qcow.img 3.it displays: segmentation fault
RE: [Qemu-devel] [Bug 592056] [NEW] qemu segmentation fault when create qcow2 image with qemu-img command
BT: #0 0x0032f0477d20 in strcmp () from /lib64/libc.so.6 #1 0x004071bb in get_option_parameter (list=0x6447e0, name=0x432dc9 size) at qemu-option.c:162 #2 0x00408848 in append_option_parameters (dest=value optimized out, list=0x642460) at qemu-option.c:383 #3 0x00405143 in img_create (argc=6, argv=0x7fffa40081e0) at qemu-img.c:303 #4 0x0032f041d8b4 in __libc_start_main () from /lib64/libc.so.6 #5 0x00403099 in _start () --Xudong
[Qemu-devel] RE: [PATCH] qemu-option: Fix uninitialized value in append_option_parameter
Kevin, this patch works fine.
Kevin Wolf wrote:
When dest is NULL, i.e. a new copy of the list is created, we don't
get a
properly terminated list after the realloc. Initialize it as an empty
list.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
Xudong, can you please try this one? I think it should fix your
qemu-img
problem.
qemu-option.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index acd74f9..f884865 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -378,6 +378,7 @@ QEMUOptionParameter
*append_option_parameters(QEMUOptionParameter *dest, num_options
+= count_option_parameters(list);
dest = qemu_realloc(dest, (num_options + 1) *
sizeof(QEMUOptionParameter)); +dest[num_dest_options].name = NULL;
while (list list-name) {
if (get_option_parameter(dest, list-name) == NULL) {
[Qemu-devel] [Bug 592056] [NEW] qemu segmentation fault when create qcow2 image with qemu-img command
Public bug reported: Host OS: ia32e kvm.git Commit:cf18597a046413e9f0dd8df3ad6715a88766be51 qemu-kvm Commit:3f505ec990599aeb960ed7031a2bb7b233ea4927 Host Kernel Version:2.6.35-rc2+ Hardware:Westmere-HEDT Bug detailed description: -- when use qemu-img command to create qcow image, segmentation fault will happen. dmesg: qemu-img[1883] general protection ip:32f0477d20 sp:7fff9c89b308 error:0 in libc-2.5.so[32f040+14a000] Bisected commit ea25559830a1a025e534dea634158c0141c71894 in qemu-kvm tree bring up this issue. Reproduce steps: 1.boot up into KVM ia32e host 2.use command: qemu-img create -b /path/to/file.img -f qcow2 /path/to/qcow.img 3.it displays: segmentation fault ** Affects: qemu Importance: Undecided Status: New -- qemu segmentation fault when create qcow2 image with qemu-img command https://bugs.launchpad.net/bugs/592056 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Host OS: ia32e kvm.git Commit:cf18597a046413e9f0dd8df3ad6715a88766be51 qemu-kvm Commit:3f505ec990599aeb960ed7031a2bb7b233ea4927 Host Kernel Version:2.6.35-rc2+ Hardware:Westmere-HEDT Bug detailed description: -- when use qemu-img command to create qcow image, segmentation fault will happen. dmesg: qemu-img[1883] general protection ip:32f0477d20 sp:7fff9c89b308 error:0 in libc-2.5.so[32f040+14a000] Bisected commit ea25559830a1a025e534dea634158c0141c71894 in qemu-kvm tree bring up this issue. Reproduce steps: 1.boot up into KVM ia32e host 2.use command: qemu-img create -b /path/to/file.img -f qcow2 /path/to/qcow.img 3.it displays: segmentation fault
RE: [Qemu-devel] [Bug 592056] [NEW] qemu segmentation fault when create qcow2 image with qemu-img command
The commit dafac85ed4f43d694c1b438ec6d14e18d225e600 works fine, I git diff the two dafac85ed4f43d694c1b438ec6d14e18d225e600 and ea25559830a1a025e534dea634158c0141c71894, and revert qemu-img.c to dafac85ed4f43d694c1b438ec6d14e18d225e600 , then everything is OK. Thanks, Xudong -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: 2010年6月10日 16:59 To: Bug 592056 Cc: Hao, Xudong; qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [Bug 592056] [NEW] qemu segmentation fault when create qcow2 image with qemu-img command Am 10.06.2010 09:41, schrieb xudong: when use qemu-img command to create qcow image, segmentation fault will happen. dmesg: qemu-img[1883] general protection ip:32f0477d20 sp:7fff9c89b308 error:0 in libc-2.5.so[32f040+14a000] Bisected commit ea25559830a1a025e534dea634158c0141c71894 in qemu-kvm tree bring up this issue. Can you please provide a backtrace? I couldn't reproduce this in a quick attempt, so I can't get it myself.
