>>> On 29.11.16 at 21:19, <andrew.coop...@citrix.com> 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....@citrix.com> wrote:
>>>> On Tue, Nov 29, 2016 at 03:40:37AM -0700, Jan Beulich wrote:
>>>>>>>> On 29.11.16 at 03:59, <shank...@codeaurora.org> 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 <shank...@codeaurora.org>
>>>>> 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
>>>> 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
>> and into every Dom0 OS, in which case it's worse because we then need to
>> all the Dom0 OSes that we support.
>> Some entity either Dom0 or Xen needs to know which tables it can use and
>> tables it cannot use, and if we do this in Xen we avoid having to put all
>> 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).
Xen-devel mailing list