[Xen Hackathon] new PV drivers

[Xen Hackathon] new PV drivers

[Stefano Stabellini]

Present (by memory):
- Julien Grall,
- Stefano Stabellini,
- Ian Campbell,
- Roger Pau Monne,
- Dario Faggioli,
- Andrii Tseglytskyi,
- David Vrabel,
- Konrad Wilk.

* What new PV devices do we need? What has been done already?
* Where should they live?


New PV Drivers, GlobalLogic has done:
- PV tiny-ALSA, very simple forwarding, backend in Linux, frontend is
  userspace, stand-alone. Could be in their own git tree on xenbits.
- Made old PV USB patches working, backend and frontend in Linux.
- Improved PVFB: do they use the backend in QEMU? Can be upstreamed?
- PV WPA supplicant, WIP with simple frontend and backend in Linux.

IPU support (TI). We need Remote Proc Framework working on Xen:
http://lwn.net/Articles/489009/
We need PV Remote Proc to have HD video reproduction in Android.
We could use an IOMMU to assign the IPU to the domU but the IPU is not
behind an IOMMU.
We could use a PV protocol to assign the IPU to one domain, using Remove
Proc to talk to the other DomU.
The PV protocol would be a simple protocol to assign the IPU to one
domain only.
Dom0 could allocate the initial memory for IPU, we are sure it is
contiguous in machine memory because it is mapped 1:1.
Dom0 need to translate the addresses on behalf of the guest.
A limited IOMMU is present between IPU and main memory. Dom0 could
program it with the memory for the IPU.

GPU support. At the moment GlobalLogic is mapping memory and irqs into the
guest. Possibility of creating a frontend/backend protocol.
We could virtualize GPU similarly to the ALSA protocol: virtual EGL or
OpenGL ES.

David: new PV protocols need a standard state machine, we should
document what a basic PV protocol looks like.

IanC: what about the security implication of assigning GPU and IPU to
guests? Is that a problem?
Andrii: For now, it is acceptable.

Re: [Xen Hackathon] new PV drivers

[Anil Madhavapeddy]

On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> Present (by memory):
> - Julien Grall,
> - Stefano Stabellini,
> - Ian Campbell,
> - Roger Pau Monne,
> - Dario Faggioli,
> - Andrii Tseglytskyi,
> - David Vrabel,
> - Konrad Wilk.
> 
> * What new PV devices do we need? What has been done already?

I missed this session, but was wondering about an entropy driver.  We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear how PV guests should go about getting a strong source of entropy from the outside world in a reasonably portable way.

VirtIO has a RNG [1] -- has anyone got any interest in a PV protocol for Xen that does the same?

[1] http://wiki.qemu-project.org/Features-Done/VirtIORNG

cheers,
Anil

Re: [Xen Hackathon] new PV drivers

[Adam Wick]

On Jun 6, 2014, at 6:56 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>> 
>> * What new PV devices do we need? What has been done already?
> 
> I missed this session, but was wondering about an entropy driver.  We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear how PV guests should go about getting a strong source of entropy from the outside world in a reasonably portable way.

+1. We’ve been making do, but a portable source of useful entropy for PV guests would be very handy.


- Adam

Re: [Xen Hackathon] new PV drivers

[Ian Campbell]

On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > Present (by memory):
> > - Julien Grall,
> > - Stefano Stabellini,
> > - Ian Campbell,
> > - Roger Pau Monne,
> > - Dario Faggioli,
> > - Andrii Tseglytskyi,
> > - David Vrabel,
> > - Konrad Wilk.
> > 
> > * What new PV devices do we need? What has been done already?
> 
> I missed this session, but was wondering about an entropy driver.
> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> how PV guests should go about getting a strong source of entropy from
> the outside world in a reasonably portable way.
> 
> VirtIO has a RNG [1] -- has anyone got any interest in a PV protocol
> for Xen that does the same?

IMHO support for these sorts of things is actually one of the few good
reasons to be considering support for basic virtio on Xen.

Alternatively AIUI a bunch of these sort of virtio devices are just
protocols built on top of virtio_serial, so we could perhaps be thinking
of repurposing them over Xen's serial PV device. Dave S was
investigating the difference between libvirt "serial" and "channel"
recently and AIUI the difference was that a channel could be named in
order to support bindings to these higher level things (i.e. appearing
to the guest as /dev/rng instead of /dev/hvcN).

Ian.

> 
> [1] http://wiki.qemu-project.org/Features-Done/VirtIORNG
> 
> cheers,
> Anil
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [Xen Hackathon] new PV drivers

[Stefano Stabellini]

