Re: [Xen-devel] [PATCH] VT-d: honor APEI firmware-first mode in XSA-59 workaround code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.14 at 03:39, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-06-04:
>> When firmware-first mode is being indicated by firmware, we shouldn't 
>> be modifying AER registers - these are considered to be owned by 
>> firmware in that case. Violating this is being reported to result in 
>> SMI storms. While circumventing the workaround means re-exposing 
>> affected hosts to the XSA-59 issues, this in any event seems better 
>> than not booting at all. Respective messages are being issued to the log, so 
> the situation can be diagnosed.
>> 
>> The basic building blocks were taken from Linux 3.15-rc. Note that 
>> this includes a block of code enclosed in #ifdef CONFIG_X86_MCE - we 
>> don't define that symbol, and that code also wouldn't build without 
>> suitable machine check side code added; that should happen eventually, but 
> isn't subject of this change.
>> 
> 
> I am wondering is there any problem if hypervisor to update the ACPI table 
> to force it as firmware first. This will avoid dom0 to touch AER 
> unintentionally.

Messing with ACPI tables is something I'd try to avoid as much as
possible. As said previously (perhaps in a different context) - we
anyway (have to) trust Dom0 to not misbehave (not the least
since you'd then also need to take into consideration kernels not
even inspecting HEST). I.e. any issues resulting from Dom0 possibly
undoing what we did ought to get fixed in kernel code.

And any further step here would be a separate patch anyway - I
certainly don't want to extend this one unless it turns out buggy
in some way. Obviously - just to remind you - the patch is in need
of your and/or Kevin's ack for the VT-d part...

Jan


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