Re: [Xen-devel] [PATCH] x86/HVM: adjust hvm_interrupt_blocked()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.10.18 at 18:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/10/18 16:58, Jan Beulich wrote:
>> First of all, hvm_intsrc_mce was not considered here at all, yet nothing
>> blocks #MC (other than an already in-progress #MC, but dealing with this
>> is not the purpose of this patch).
> 
> I don't believe we've got sufficient infrastructure to fix this
> reasonably yet, but for the record, the real behaviour for MCEs is:
> 
> If intel
>     broadcast to every thread covered by the MCE bank
> else if AMD
>     sent to the thread with the lowest id covered by the MCE bank
> 
> When trying to inject:
> 
> if !CR4.MCE or MCG_STATUS.MCIP
>     shutdown

How is this related to the function the patch changes?

> Furthermore, I believe even #MC is blocked by the MOVSS shadow, because
> the purpose of the shadow is to indicate "my stack is not safe to take
> an exception".

"I believe" is what I would have said too, but the documentation
has not even a hint to that effect, and (to me) instead suggests
that this is not the case. I'm sort of assuming that they imply a
full stack switch (32-bit: task switch; 64-bit: IST) to be arranged
for by the OS. But of course the documentation being explicit in
this regard would certainly help decide what the ordering of
actions/tests in the function here really ought to be.

>> Additionally STI-shadow only blocks maskable interrupts, but not NMI.
> 
> This has been discussed on LKML in the past, but `STI; HLT` will
> deadlock if NMIs don't respect the STI shadow.
> 
> An NMI which hits that instruction boundary will IRET with IF clear, at
> which point the core will halt and never wake up.

True, yet again ...

> I believe the input from the vendor architects was that some very old
> cores suffer from this problem, but anything you can get yours hand on
> today will respect the STI shadow.

... I haven't been able to find anything like this in the doc; instead
iirc I did, just like for #MC, again find hints towards the behavior
that the patch implements.

I don't really know what to do here, when the doc is as unclear as
it looks to be (or a possibly more clear statement is in an unexpected
place, and hence not reasonable to be found).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel