[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 29.11.16 at 13:09, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Nov 29, 2016 at 04:44:18AM -0700, Jan Beulich wrote:
>> >>> 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.
> 
> Well, if we simply pass everything to Dom0, then Dom0 would need to know what 
> it 
> can use and what it cannot use, so you are just moving the problem away from 
> Xen 
> and into every Dom0 OS, in which case it's worse because we then need to 
> fixup 
> all the Dom0 OSes that we support.
> 
> Some entity either Dom0 or Xen needs to know which tables it can use and 
> which 
> tables it cannot use, and if we do this in Xen we avoid having to put all 
> this 
> logic in every Dom0 kernel.

Well, that's how it is supposed to work anyway, the more that we're
not talking about functionality at table granularity: The patch here
is about just some piece of a table, and if you think about e.g. PM
timer, that's also something which doesn't come with its own table,
yet Dom0 has to keep its hands off. Hence I think this is better
viewed the other way around: Dom0 should not use what isn't
explicitly or from an abstract perspective fine to use. Arguably
things like watchdog timers may be a gray area, as they might be
useful to both, and it might also be possible for Dom0 to use one if
Xen (perhaps dynamically, e.g. due to some command line option
decided not use it. Yet in such a case Dom0 should ask for Xen's
permission rather than blindly using it.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.