Re: [Xen-devel] [RFH]: AMD SVM #PF error code with P and RSVD bit....

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Mon, 16 Jun 2014 10:24:15 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 14.06.14 at 03:03, <mukesh.rathor@xxxxxxxxxx> wrote:
> > I am trying to debug this triple fault bringing up PVH linux domU on
> > AMD.
> > 
> > Instruction:
> > ffffffff81d2d976: 8:dmi_scan_machine+b7          mov (%r12),
> > %rax r12: ffffffffff46e000
> > 
> > This first causes #PF:
> > (XEN) exitcode = 0x4e exitintinfo = 0
> > (XEN) exitinfo1 = 0x9 exitinfo2 = 0xffffffffff46e000 
> > 
> > erro_code == 0x9 => RSVD bit set. according to the APM:
> > 
> >    RSVâBit 3. If this bit is set to 1, the page fault is a result
> >    of the processor reading a 1 from a reserved field within a
> >    page-translation-table entry. This type of page fault occurs only
> >    when CR4.PSE=1 or CR4.PAE=1.
> > 
> > My CR4 == 0x0000000000000060 == PAE MCE (Full vmcb below). 
> > However, all PTEs seem OK, all NPT entries seem OK too.
> > 
> > PTE entries (l4 thru L1):
> > 
> > 0000000001c16067 0000000001c18067 0000000001e8d067 80000000000f0463 
> 
> EFER.NX is clear, and hence the NX bit on the L1 entry is wrong.

Ah, interesting, I didn't realize it would complain about NX during load/store.

BTW on:

Intel:
    Guest EFER = 0x0000000000000000

    Ptes:
       0000000001c16067 0000000001c18067 0000000001e8d067 80000000000f0463

L1 has XD set. Maybe Intel just ignores the bit if EFER.NX is 0!


So, that leads me to wonder next whether it's better to set EFER.NX in SVM
when setting LME/LMA, or impose on the guest to do it itself. Both seem OK
to me...

thanks
mukesh


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