Re: [Xen-devel] [PATCH v3 3/3] xen: introduce XENMEM_get_dma_buf and XENMEM_put_dma_buf

[Tim Deegan <tim@xxxxxxx>]

At 15:16 +0100 on 08 Aug (1375974960), Stefano Stabellini wrote:
> On Thu, 8 Aug 2013, Keir Fraser wrote:
> > On 08/08/2013 11:40, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> > 
> > >>  it exchanges the pages
> > >> + * passed in with a new set of pages, contiguous and under 4G if so
> > >> + * requested.
> > > 
> > > I guess it avoids exchanging the pages if they already meet this
> > > constraint?
> > > 
> > > The "if so requested" binds to "under 4G" and not "contiguous"? The
> > > result is always contiguous I think. Also 4G is just an example and the
> > > caller can ask for any order it likes.
> > > 
> > > The contents of the pages will be lost I think. Perhaps in debug builds
> > > we should consider actually nuking the page's content in the case where
> > > we don't actually exchange?
> > 
> > This confused me too, this talk of contiguity and being below 4GB. Doesn't
> > this new hypercall behave *exactly* like XENMEM_exchange, except for the
> > additional pinning of the MFNs? If so, just say that in the patch header and
> > code comments. The fact *you* currently use it to get memory below 4GB is an
> > application detail.
> 
> Yeah, you have a good point there. Trying to make the comment clearer I
> actually confused it. I'll fix it.
> 
> 
> > I wonder whether XENMEM_exchange is much use at all in the presence of
> > paging, without the additional semantics of pinning? Perhaps XENMEM_exchange
> > could be suitably adjusted to have the pinning semantics in this case?
> 
> It's not just about pinning, we also need to get the mfn back even if
> the guest is autotranslate, that XENMEM_exchange doesn't do.

I'd prefer if this were phrased as a DMA address, or something like
that.  On systems with an IOMMU (e.g. x86) this address might not be an
MFN.

Tim.

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