On Wed, Aug 17, 2016 at 06:41:33PM +0200, Andrea Bolognani wrote: > On Wed, 2016-08-17 at 18:13 +0200, 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 Zhao > > > > libvirt 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. > > Debian 8, the guest OS Kevin is trying to boot, is even older, > and in particular it doesn't have any virtio-pci support. > > By the way, the same issue was raised on the libvirt list as > well > > https://www.redhat.com/archives/libvir-list/2016-August/msg00854.html > > and there's some more information there. > > > 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) > > 2) root complex ports, switches (upstream/downstream ports) are currently > > based on Intel parts. Marcel is thinking about creating generic models. > > Huge +1 from me! Way to go, Marcel! :) > > > 3) libvirt needs to learn how to plug everything together, in proper PCIe > > fashion, leaving holes for hotplug. > > Work on this front is ongoing on the libvirt front as we speak. > > > 4) Probably more... I forget all the different issues we discovered when > > we started playing with this a few months ago. > > > > The good news is that x86 folk want all the same things for the q35 model. > > mach-virt enthusiasts like us get to ride along pretty much for free. > > > > So, using virtio-pci with mach-virt and libvirt isn't possible right now, > > not without manual changes to the XML. It might be nice to document how to > > manually convert a guest, so developers who want to use virtio-pci don't > > have to abandon libvirt. I'd have to look into that, or ask one of our > > libvirt friends to help. Certainly the instructions would be for latest > > libvirt though. > > Things are very much in flux, though, so I'm not entirely sure > putting out any sort of official document would be a good idea > right now. We'll definitely help eg. through the mailing lists > and similar channels, but committing any configuration to a > more static media seems premature.
Understood, and based on Laine's response, things are looking just around the corner now anyway, so forget I asked :-) > > > Finally, FWIW, with a guest kernel of 4.6.4-301.fc24.aarch64. The > > following qemu command line works for me. > > (notice the use of PCIe), and my network interface gets labeled enp0s1. > > > > $QEMU -machine virt-2.6,accel=kvm -cpu host \ > > -m 1024 -smp 1 -nographic \ > > -bios /usr/share/AAVMF/AAVMF_CODE.fd \ > > -device ioh3420,bus=pcie.0,id=pcie.1,port=1,chassis=1 \ > > -device ioh3420,bus=pcie.0,id=pcie.2,port=2,chassis=2 \ > > -device > >virtio-scsi-pci,disable-modern=off,disable-legacy=on,bus=pcie.1,addr=00.0,id=scsi0 > > \ > > -drive > >file=/home/drjones/.local/libvirt/images/fedora.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 > > \ > > -device > >scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 > > \ > > -netdev user,id=hostnet0 \ > > -device > >virtio-net-pci,disable-modern=off,disable-legacy=on,bus=pcie.2,addr=00.0,netdev=hostnet0,id=net0 > > > > I prefer always using virtio-scsi for the disk, but a similar command > > line can be used for a virtio-blk-pci disk. > > Does the same command line work if you don't specify any of > the disable-* options? > > I'm asking because I tried running a Fedora 24 guest through > libvirt, which doesn't support those options yet, and I get > > virtio_blk virtio2: virtio: device uses modern interface but > does not have VIRTIO_F_VERSION_1 > virtio_blk: probe of virtio2 failed with error -22 Doesn't work for me either. I can only boot with disable-modern=off, disable-legacy=on (at least when building my config the way I try to build it...) I presume that's a guest kernel issue. > > Isn't the default for 2.6 disable-modern=off, > disable-legacy=off? Or was that 2.7? I tried both anyway ;) Dunno. With the command line getting longer all the time, I just have a script that generates one that works for me, and haven't worried much about the defaults... Thanks, drew
