Re: [Xen-devel] [RFC] netif: staging grants for requests

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Stefano Stabellini [mailto:sstabellini@xxxxxxxxxx]
> Sent: 06 January 2017 19:18
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Joao Martins <joao.m.martins@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>;
> Wei Liu <wei.liu2@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> Subject: RE: [RFC] netif: staging grants for requests
> 
> On Fri, 6 Jan 2017, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Joao Martins [mailto:joao.m.martins@xxxxxxxxxx]
> > > Sent: 14 December 2016 18:11
> > > To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > Cc: David Vrabel <david.vrabel@xxxxxxxxxx>; Andrew Cooper
> > > <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Paul
> Durrant
> > > <Paul.Durrant@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > Subject: [RFC] netif: staging grants for requests
> > >
> > > Hey,
> > >
> > > Back in the Xen hackaton '16 networking session there were a couple of
> ideas
> > > brought up. One of them was about exploring permanently mapped
> grants
> > > between
> > > xen-netback/xen-netfront.
> > >
> > > I started experimenting and came up with sort of a design document (in
> > > pandoc)
> > > on what it would like to be proposed. This is meant as a seed for
> discussion
> > > and also requesting input to know if this is a good direction. Of course, 
> > > I
> > > am willing to try alternatives that we come up beyond the contents of the
> > > spec, or any other suggested changes ;)
> > >
> > > Any comments or feedback is welcome!
> > >
> >
> > Hi,
> >
> >   Sorry for the delay... I've been OOTO for three weeks.
> >
> >   I like the general approach or pre-granting buffers for RX so that the
> backend can simply memcpy and tell the frontend which buffer a packet
> appears in but IIUC you are proposing use of a single pre-granted area for TX
> also, which would presumably require the frontend to always copy on the TX
> side? I wonder if we might go for a slightly different scheme...
> >
> >   The assumption is that the working set of TX buffers in the guest OS is
> fairly small (which is probably true for a small number of heavily used 
> sockets
> and an OS that uses a slab allocator)...
> >
> >   The guest TX code maintains a hash table of buffer addresses to grant
> refs. When a packet is sent the code looks to see if it has already granted 
> the
> buffer and re-uses the existing ref if so, otherwise it grants the buffer and
> adds the new ref into the table.
> >
> >   The backend also maintains a hash of grant refs to addresses and,
> whenever it sees a new ref, it grant maps it and adds the address into the
> table. Otherwise it does a hash lookup and thus has a buffer address it can
> immediately memcpy from.
> >
> >   If the frontend wants the backend to release a grant ref (e.g. because 
> > it's
> starting to run out of grant table) then a control message can be used to ask
> for it back, at which point the backend removes the ref from its cache and
> unmaps it.
> >
> >   Using this scheme we allow a guest OS to still use either a zero-copy
> approach if it wishes to do so, or a static pre-grant... or something between
> (e.g. pre-grant for headers, zero copy for bulk data).
> >
> >   Does that sound reasonable?
> 
> Wouldn't it be better to introduce the new memcpy based scheme for RX
> only?

It would certainly be reasonable to tackle RX first. But I don't want to force 
a copy in the TX path when it may be possible to avoid it.

> 
> This suggestion increases the total amount of grants and the amount of
> non-packet data simultaneously shared from frontend to backend by
> "accident" (because it happens to be on the same pages that are granted
> to the backend). Am I right? If so, it could be a security concern.
> Let's keep in mind that if we trust the backend then we might as well go
> all the way and assume that the backend is in Dom0 and can map any mfn
> in memory without requiring grants. That would be a simple extension
> guaranteed to have great performance (I am in favor of this FYI).

I'm not sure that we want to do away with grants altogether. In my scheme the 
frontend can ask for its grants back so that it doesn't leak, but if it's 
willing to place more trust in the backend then it can grant pages from the 
stack which may contain other information. Certainly bypassing grants would be 
a quick performance boost but it's an all-or-nothing approach, whereas I'm 
shooting for something more flexible.

  Paul

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