[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 20:32, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
wrote:
> On Tue, 10 Sep 2013, Jan Beulich wrote:
>> >>> 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.
> 
> We could leave it up to each architecture to specify whether the
> hypercall returns a DMA address or a Machine address (according to
> their definition of DMA address and Machine address).
> Even if this is a common header.

That would likely result in ugly conditionals in the kernel side code
consuming this.

But yes, considering that we're not currently aware of ports to
such architectures (I have no idea how MIPS works in this regard;
that's the only architecture I'm aware people have shown some
interest in), we might as well do it that way. But then please
change the comment so say so.

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