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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 29 Nov 2016, Roger Pau Monne wrote:
> On Tue, Nov 29, 2016 at 06:07:36AM -0700, Jan Beulich wrote:
> > >>> 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.

We do need to keep an eye on ASWG activity going forward. Fortunately
some of the people in the Xen community work for companies that are
members and can do it.


> > > 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.
> 
> I would say that everything that Xen can fix from static tables, Xen should 
> do 
> it. Then there are pieces that simply Xen cannot get it's hands on, because 
> the 
> description is in dynamic tables, and there we have to play tricks either 
> with 
> Dom0 or with ACPI overwrites like the STAO (which is under our control and we 
> can modify it's specification at will).

That's exactly right.


> > 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.
> 
> IMHO, the best way to ask for such permissions is to fixup the tables so that 
> Dom0 knows whether those devices/functionality can be used or not. Creating an
> out-of-band method to delivery this information when there's already a native 
> way to do it (and can be implemented in Xen) is sub-optimal.

I completely agree.

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