[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 Wed, Nov 30, 2016 at 01:54:00AM -0700, Jan Beulich wrote:
> >>> On 29.11.16 at 21:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 29/11/16 12:09, Roger Pau Monne 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.
> > 
> > Dom0 should have nothing which isn't explicitly whitelisted as ok by Xen.
> > 
> > The culture of the blacklist model which has existing for much of Xen's
> > history is a broken concept.
> > 
> > I have spent a long time trying to undo the damage caused by this
> > culture with the CPUID levelling work, and there is a lot more to do
> > (e.g. MSR levelling) which needs to be done at some point.  While these
> > are examples which typically crash guests, the same whitelist/blacklist
> > arguments apply to situations like this.
> 
> All understood. Still I'm afraid using white listing for ACPI tables is
> going to be functionally more limiting than doing do for e.g. CPUID,
> as it's going to be hard to ever get a complete picture of all tables,
> namely including OEM ones. Not to speak of possible references
> between tables (or from AML to static tables, an example of which
> we even have in the ACPI tables we build for HVM guests, where
> the processor objects reference MADT).

How this is implemented now on x86 allows to turn it into a whitelist with a 
couple of line changes.

Now, I don't really have a strong opinion either way, both implementations have 
it's downsides. With blacklisting we risk passing tables to the guest that 
contain information that breaks the hardware description (either because the 
hardware is not available or not properly passed-through by Xen). While with 
whitelisting, we risk missing some OEM tables or tables referenced from AML. I 
guess we can move this discussion to the PVHv2 Dom0 thread.

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