Re: [Xen-devel] [PATCH 08/12] xen/grant-table: add a mechanism to safely unmap pages that are in use

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-07 at 12:00 +0000, Ian Campbell wrote:
> On Tue, 2015-01-06 at 18:57 +0000, David Vrabel wrote:
> > From: Jenny Herbert <jennifer.herbert@xxxxxxxxxx>
> > 
> > Introduce gnttab_unmap_refs_async() that can be used to safely unmap
> > pages that may be in use (ref count > 1).  If the pages are in use the
> > unmap is deferred and retried later.  This polling is not very clever
> > but it should be good enough if the cases where the delay is necessary
> > are rare.
> > 
> > This is needed to allow block backends using grant mapping to safely
> > use network storage (block or filesystem based such as iSCSI or NFS).
> > 
> > The network storage driver may complete a block request whilst there
> > is a queued network packet retry (because the ack from the remote end
> > races with deciding to queue the retry).  The pages for the retried
> > packet would be grant unmapped and the network driver (or hardware)
> > would access the unmapped page.
> 
> I thought this had been solved a little while ago by mapping a scratch
> page on unmap even for kernel space grant mappings, but both the design
> doc and here imply not (i.e. the scratch is for user grant mappings
> only), so I must be misremembering.
> 
> Regardless, this approach seems likely to be far better...

None of the following patches switch netback to use it though, I think
because the use of SKBTX_DEV_ZEROCOPY makes it unnecessary. But perhaps
this lazy unmap scheme would be a better fix than SKB zerocopy for that
case too. The current stuff has the downside of always copying skbs from
guests destined for dom0 itself (rather than just passing through on
there way to a pysical NIC or another VIF), IIRC.

Ian.


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