|
From: | Laine Stump |
Subject: | Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device? |
Date: | Thu, 18 Aug 2016 17:26:39 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 |
On 08/18/2016 08:43 AM, Kevin Zhao wrote:
Hi Laine, Thanks :-) I also has a little questions below. On 18 August 2016 at 01:00, Laine Stump <address@hidden> wrote:On 08/17/2016 12:13 PM, Andrew Jones wrote:On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote:Hi all, Now I'm investigating net device hot plug and disk hotplug for AArch64. For virtio , the default address is virtio-mmio. After Libvirt 1.3.5, user can explicitly specify the address-type to pci and so libvirt will pass the virtio-pci parameters to the Qemu. Both my host and guest OS is Debian8, and Qemu version is 2.6.0. Libvirt version is 1.3.5. For net-device, I change the address-type to pci, and libvirt pass the command below: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:25: 25,bus=pci.2,addr=0x1 After booting, the eth0 device disappear(eth0 occur when the address is virtio-mmio), but I can find another net-device enp2s1, also it can't work for dhcp: Running lspci: 02:01.0 Ethernet controller: Red Hat, Inc Virtio network device I'm not sure whether it worked. For disk device,* when I change the address-type to pci, the whole qemu command is :* https://paste.fedoraproject.org/409553/, but the VM can not boot successfully. Does Qemu not support device disk of virtio-pci in AArch64 just as it in X86_64? Thanks~Since I am not very familiar with Qemu, really looking forward to your response. Best Regards, Kevin Zhaolibvirt 1.3.5 is a bit old. Later versions no longer unconditionally add the i82801b11 bridge, which was necessary to use PCI devices with the PCIe host bridge mach-virt has. IMO, libvirt and qemu still have a long way to go in order to configure a base/standard mach-virt PCIe machine.Well, you can do it now, but you have to manually assign the PCI addresses of devices (and if you want hotplug you need to live with Intel/TI-specific PCIe controllers).OK. It seems that Qemu will drop PCI for machine-virt and turning to PCIE in the future.
This isn't a qemu issue, but a libvirt issue.
Do I need to do more for Intel/TI-specific PCIe controllers?
what do I need to add in the guest XML or more?
As soon as my first set of patches is pushed, what you'll need to do is to add:
<controller type='pci' model='pcie-root-port'/> for each virtio device.As soon as I've figured out a useful algorithm for adding the pcie controllers automatically, you won't need to do anything at all. (Keep in mind that any existing configurations will maintain their original config. If you want an existing configuration to be switched to using the new recommended (pcie) bus topology you will need to replace every instance of:
<address type='pci' domain='0x0000' ......../> with a plain: <address type='pci'/> This will force libvirt to reassign PCI addresses for the devices.
1) If we want to support both PCIe devices and PCI, then things are messy. Currently we propose dropping PCI support. mach-virt pretty much exclusively uses virtio, which can be set to PCIe mode (virtio-1.0)I have a libvirt patch just about ACKed for pushing upstream that will automatically assign virtio-pci devices to a PCIe slot (if the qemu binary supports virtio-1.0): https://www.redhat.com/archives/libvir-list/2016-August/msg00852.htmlWhat's the minimum version of Qemu that support virito-1.0? Does Qemu 2.6 works?
qemu as old as 2.4.0 has the "--disable-legacy" option for virtio devices. I don't know if it was actually working properly back that far.
Also as I see your patch for automatically assign virtio-pci to PCIE slot,after it merged I think thing will go much more easier. Now I will manually add the slots and bus to pcie. Because I am not familiar with it, if it convenient, could you give me an available xml file which PCIE disk and PCIE net device can work for machine virt ?
I think Andrea sent an example.
[Prev in Thread] | Current Thread | [Next in Thread] |