Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.18 at 15:17, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Paul Durrant
>> Sent: 29 March 2018 13:43
>> To: 'Jan Beulich' <JBeulich@xxxxxxxx>
>> Cc: StefanoStabellini <sstabellini@xxxxxxxxxx>; Wei Liu
>> <wei.liu2@xxxxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Tim
>> (Xen.org) <tim@xxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>;
>> Julien Grall <julien.grall@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian
>> Jackson <Ian.Jackson@xxxxxxxxxx>
>> Subject: Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add
>> HYPERVISOR_memory_op to acquire guest resources
>> 
>> > -----Original Message-----
>> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > Sent: 29 March 2018 13:29
>> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> > Cc: Julien Grall <julien.grall@xxxxxxx>; Andrew Cooper
>> > <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
>> > <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wei
>> Liu
>> > <wei.liu2@xxxxxxxxxx>; StefanoStabellini <sstabellini@xxxxxxxxxx>; xen-
>> > devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek Wilk
>> > <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>
>> > Subject: RE: [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to
>> > acquire guest resources
>> >
>> > >>> On 29.03.18 at 11:53, <Paul.Durrant@xxxxxxxxxx> wrote:
>> > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > >> Sent: 26 March 2018 12:41
>> > >>
>> > >> >>> On 22.03.18 at 12:55, <paul.durrant@xxxxxxxxxx> wrote:
>> > >> > --- a/xen/include/xlat.lst
>> > >> > +++ b/xen/include/xlat.lst
>> > >> > @@ -86,6 +86,7 @@
>> > >> >  !    memory_map                      memory.h
>> > >> >  !    memory_reservation              memory.h
>> > >> >  !    mem_access_op                   memory.h
>> > >> > +!    mem_acquire_resource            memory.h
>> > >>
>> > >> Why ! ? The layout doesn't appear to differ between native and
>> > >> compat. Or wait, the handle does, but why is that not
>> > >> XEN_GUEST_HANDLE_64()? (I've skipped the compat layer code
>> > >> in this round of review for that reason.)
>> > >
>> > > It's been XEN_GUEST_HANDLE throughout all but the earliest revisions of
>> > the
>> > > patch and I have not modified the compat code massively since you gave
>> > your
>> > > R-b anyway... the only thing that changed was copying back the new flags
>> > > value.
>> >
>> > Granted I could/should have noticed this earlier, but being able to
>> > get away without compat translation would certainly be a win, and
>> > we have that option since this is a tools-only interface.
>> >
>> 
>> Ok. I'll see if I can get this done today then.
>> 
>>   Paul
> 
> Actually, I'm getting confused by all this... The handle is for an array of 
> xen_pfn_t, which means they are going to be 32-bits wide for a 32-bit tools 
> domain. Doesn't this mean I'm going to need compat code to iterate and 
> translate the array anyway?

Oh, yes, indeed. I'm sorry for the confusion. With the other remarks
addressed feel free to add
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel