From: Andrea Bolognani <abologna@redhat.com>
To: Andrew Jones <drjones@redhat.com>, Kevin Zhao <kevin.zhao@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
Thomas Hanson <thomas.hanson@linaro.org>,
Peter Maydell <peter.maydell@linaro.org>,
Gema Gomez-Solano <gema.gomez-solano@linaro.org>,
Marcel Apfelbaum <mapfelba@redhat.com>,
Laine Stump <lstump@redhat.com>
Subject: Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?
Date: Wed, 17 Aug 2016 18:41:33 +0200 [thread overview]
Message-ID: <1471452093.3820.42.camel@redhat.com> (raw)
In-Reply-To: <20160817161303.jdglwirs522vn2wa@kamzik.localdomain>
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.
> 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
Isn't the default for 2.6 disable-modern=off,
disable-legacy=off? Or was that 2.7? I tried both anyway ;)
--
Andrea Bolognani / Red Hat / Virtualization
next prev parent reply other threads:[~2016-08-17 16:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 12:08 [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device? Kevin Zhao
2016-08-17 16:13 ` Andrew Jones
2016-08-17 16:41 ` Andrea Bolognani [this message]
2016-08-18 6:38 ` Andrew Jones
2016-08-19 15:43 ` Andrea Bolognani
2016-08-19 17:51 ` Laine Stump
2016-08-17 17:00 ` Laine Stump
2016-08-18 7:41 ` Andrew Jones
2016-08-18 21:11 ` Laine Stump
2016-08-18 12:10 ` Marcel Apfelbaum
2016-08-18 21:20 ` Laine Stump
2016-08-18 12:43 ` Kevin Zhao
2016-08-18 13:51 ` Andrea Bolognani
2016-08-24 1:52 ` Kevin Zhao
2016-09-08 6:50 ` Kevin Zhao
2016-08-18 21:26 ` Laine Stump
2016-08-18 12:30 ` Kevin Zhao
2016-08-18 12:51 ` Kevin Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1471452093.3820.42.camel@redhat.com \
--to=abologna@redhat.com \
--cc=drjones@redhat.com \
--cc=gema.gomez-solano@linaro.org \
--cc=kevin.zhao@linaro.org \
--cc=lstump@redhat.com \
--cc=mapfelba@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thomas.hanson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).