On Mon, 9 Jun 2014, Ian Campbell wrote:
> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> > On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > 
> > > Present (by memory):
> > > - Julien Grall,
> > > - Stefano Stabellini,
> > > - Ian Campbell,
> > > - Roger Pau Monne,
> > > - Dario Faggioli,
> > > - Andrii Tseglytskyi,
> > > - David Vrabel,
> > > - Konrad Wilk.
> > > 
> > > * What new PV devices do we need? What has been done already?
> > 
> > I missed this session, but was wondering about an entropy driver.
> > We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> > how PV guests should go about getting a strong source of entropy from
> > the outside world in a reasonably portable way.
> > 
> > VirtIO has a RNG [1] -- has anyone got any interest in a PV protocol
> > for Xen that does the same?
> 
> IMHO support for these sorts of things is actually one of the few good
> reasons to be considering support for basic virtio on Xen.
> 
> Alternatively AIUI a bunch of these sort of virtio devices are just
> protocols built on top of virtio_serial, so we could perhaps be thinking
> of repurposing them over Xen's serial PV device. Dave S was
> investigating the difference between libvirt "serial" and "channel"
> recently and AIUI the difference was that a channel could be named in
> order to support bindings to these higher level things (i.e. appearing
> to the guest as /dev/rng instead of /dev/hvcN).

However writing a good PV-RNG should be far easier than making virtio
work properly with Xen PV guests.

Re: [Xen Hackathon] new PV drivers

[Ian Campbell]

On Mon, 2014-06-09 at 10:42 +0100, Stefano Stabellini wrote:
> On Mon, 9 Jun 2014, Ian Campbell wrote:
> > On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> > > On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > 
> > > > Present (by memory):
> > > > - Julien Grall,
> > > > - Stefano Stabellini,
> > > > - Ian Campbell,
> > > > - Roger Pau Monne,
> > > > - Dario Faggioli,
> > > > - Andrii Tseglytskyi,
> > > > - David Vrabel,
> > > > - Konrad Wilk.
> > > > 
> > > > * What new PV devices do we need? What has been done already?
> > > 
> > > I missed this session, but was wondering about an entropy driver.
> > > We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> > > how PV guests should go about getting a strong source of entropy from
> > > the outside world in a reasonably portable way.
> > > 
> > > VirtIO has a RNG [1] -- has anyone got any interest in a PV protocol
> > > for Xen that does the same?
> > 
> > IMHO support for these sorts of things is actually one of the few good
> > reasons to be considering support for basic virtio on Xen.
> > 
> > Alternatively AIUI a bunch of these sort of virtio devices are just
> > protocols built on top of virtio_serial, so we could perhaps be thinking
> > of repurposing them over Xen's serial PV device. Dave S was
> > investigating the difference between libvirt "serial" and "channel"
> > recently and AIUI the difference was that a channel could be named in
> > order to support bindings to these higher level things (i.e. appearing
> > to the guest as /dev/rng instead of /dev/hvcN).
> 
> However writing a good PV-RNG should be far easier than making virtio
> work properly with Xen PV guests.

True. I was mostly thinking about the trivial ones which didn't need
zero copy/DMA which might have made it simpler.

In any case as I said I think most of the interesting little ones are
actually based on the virtio-serial so making them work over xen PV
console channels should be pretty easy.

Ian.

Re: [Xen Hackathon] new PV drivers

[Boris Ostrovsky]

On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
> On Mon, 9 Jun 2014, Ian Campbell wrote:
>> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
>>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>>>
>>>> Present (by memory):
>>>> - Julien Grall,
>>>> - Stefano Stabellini,
>>>> - Ian Campbell,
>>>> - Roger Pau Monne,
>>>> - Dario Faggioli,
>>>> - Andrii Tseglytskyi,
>>>> - David Vrabel,
>>>> - Konrad Wilk.
>>>>
>>>> * What new PV devices do we need? What has been done already?
>>> I missed this session, but was wondering about an entropy driver.
>>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
>>> how PV guests should go about getting a strong source of entropy from
>>> the outside world in a reasonably portable way.


Is entropy provided by drivers/char/random.c not sufficient?

-boris


>>>
>>> VirtIO has a RNG [1] -- has anyone got any interest in a PV protocol
>>> for Xen that does the same?
>> IMHO support for these sorts of things is actually one of the few good
>> reasons to be considering support for basic virtio on Xen.
>>
>> Alternatively AIUI a bunch of these sort of virtio devices are just
>> protocols built on top of virtio_serial, so we could perhaps be thinking
>> of repurposing them over Xen's serial PV device. Dave S was
>> investigating the difference between libvirt "serial" and "channel"
>> recently and AIUI the difference was that a channel could be named in
>> order to support bindings to these higher level things (i.e. appearing
>> to the guest as /dev/rng instead of /dev/hvcN).
> However writing a good PV-RNG should be far easier than making virtio
> work properly with Xen PV guests.

