Re: [Xen-devel] OASIS Virtual I/O Device (VIRTIO) TC

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Aug 27, 2013 at 11:37:41AM +0200, Daniel Kiper wrote:
[...]
> > Yes this is true.
> >
> > However the statement (?) in Daniel's first email (based upon the
> > "Virtio PCI Card Specification") gave me the impression that they
> > planned to support virtual PCI only...
> 
> Right, VIRTIO TC started its work on the base of "Virtio PCI Card 
> Specification".
> However, it was stated immediately that PCI specification should be excluded
> from main specification and should form a separate attachment. It means that
> VIRTIO would not require PCI bus in the future. Additionally, current document
> contains specification for MMIO which looks like good alternative for PCI.
> 
> > > virt_mmio instead these days. A shared ring for cfg + evtchn model for
> > > notification doesn't seem too far fetched to me.
> > >
> > > A far bigger problem IMHO with virtio is that it basically discards the
> > > Xen security model. I don't know how hard it will be to retrofit gnttab
> > > based access control into the virtio protocols. A lot would be my
> > > guess...
> 
> I am going to convince VIRTIO TC that new spec should be Xen friendly too.
> 
> > Indeed, seems there is lots of work to do...
> 
> By the way, Wei, Konrad told me that you worked on VRITIO implementation
> for Xen and you have hands-on-experience with it. Could you tell me what
> issues you met during your work on VRITIO support for Xen environment?
> 

I would not say I have very deep understanding of it because I only
worked on it part-time for two months. But I will try to best to
remember and elaborate. :-)

For HVM guests Virtio works just fine. Xen uses QEMU as device model
which means we have Virtio devices for free. In this case all Virtio
devices use virtual PCI bus provided by QEMU. Basically we get most of
the things for free.

(A recent email on netdev@ from an engineer in Huawei suggests that
virto-net + vhost-net works for him, which is really great. Ref: Is
fallback vhost_net to qemu for live migrate
availableï<521C1DCF.5090202@xxxxxxxxxx>)

For PV guests it requires more work. Virtio is designed to be portable.
The PCI and MMIO implementations your mentioned are in fact called
"transport". As PV guests don't have virtual PCI buses and MMIO don't
seem to work on Xen PV either (it's very possible that I'm wrong on this
MMIO thing as I'm not familiar with it), I had to implement a new
transport. TBH the biggest issue is more of an engineering problem --
virtual PCI is sync while Xen DomU and Dom0 run in prarallel.
The approach I chose back then was just a hack mimicking PCI
which made everything slow. It was not meant to be canonical or
upstreamable. If I were to do this now I would choose to apply the Xen
PV model to the transport.

To make the whole thing work we also need backend supporting Virtio. The
closest thing at hand was QEMU, but again, the transport had to be
re-implemented.

The hack is on http://wiki.xen.org/wiki/Virtio_On_Xen

Wei.

> Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel