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

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



>>> On 08.08.13 at 16:44, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> 
>>> wrote:
> On Thu, 8 Aug 2013, Jan Beulich wrote:
>> >>> On 08.08.13 at 16:12, Stefano Stabellini 
>> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Thu, 8 Aug 2013, Jan Beulich wrote:
>> >> >>> On 05.08.13 at 18:40, Stefano Stabellini 
>> >> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> >> > @@ -630,8 +690,15 @@ long do_memory_op(unsigned long cmd, 
>> > XEN_GUEST_HANDLE_PARAM(void) arg)
>> >> >  
>> >> >          break;
>> >> >  
>> >> > +    case XENMEM_get_dma_buf:
>> >> > +        /* xen_get_dma_buf_t is identical to xen_memory_exchange_t, so
>> >> > +         * just cast it and reuse memory_exchange */
>> >> 
>> >> Then why do you define a new type for it in the first place?
>> > 
>> > Because the original hypercall doesn't copy back the mfn if the guest
>> > it's an autotranslate guest.
>> > And because it doesn't pin the p2m mappings.
>> 
>> Hmm, I'm confused: Here you reason why you want a new type
>> (note that I said "type", not "sub-hypercall"), ...
>> 
>> >> And anyway, the naming of the new sub-op isn't really
>> >> representing what the operation is capable of.
>> >> XENMEM_exchange_and_pin would seem to come much closer.
>> > 
>> > I like this suggestion. I could also keep xen_memory_exchange as
>> > argument for XENMEM_exchange_and_pin, as Ian suggested.
>> 
>> ... yet here you agree that xen_memory_exchange could be
>> re-used.
>  
> I meant only to keep the same parameter struct xen_memory_exchange.

And that's what I asked for.

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