Re: [Xen-devel] [V2 PATCH 9/9] x86/hvm: pkeys, add pkeys support for gva2gfn funcitons

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.12.15 at 09:50, <huaitong.han@xxxxxxxxx> wrote:
> On Wed, 2015-12-02 at 04:35 -0700, Jan Beulich wrote:
>>  >>> On 27.11.15 at 10:52, <huaitong.han@xxxxxxxxx> wrote:
>> > @@ -4439,7 +4443,8 @@ enum hvm_copy_result
>> > hvm_copy_from_guest_virt_nofault(
>> >  {
>> >      return __hvm_copy(buf, vaddr, size,
>> >                        HVMCOPY_from_guest | HVMCOPY_no_fault |
>> > HVMCOPY_virt,
>> > -                      PFEC_page_present | pfec);
>> > +                      PFEC_page_present | pfec |
>> > +                      hvm_pku_enabled(current) ? PFEC_prot_key :
>> > 0);
>> >  }
>> >  
>> >  enum hvm_copy_result hvm_fetch_from_guest_virt_nofault(
>> 
>> Was this patch tested at all? The lack of parentheses in all the
>> changes you make result - afaict - in PFEC_prot_key to be
>> unconditionally passed to __hvm_copy(), which can't be right.
> Yes, the patch can work, I understand, if the pfec parameter of __hvm_c
> opy is zero, it means that memory permission check is not to be
> required, when pfec is not 0, PKRU has access disable and write
> disable, so, PFEC_prot_key is unconditionally passed to the functions.

Did you understand that what I'm trying to point out is that the
code you've supplied is equivalent to (in the above case)

    return __hvm_copy(buf, vaddr, size,
                      HVMCOPY_from_guest | HVMCOPY_no_fault | HVMCOPY_virt,
                      PFEC_prot_key);

(which I doubt you consider correct)?

Jan


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