Re: [Xen-devel] Xen 4.9 vmentry failure

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan

Jan


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