[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 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.

Roger.

_______________________________________________
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®.