RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.10.11 at 13:58, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Jan Beulich wrote:
>>>>> On 11.10.11 at 11:51, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>> That would be data load error (EIPV=1), a sync error.
>> 
>> If indeed implemented that way in hardware, that would make the
>> handling ambiguous: A GDT access must not (unconditionally) be
>> attributed to the (pv) guest, as it is not a problem the guest can
>> (necessarily) deal with (considering the split page ownership of
>> what constitutes the GDT under Xen, the guest should only be
>> accountable for the non-reserved part of the GDT, the rest should
>> be attributed back to Xen).
>> 
>> The same would go for (perhaps speculative) page table walks.
>> 
> 
> Seems not ambiguous here: who own, who take.
> If error caused by hypervisor access broken page, xen panic;
> If error caused by guest access, guest would handle it (I guess normally 
> kill itself);

If a guest accesses the hypervisor part of the GDT or page tables, or
some other shared data structure owned by the hypervisor (like the
M2P table), its handler may get utterly confused by being presented
an address it doesn't own and knows nothing about (i.e. in violation
of your "who own, who take").

And even from a theoretical pov, a hypervisor should panic if one of
its data structures got corrupted, no matter whether that was due to
its own or a guest's access. Delaying the panic here will only lead to
the situation becoming worse. (The same would go for a "normal"
kernel: If an application causes an MCE due to e.g. a GDT access, it
shouldn't be just the application that gets killed. Of course, with the
interesting GDT descriptors all being located close to each other,
there's little chance the kernel would be able to handle that, but
that's an implementation aspect of the kernel, not something that
should matter to the hardware design.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel