[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 4/4] xen: introduce XENMEM_exchange_and_pin and XENMEM_unpin



>>> On 10.09.13 at 14:50, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2013-09-10 at 13:15 +0100, Jan Beulich wrote:
> 
>> > @@ -459,6 +460,52 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
>> >   * The zero value is appropiate.
>> >   */
>> >  
>> > +#define XENMEM_exchange_and_pin             26
>> > +/*
>> > + * This hypercall is similar to XENMEM_exchange: it takes the same
>> > + * struct as an argument and it exchanges the pages passed in with a new
>> > + * set of pages. The new pages are going to be "pinned": it's guaranteed
>> > + * that their p2m mapping won't be changed until explicitly "unpinned".
>> > + * The content of the exchanged pages is lost.
>> > + * Only normal guest r/w memory can be pinned: no granted pages or
>> > + * ballooned pages.
>> > + * If return code is zero then @out.extent_list provides the DMA frame
>> > + * numbers of the newly-allocated memory.
>> 
>> "DMA"? I don't think that term is universally true across all possible
>> architectures (but we're in an architecture independent header
>> here). "Machine" would probably be better (as it implies CPU
>> perspective, whereas DMA hints at device perspective).
> 
> I think DMA here is correct. The purpose of exchange and pin is so that
> the page can be safely handed to a device for DMA.
> 
> On an architecture where DMA address != Machine address then this should
> indeed return the DMA addresses.

One problem is that I think there are architectures where there's no
single canonical DMA address; such an address may depend on the
placement of a device in the system's topology. Hence I don't think
it would even be possible to return "the" DMA address here. It ought
to be the machine address (CPU view), and the consumer ought to
know how to translate this to a DMA address for a particular device.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.