Re: [Xen-devel] Xen 4.9 vmentry failure

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/06/17 11:22, Jan Beulich wrote:
>>>> On 01.06.17 at 11:12, <andrew.cooper3@xxxxxxxxxx> wrote:
>> We attempted to inject an NMI.  As this is a plain VM without any
>> hardware, I expect it came from an IPI rather than something external to
>> the VM.  This also matches up with the interruptibility indicating that
>> the guest is in an NMI shadow.
>>
>> Being 32bit, NMIs are handled using a task gate to switch stack, and at
>> the point of failure, we tried injecting #TS, which suggests that
>> hvm_task_switch() objected to something.
> As this isn't the TSW_iret case from all we know, there's only one
> path raising #TS(tss_sel) - when the P bit in the descriptor is not
> set. I therefore rather wonder ...
>
>> The error code (0x0010) is odd, but it is certainly possible that
>> windows puts its TSS adjacent to %cs.
> ... whether it's some other selector that cannot be loaded.
>
>>  On inspection, there is
>> definitely a bug in that this error code should have IDT|EXT set in it,
>> but as this has been broken since forever, its not the source of the
>> regression.
> Certainly not IDT but just EXT, I would think?

Indeed.  I don't know what I was thinking suggesting IDT here.

>  But that raises
> another possibility: What if the selector here actually is pointing
> into the IDT? The SDM says it's the TSS selector that the exit
> qualification provides, but what if in fact it's the error code
> #TS / #GP would otherwise have been handed?

Looking back over the manual, I can't see any documented case where #TS
would reference an IDT entry.  All error cases reference a segment
selector, which puts it firmly in the GDT or LDT.

>
> Otoh if we assume it's an IPI, we should also be allowed to
> assume both IDT descriptor for vector 2 and referenced task
> descriptor are okay.
>
> So in the end I really think 0x0010 is the ring zero data/stack
> selector. And I'd then further think we have an issue with
> switching from ring 3 to ring 0 here:
>
>         dpl = (desc.b >> 13) & 3;
>         rpl = sel & 3;
>         cpl = hvm_get_cpl(v);
>         ...
>         case x86_seg_ss:
>             ...
>             if ( (dpl != cpl) || (dpl != rpl) )
>                 goto unmap_and_fail;
>
>> It is still unclear however which piece of guest state the processor is
>> actually objecting to.
> CS.RPL != SS.RPL

I really haven't had enough coffee yet, have I.  I will see about
building an XTF test to exercise this corner case.

~Andrew

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