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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.06.12 at 17:29, "Luck, Tony" <tony.luck@xxxxxxxxx> wrote:
>>  1). still use 1 bank and simply ignore this issue. I mean, even if guest 
>> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
>> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
>> kill itself. Considering bank0 quirks is only for old cpus, this is 
>> acceptable;
>> 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
>> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
>> guest kill itself.
> 
> Don't you control what CPUID is shown to the guest? Under what circumstances
> would you tell the guest that it is running on an AMD-K7 or an Intel family
> 6 with model < 0x1A?   Surely for migration reasons you need to present the
> same virtualized family/model all the time ... so just don't use ones that
> cause problems.

I don't think family/model/stepping are frequently faked, it's
normally just the various feature flags that get normalized to
the smallest common set.

> If that isn't an option - then say there are 2 banks and have Xen ignore bank
> 0 (make MC0_STATUS always appear to contain 0) and put all the errors into
> bank1.  If you tell the guest there are 32 banks it will read all of them.
> Which means a lot of pointless exits to the hypervisor.

Indeed, emulating too many banks can have its own downsides.
Yet I don't think we're really concerned about performance when
handling machine checks. But having more than one usable bank
must have advantages, else hardware wouldn't implement things
that way.

Jan


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