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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.06.14 at 00:44, <mukesh.rathor@xxxxxxxxxx> wrote:
> 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!

Which would be a bug imo.

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

No, this should be entirely under guest control.

Jan

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