[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.