Re: [Xen-devel] [PATCH 2/4] xen: introduce grant_map_exists

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 3 Oct 2014, Stefano Stabellini wrote:
> On Thu, 2 Oct 2014, Jan Beulich wrote:
> > >>> On 02.10.14 at 13:41, <tim@xxxxxxx> wrote:
> > > At 11:42 +0100 on 02 Oct (1412246555), Stefano Stabellini wrote:
> > >> On Thu, 2 Oct 2014, Tim Deegan wrote:
> > >> > Hi,
> > >> > 
> > >> > At 11:02 +0100 on 02 Oct (1412244156), Stefano Stabellini wrote:
> > >> > > Check whether an mfn has been granted to a given domain on a target
> > >> > > grant table.
> > >> > 
> > >> > The implementation looks good but I'm concerned about the need for it,
> > >> > since linear scans of busy grant tables could get fairly expensive.
> > >> > 
> > >> > I see in patch 3/4 you add a hypercall to flush caches, taking an mfn
> > >> > range.  Should that not take a gfn range?  That would be the idiomatic
> > >> > interface, and the p2m lookup would tell you whether the guest had
> > >> > appropiate rights.
> > >> > 
> > >> > I suspect, from reading 0/4, that I'm missing something about the
> > >> > tangle of non-IOMMU dom0 operations on ARM. :)
> > >> 
> > >> The hypercall is going to be used to flush foreign pages grant mapped in
> > >> Dom0. Unfortunately dom0 doesn't know the gfn, only the dma address
> > >> (==mfn).
> > > 
> > > Blargh.  Silly linux, forgetting its grant handles. :)
> > > 
> > > So after some IRL discussion with Stefano and IanC, I'm convinced that
> > > the alternatives (linux maintaining per-map lookup tables to get back
> > > from DMA address to grant handle) aren't going to work.  But we can
> > > make this API a bit neater.  I think the design we came up with is:
> > > 
> > >  - the cache-flush hypercall becomes a grant-table op instead of a
> > >    memop.
> > >  - the argument becomes a 'dev_bus_addr' instead of an MFN.  That is,
> > >    it must be the address returned in the dev_bus_addr field of a
> > >    grant map operation.  If not, it will return EINVAL.
> > 
> > Then at the very least let's allow for either a dev_bus_addr or
> > a grant-ref (even if for the moment the latter may yield
> > -EOPNOTSUPP in order to not spend more time on this than
> > immediately necessary). That way guests remembering what
> > they did a few microseconds back can do this in a more well
> > behaved fashion.
> 
> I can add the gref as a possible parameter in a union, but I would like
> to keep the interface multi-page capable. So the gref case is going to
> work implicitly only on a single page.

I take it back, the hypercall working on a single grant is OK as
otherwise pages wouldn't be contiguous in mfn space and couldn't be used
in a single dma_op.

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