Re: [Xen-devel] Woes of NMIs and MCEs, and possibly how to fix

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.11.12 at 20:12, Mats Petersson <mats.petersson@xxxxxxxxxx> wrote:
> On 30/11/12 17:34, Andrew Cooper wrote:
>> 4) "Fake NMIs" can be caused by hardware with access to the INTR pin
>> (very unlikely in modern systems with the LAPIC supporting virtual wire
>> mode), or by software executing an `int $0x2`.  This can cause the NMI
>> handler to run on the NMI stack, but without the normal hardware NMI
>> cessation logic being triggered.
>>
>> 5) "Fake MCEs" can be caused by software executing `int $0x18`, and by
>> any MSI/IOMMU/IOAPIC programmed to deliver vector 0x18.  Normally, this
>> could only be caused by a bug in Xen, although it is also possible on a
>> system with out interrupt remapping. (Where the host administrator has
>> accepted the documented security issue, and decided still to pass-though
>> a device to a trusted VM, and the VM in question has a buggy driver for
>> the passed-through hardware)
> Surely both 4 & 5 are "bad guest behaviour", and whilst it's a "nice to 
> have" to catch that, it's no different from running on bare metal doing 
> daft things with vectors or writing code that doesn't behave at all 
> "friendly". (4 is only available to Xen developers, which we hope are 
> most of the time sane enough not to try these crazy things in a "live" 
> system that matters). 5 is only available if you have pass through 
> enabled. I don't think either is a particularly likely cause of real, in 
> the field, problems.

If these were guest exposed, we'd have a much more severe
problem. But as Tim said, they aren't, hence we "only" need to
exclude Xen bugs here (and decide on how far we may want to go
with working around eventual hardware bugs).

Jan


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