Re: [Xen-devel] Command line options of dubious use

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 12:05, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/01/2019 14:04, Jan Beulich wrote:
>>>  dom0 (either PV, or PVH) cannot use the HPET
>>> safely, even if it is restricted to just read-only access.  Dom0 must
>>> under no circumstance interact directly with the hardware HPET, as it is
>>> a direct interrupt source.
>> But reads don't cause interrupts, do they?
> 
> No, but they do need to be performed under lock, and excluded against
> Xen actions.

That's for the result to be sensible, i.e. affecting Dom0. There's then
still no harm to Xen afaict.

>> Just like with the IO-APIC, the main problem here isn't going to be
>> the Dom0 kernel, but ACPI methods accessing certain pieces of
>> hardware. That's the price we pay for the split brain model we use
>> for dealing with ACPI. For this reason I'm afraid I would object to
>> any attempt to remove the option, despite the care that's needed
>> when wanting/needing to make use of it.
> 
> There can only be a single driver per HPET in the system.  In our case,
> that must be Xen, even if dom0 can see the HPET.
> 
> AML cannot use an HPET which is exposed to the OS, because it can't
> reasonably know whether the main counter is enabled or not,

It can read the config register.

> certainly
> can't play with the enablement of the main counter behind the OS's back,
> and can't safely use it in a read-only capacity because of spliced reads.
> 
> AML could in principle have a full HPET driver (as a timesource, if not
> an interrupt source), if it hid the HPET entirely from the OS, but in
> this case, it will explode on a read-only mapping.
> 
>>>  A related problem is that Linux has chipset
>>> quirks for missing HPET ACPI tables, and on some systems can manage to
>>> program the HPET behind Xen's back, resulting in chaos.  The default
>>> MMIO locations of these devices are standard nowadays, so we should
>>> probably blacklist mapping attempts completely.
>>>
>>> If there does happen to be something else adjacent to the HPET in the
>>> same page, the only safe way to handle the 4k frame as emulated MMIO,
>>> and forward accesses to the latter 3072 bytes to hardware.
>> Right; we didn't want to implement this until actually running into a
>> system in need of it.
> 
> So we opted for subtle timing bugs over obvious crashes, on the
> unrealistic offchance that AML is reading the HPET?

You take an unfortunate perspective here. In the similar IO-APIC
case, the reads or RTEs were - as far as I was able to tell from
analyzing two or three variants of affected AML code - completely
useless. Presumably just some debugging code left somewhere.
It seems quite desirable to be able to boot on such systems without
any oopses in Dom0.

> The mapping should either be non-existent (so we actually spot attempts
> to use it), or have a fully emulated HPET in it, with the rest of the 4k
> frame with emulated and forwarded.

That would indeed be best, in an ideal world.

>>> * vga = ask
>>>
>>> The single piece of keyboard interaction we have in Xen is the 16bit
>>> assembly code menu to display the graphics adapter modes.  This clearly
>>> isn't used in production due to it blocking for an answer, but does
>>> anyone use it in development?
>> It's been less than half a year ago that I had to use it.
>>
>>>  At the point that you can edit the boot
>>> command line to ask for the right mode, a suitable mode is already
>>> available in the bootloader.
>> But that's just one, not necessarily the one you'd like to use.
>> On the system that I needed to use it, the set of modes usable
>> at boot time (as reported by the VESA BIOS) was different from
>> the set reported at runtime (with X already active) by hwinfo or
>> some such, so picking a _reliably valid_ mode from the list
>> provided there was not possible.
> 
> So what you are saying is that, despite attempting to use the option, it
> didn't actually work usefully?

Sort of - I did obtain the desired mode when the system was fully up
(a 1280x1024 one), just to find that during boot it wouldn't work. I
tried one or two more (with different color depths) until I finally used
the "vga=ask" option to see what the BIOS reports valid at that
point. To my surprise, only 1024x768 modes were listed (on a pretty
recent nVidia card with 6GB of framebuffer).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel