Linux Virtualization - May 2011 - [PATCH 3/3] powerpc-virtio: virtio support introduced (block, network, serial, balloon, 9p-fs), both fullemu and power-kvm

On 17.05.2011, at 08:47, David Gibson wrote:
> From: Alexey Kardashevskiy <aik at ozlabs.ru>
> 
> The recently added pseries machine does not currently support PCI
> emulation.  For the (upcoming) kvm case, this is quite difficult to do
> because the preferred HV mode for the host kernel does not allow MMIO
> emulation (a hardware limitation).
> 
> Therefore, to support virtio devices, we implement a new virtio setup
> protocol for PAPR guests.  This is based loosely on the s390 and lguest
> methods, using the PAPR hcalls for the virtio primitive operations,
> and the PAPR device tree to advertise the virtio device resources to the
> guest.
> 
> This patch includes support for the virtio block, network, serial, and
> balloon devices, and the 9p filesystem.
> 
> The guest linux kernel should be updated as well in order to
> support a new virtio setup.
> 
> Supported devices are (below are QEMU command line switches):
> 
> - virtio-blk - block device, at the moment works as "IDE":
>    usage: -drive file=test-virtio-blk.img,if=ide
> 
> - virtio-net - network device
>    usage: -net nic,model=virtio-net
> 
> - virtio-balloon - memory hot-swap device (at the moment of commit,
power-kvm
> did not support balloon)
>    usage: -device virtio-balloon-spapr
> 
> - virtio-serial - serial bus controller
>    usage: -device virtio-serial-spapr \
>           -chardev socket,id=CONSOLE,host=localhost,port=4444,server,telnet
\
>           -device virtconsole,chardev=CONSOLE
>    The first switch tells QEMU to create a serial bus device and next
>    2 switches create "chardev" and virtual console device
connected to
>    that "chardev".
> 
> - virtio-9p - plan9 filesystem with ability to work over virtio transport
>    usage: -fsdev fstype=local,id=TAG,path=/home/aik/,security_model=none \
>           -device virtio-9p-spapr,fsdev=TAG,mount_tag=TAG
>    where TAG is a tag which should be used later when mounting is linux as:
>           mount -t 9p -o trans=virtio TAG /mnt
> 
>    Configure for full emulation as:
>       ./configure --target-list=ppc64-softmmu --enable-attr
> 
>    Configure for power-kvm as:
>       ./configure --enable-kvm  --target-list=ppc64-softmmu --enable-fdt \
>                    --cc="gcc -m64" \
>                    --kerneldir=/root/kheaders --enable-io-thread
--enable-attr
> 
> Note: --enable-attr is required for 9p support. On ppc64 systems, libattr
> should be compiled and installed manually as it is not distributes in
> 64bit packages.
Before including such a patch, we should really discuss the desired interface
for virtio on sPAPR. I personally would prefer if we could have a generic MMIO
hypercall that the guest issues, so that we can simply use virtio-pci on sPAPR
(and all the other PCI hardware).

But at the end of the day, the steps should be as follows:

  1) Discuss this on the virtualization ML
  2) Send patches for the virtio documentation so the protocol has a spec (which
we're lacking for s390 still)
  3) Implement Linux side, upstream it
  4) Upstream Qemu side

Since I haven't seen 1-3, I'd like to defer this patch until the other
points are good :)


Alex

On Tue, May 17, 2011 at 09:06:41AM +0200, Alexander Graf
wrote:
> On 17.05.2011, at 08:47, David Gibson wrote:
> > From: Alexey Kardashevskiy <aik at ozlabs.ru>
> > 
> > The recently added pseries machine does not currently support PCI
> > emulation.  For the (upcoming) kvm case, this is quite difficult to do
> > because the preferred HV mode for the host kernel does not allow MMIO
> > emulation (a hardware limitation).
> > 
> > Therefore, to support virtio devices, we implement a new virtio setup
> > protocol for PAPR guests.  This is based loosely on the s390 and
lguest
> > methods, using the PAPR hcalls for the virtio primitive operations,
> > and the PAPR device tree to advertise the virtio device resources to
the
> > guest.
> > 
> > This patch includes support for the virtio block, network, serial, and
> > balloon devices, and the 9p filesystem.
[snip]
> 
> Before including such a patch, we should really discuss the desired
> interface for virtio on sPAPR. I personally would prefer if we could
> have a generic MMIO hypercall that the guest issues, so that we can
> simply use virtio-pci on sPAPR (and all the other PCI hardware).
Hrm.  I'm not thrilled at that idea.  We would still need to advertise
in the device tree to use the MMIO hypercall, instead of going direct
- since we will be going direct for things like passthrough PCI
devices under KVM.
> But at the end of the day, the steps should be as follows:
> 
>   1) Discuss this on the virtualization ML
Ok, which list do you mean here?
>   2) Send patches for the virtio documentation so the protocol has a spec
(which we're lacking for s390 still)
>   3) Implement Linux side, upstream it
I don't see why the Linux guest side needs to go before the qemu
side.  You can't use one without the other, so there's no clear order.
>   4) Upstream Qemu side
> 
> Since I haven't seen 1-3, I'd like to defer this patch until the
> other points are good :)
Hmm.  I'll see what I can do.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On Wed, May 18, 2011 at 01:27:45PM +1000, David Gibson
wrote:
> On Tue, May 17, 2011 at 09:06:41AM +0200, Alexander Graf wrote:
> > On 17.05.2011, at 08:47, David Gibson wrote:
> > > From: Alexey Kardashevskiy <aik at ozlabs.ru>
> > > 
> > > The recently added pseries machine does not currently support PCI
> > > emulation.  For the (upcoming) kvm case, this is quite difficult
to do
> > > because the preferred HV mode for the host kernel does not allow
MMIO
> > > emulation (a hardware limitation).
> > > 
> > > Therefore, to support virtio devices, we implement a new virtio
setup
> > > protocol for PAPR guests.  This is based loosely on the s390 and
lguest
> > > methods, using the PAPR hcalls for the virtio primitive
operations,
> > > and the PAPR device tree to advertise the virtio device resources
to the
> > > guest.
> > > 
> > > This patch includes support for the virtio block, network,
serial, and
> > > balloon devices, and the 9p filesystem.
> [snip]
> > 
> > Before including such a patch, we should really discuss the desired
> > interface for virtio on sPAPR. I personally would prefer if we could
> > have a generic MMIO hypercall that the guest issues, so that we can
> > simply use virtio-pci on sPAPR (and all the other PCI hardware).
> 
> Hrm.  I'm not thrilled at that idea.  We would still need to advertise
> in the device tree to use the MMIO hypercall, instead of going direct
> - since we will be going direct for things like passthrough PCI
> devices under KVM.
> 
> > But at the end of the day, the steps should be as follows:
> > 
> >   1) Discuss this on the virtualization ML
> 
> Ok, which list do you mean here?
> 
> >   2) Send patches for the virtio documentation so the protocol has a
spec (which we're lacking for s390 still)
> >   3) Implement Linux side, upstream it
> 
> I don't see why the Linux guest side needs to go before the qemu
> side.  You can't use one without the other, so there's no clear
order.
Agree here. I would further argue qemu should go in first,
this is what happens with real devices: first hardware, then
driver. Linux side just needs to be ready and available in the repository
somewhere.
> >   4) Upstream Qemu side
> > 
> > Since I haven't seen 1-3, I'd like to defer this patch until
the
> > other points are good :)
> 
> Hmm.  I'll see what I can do.
> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson

On 18.05.2011, at 05:27, David Gibson wrote:
> On Tue, May 17, 2011 at 09:06:41AM +0200, Alexander Graf wrote:
>> On 17.05.2011, at 08:47, David Gibson wrote:
>>> From: Alexey Kardashevskiy <aik at ozlabs.ru>
>>> 
>>> The recently added pseries machine does not currently support PCI
>>> emulation.  For the (upcoming) kvm case, this is quite difficult to
do
>>> because the preferred HV mode for the host kernel does not allow
MMIO
>>> emulation (a hardware limitation).
>>> 
>>> Therefore, to support virtio devices, we implement a new virtio
setup
>>> protocol for PAPR guests.  This is based loosely on the s390 and
lguest
>>> methods, using the PAPR hcalls for the virtio primitive operations,
>>> and the PAPR device tree to advertise the virtio device resources
to the
>>> guest.
>>> 
>>> This patch includes support for the virtio block, network, serial,
and
>>> balloon devices, and the 9p filesystem.
> [snip]
>> 
>> Before including such a patch, we should really discuss the desired
>> interface for virtio on sPAPR. I personally would prefer if we could
>> have a generic MMIO hypercall that the guest issues, so that we can
>> simply use virtio-pci on sPAPR (and all the other PCI hardware).
> 
> Hrm.  I'm not thrilled at that idea.  We would still need to advertise
> in the device tree to use the MMIO hypercall, instead of going direct
> - since we will be going direct for things like passthrough PCI
> devices under KVM.
Yes, it's not an easy thing to solve. But not having the chance of emulating
MMIO robs you off quite some possibilities and reimplementing yet another host
abstraction layer for virtio will be more headaches than you can imagine :).
> 
>> But at the end of the day, the steps should be as follows:
>> 
>>  1) Discuss this on the virtualization ML
> 
> Ok, which list do you mean here?
The one I CC'ed :)
> 
>>  2) Send patches for the virtio documentation so the protocol has a
spec (which we're lacking for s390 still)
>>  3) Implement Linux side, upstream it
> 
> I don't see why the Linux guest side needs to go before the qemu
> side.  You can't use one without the other, so there's no clear
order.
Well, ok. I'd at least like to see the Linux side on the mailing list then
before pulling the qemu side :).
> 
>>  4) Upstream Qemu side
>> 
>> Since I haven't seen 1-3, I'd like to defer this patch until
the
>> other points are good :)
> 
> Hmm.  I'll see what I can do.
Thanks!

Alex