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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-06-05:
>>>> 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.

This is what my concern. As you said, we may need to rely on dom0 do not to 
unmask the AER even such operation is valid from dom0's point. Otherwise, we 
need to fix it in dom0. But my previous experience is that Linux guys dislike 
such xen specific fixing to common 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...

For the patch itself:

Acked-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>

> 
> Jan


Best regards,
Yang



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