Re: [Xen Hackathon] new PV drivers

[Ian Campbell]

On Mon, 2014-06-09 at 10:30 -0400, Boris Ostrovsky wrote:
> On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
> > On Mon, 9 Jun 2014, Ian Campbell wrote:
> >> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> >>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >>>
> >>>> Present (by memory):
> >>>> - Julien Grall,
> >>>> - Stefano Stabellini,
> >>>> - Ian Campbell,
> >>>> - Roger Pau Monne,
> >>>> - Dario Faggioli,
> >>>> - Andrii Tseglytskyi,
> >>>> - David Vrabel,
> >>>> - Konrad Wilk.
> >>>>
> >>>> * What new PV devices do we need? What has been done already?
> >>> I missed this session, but was wondering about an entropy driver.
> >>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> >>> how PV guests should go about getting a strong source of entropy from
> >>> the outside world in a reasonably portable way.
> 
> 
> Is entropy provided by drivers/char/random.c not sufficient?

This is about providing entropy for that driver to consume.

VMs typically don't have much hardware and therefore don't have much
entropy to seed the pool with.

Ian.

Re: [Xen Hackathon] new PV drivers

[Boris Ostrovsky]

On 06/09/2014 10:33 AM, Ian Campbell wrote:
> On Mon, 2014-06-09 at 10:30 -0400, Boris Ostrovsky wrote:
>> On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
>>> On Mon, 9 Jun 2014, Ian Campbell wrote:
>>>> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
>>>>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>>>>>
>>>>>> Present (by memory):
>>>>>> - Julien Grall,
>>>>>> - Stefano Stabellini,
>>>>>> - Ian Campbell,
>>>>>> - Roger Pau Monne,
>>>>>> - Dario Faggioli,
>>>>>> - Andrii Tseglytskyi,
>>>>>> - David Vrabel,
>>>>>> - Konrad Wilk.
>>>>>>
>>>>>> * What new PV devices do we need? What has been done already?
>>>>> I missed this session, but was wondering about an entropy driver.
>>>>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
>>>>> how PV guests should go about getting a strong source of entropy from
>>>>> the outside world in a reasonably portable way.
>>
>> Is entropy provided by drivers/char/random.c not sufficient?
> This is about providing entropy for that driver to consume.
>
> VMs typically don't have much hardware and therefore don't have much
> entropy to seed the pool with.

So this is about seeding, not feeding? (sorry, did not mean to start 
rhyming ;-)).

-boris

Re: [Xen Hackathon] new PV drivers

[Ian Campbell]

On Mon, 2014-06-09 at 10:39 -0400, Boris Ostrovsky wrote:
> On 06/09/2014 10:33 AM, Ian Campbell wrote:
> > On Mon, 2014-06-09 at 10:30 -0400, Boris Ostrovsky wrote:
> >> On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
> >>> On Mon, 9 Jun 2014, Ian Campbell wrote:
> >>>> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> >>>>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >>>>>
> >>>>>> Present (by memory):
> >>>>>> - Julien Grall,
> >>>>>> - Stefano Stabellini,
> >>>>>> - Ian Campbell,
> >>>>>> - Roger Pau Monne,
> >>>>>> - Dario Faggioli,
> >>>>>> - Andrii Tseglytskyi,
> >>>>>> - David Vrabel,
> >>>>>> - Konrad Wilk.
> >>>>>>
> >>>>>> * What new PV devices do we need? What has been done already?
> >>>>> I missed this session, but was wondering about an entropy driver.
> >>>>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> >>>>> how PV guests should go about getting a strong source of entropy from
> >>>>> the outside world in a reasonably portable way.
> >>
> >> Is entropy provided by drivers/char/random.c not sufficient?
> > This is about providing entropy for that driver to consume.
> >
> > VMs typically don't have much hardware and therefore don't have much
> > entropy to seed the pool with.
> 
> So this is about seeding, not feeding? (sorry, did not mean to start 
> rhyming ;-)).

TBH I'm not sure, I think it could be either or both...

Ian.

Re: [Xen Hackathon] new PV drivers

[Boris Ostrovsky]

