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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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?

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).

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