Re: [Xen-devel] [vMCE design RFC] Xen vMCE design

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.06.12 at 18:21, "Luck, Tony" <tony.luck@xxxxxxxxx> wrote:
> There may be some secondary side benefit that independent errors might be
> reported to different banks, and so avoid some overwrite problems.  But I 
> don't
> think that Xen has a big worry with overwrite, does it? In general the 
> errors that
> you will show to the guest are ones that you expect the guest to handle 
> immediately
> (e.g. SRAO and SRAR signaled with a machine check). You do not log any 
> corrected
> errors to the guest (they can't do anything useful with them). You certainly 
> don't
> log any errors that are not signaled. So you should never have any errors 
> hanging
> around in banks for long periods that would get overwritten.

The problem is the determination of what "long" means here. The
target vCPU may not get scheduled for extended periods of time
(raising its priority would have other undesirable implications), so
the risk over overwrite exists from that perspective. However,
assuming that reportable errors get associated with a particular
vCPU, and that such a vCPU won't be able to execute any further
guest code prior to the delivery of the exception, the only real
risk here would be if the vMCE handler itself raised another event.
That I agree with Jinsong can be well treated as fatal (killing the
guest, provided the event gets properly logged so the admin
isn't left in the dark regarding the unexpected death of the VM),
mostly matching would a single bank hardware implementation
would result in.

Jan


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