On 06/09/2014 10:43 AM, Ian Campbell wrote:
> On Mon, 2014-06-09 at 10:39 -0400, Boris Ostrovsky wrote:
>> On 06/09/2014 10:33 AM, Ian Campbell wrote:
>>> On Mon, 2014-06-09 at 10:30 -0400, Boris Ostrovsky wrote:
>>>> On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
>>>>> On Mon, 9 Jun 2014, Ian Campbell wrote:
>>>>>> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
>>>>>>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>>>>>>>
>>>>>>>> Present (by memory):
>>>>>>>> - Julien Grall,
>>>>>>>> - Stefano Stabellini,
>>>>>>>> - Ian Campbell,
>>>>>>>> - Roger Pau Monne,
>>>>>>>> - Dario Faggioli,
>>>>>>>> - Andrii Tseglytskyi,
>>>>>>>> - David Vrabel,
>>>>>>>> - Konrad Wilk.
>>>>>>>>
>>>>>>>> * What new PV devices do we need? What has been done already?
>>>>>>> I missed this session, but was wondering about an entropy driver.
>>>>>>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
>>>>>>> how PV guests should go about getting a strong source of entropy from
>>>>>>> the outside world in a reasonably portable way.
>>>> Is entropy provided by drivers/char/random.c not sufficient?
>>> This is about providing entropy for that driver to consume.
>>>
>>> VMs typically don't have much hardware and therefore don't have much
>>> entropy to seed the pool with.
>> So this is about seeding, not feeding? (sorry, did not mean to start
>> rhyming ;-)).
> TBH I'm not sure, I think it could be either or both...

Feeding is done by interrupt timing and block device access latency, 
both of which are happening in a guest. I don't know whether there is 
enough of that but perhaps before embarking on new PV driver it may be 
worth investigating quality of existing entropy source. Or maybe it's 
already been looked at.

-boris

Re: [Xen Hackathon] new PV drivers

[Ian Campbell]

On Mon, 2014-06-09 at 10:55 -0400, Boris Ostrovsky wrote:
> On 06/09/2014 10:43 AM, Ian Campbell wrote:
> > On Mon, 2014-06-09 at 10:39 -0400, Boris Ostrovsky wrote:
> >> On 06/09/2014 10:33 AM, Ian Campbell wrote:
> >>> On Mon, 2014-06-09 at 10:30 -0400, Boris Ostrovsky wrote:
> >>>> On 06/09/2014 05:42 AM, Stefano Stabellini wrote:
> >>>>> On Mon, 9 Jun 2014, Ian Campbell wrote:
> >>>>>> On Fri, 2014-06-06 at 14:56 +0100, Anil Madhavapeddy wrote:
> >>>>>>> On 3 Jun 2014, at 12:47, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Present (by memory):
> >>>>>>>> - Julien Grall,
> >>>>>>>> - Stefano Stabellini,
> >>>>>>>> - Ian Campbell,
> >>>>>>>> - Roger Pau Monne,
> >>>>>>>> - Dario Faggioli,
> >>>>>>>> - Andrii Tseglytskyi,
> >>>>>>>> - David Vrabel,
> >>>>>>>> - Konrad Wilk.
> >>>>>>>>
> >>>>>>>> * What new PV devices do we need? What has been done already?
> >>>>>>> I missed this session, but was wondering about an entropy driver.
> >>>>>>> We're integrating an OCaml SSL/TLS into MirageOS, and it's not clear
> >>>>>>> how PV guests should go about getting a strong source of entropy from
> >>>>>>> the outside world in a reasonably portable way.
> >>>> Is entropy provided by drivers/char/random.c not sufficient?
> >>> This is about providing entropy for that driver to consume.
> >>>
> >>> VMs typically don't have much hardware and therefore don't have much
> >>> entropy to seed the pool with.
> >> So this is about seeding, not feeding? (sorry, did not mean to start
> >> rhyming ;-)).
> > TBH I'm not sure, I think it could be either or both...
> 
> Feeding is done by interrupt timing and block device access latency, 
> both of which are happening in a guest. I don't know whether there is 
> enough of that but perhaps before embarking on new PV driver it may be 
> worth investigating quality of existing entropy source. Or maybe it's 
> already been looked at.

I've not done the numbers/investigated it myself but it's a quite widely
held belief that those things are not sufficient in a virtual machine. 

Ian.

Re: [Xen Hackathon] new PV drivers

[Andy Smith]

Hello,

On Mon, Jun 09, 2014 at 04:06:25PM +0100, Ian Campbell wrote:
> On Mon, 2014-06-09 at 10:55 -0400, Boris Ostrovsky wrote:
> > Feeding is done by interrupt timing and block device access latency, 
> > both of which are happening in a guest. I don't know whether there is 
> > enough of that but perhaps before embarking on new PV driver it may be 
> > worth investigating quality of existing entropy source. Or maybe it's 
> > already been looked at.
> 
> I've not done the numbers/investigated it myself but it's a quite widely
> held belief that those things are not sufficient in a virtual machine. 

Available entropy in my VMs is much lower than on the dom0, to the
point where I had customers doing a lot of HTTPS/TLS who were
expeirencing stalls.

I bought a couple of Entropy Keys and shipped in entropy to the VMs
via an additional daemon.

    https://tools.bitfolk.com/wiki/Entropy

A software solution to seed entropy in VMs from the dom0's pool
would be welcome.

Cheers,
Andy