Re: [Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.11.16 at 12:38, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Nov 29, 2016 at 03:40:37AM -0700, Jan Beulich wrote:
>> >>> On 29.11.16 at 03:59, <shankerd@xxxxxxxxxxxxxx> wrote:
>> > Either we have to hide the watchdog timer section in GTDT or emulate
>> > watchdog timer block for dom0. Otherwise, system gets panic when
>> > dom0 accesses its MMIO registers. The current XEN doesn't support
>> > virtualization of watchdog timer, so hide the watchdog timer section
>> > for dom0.
>> > 
>> > Signed-off-by: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
>> 
>> The mere need for a patch like this is, to me at least, a pretty
>> clear indication that such black listing models don't work well
>> (and using white listing instead would likely be too restrictive).
>> As the same is about to become an issue on x86 too (with
>> PVHv2) I think there's a need to reconsider how to deal with
>> ACPI with other than a traditional PV Dom0, namely whether
>> (a) it wouldn't make sense to expect a little more awareness
>> by the Dom0 kernel, and
>> (b) whether we shouldn't unconditionally hand everything to
>> Dom0 which Xen doesn't explicitly make use of itself (implying
>> that MMIO regions get suitably prepared either during boot
>> or on demand).
> 
> I cannot speak about ARM, but given that support for ACPI was added in the 
> previous release, and is AFAIK still marked as experimental, I expect such 
> fixes 
> to be normal.

Yes and no. My issue here is that the need for such fixes may arise
with new additions to the ACPI spec, and that would easily end up
in a maintenance nightmare.

> Then, speaking about the general picture and approach, (a) is mostly true on 
> x86 
> PVHv2 Dom0, while I don't see the point in also doing (b). Regarding (a), 
> it's 
> quite clear that some awareness by Dom0 is going to be needed when running as 
> Dom0 (report MCFG regions and the poweroff sequence at least) as much as I 
> would like to avoid that. Regarding (b), there are tables that we already 
> know 
> are completely useless to Dom0 ATM, like DMAR, SRAT, SLIT... IMHO, those 
> should 
> not be presented to Dom0 at all, because if they are presented now they 
> should 
> be ignored by Dom0, and if we ever want to somehow for example report NUMA 
> topology to Dom0, we would be screwed.

The tables you name really fall into the "used by Xen" category.

Jan


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