Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

[Xiao Guangrong]

On 03/30/2016 02:39 PM, Xiao Guangrong wrote:
> On 03/30/2016 02:36 PM, Paolo Bonzini wrote:
> > On 30/03/2016 03:56, Xiao Guangrong wrote:
> > > > x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
> > > > is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0.  Can you use it
> > > > (with ept=1 of course) to check what the processor is doing?
> > >
> > > Sure.
> > >
> > > And ept=1 is hard to trigger MMU issue, i am enabling PKEY on shadow
> > > MMU, let's see what will happen. ;)
> >
> > No, don't do that!
> >
> > ept=1 lets you test what the processor does.  It means you cannot test
> > permission_fault(), but what we want here is just reverse engineering
> > the microcode.  ept=1 lets you do exactly that.
>
> Yes, i got this point. Huaitong will do the test once the machine gets
> free.

I tested it and it is failed:

test pte.p pte.user pde.p pde.user pde.a pde.pse pkru.wd pkey=1 user write efer.nx cr4.pke: FAIL: 
error code 27 expected 7
Dump mapping: address: 0x123400000000
------L4: 2ebe007
------L3: 2ebf007
------L2: 8000000020000a5

So PFEC.PKEY is set even if the ordinary check failed (caused by pde.rw = 0), the kvm code is
right. :)