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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

> 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, 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?

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.

>
>> * 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?

~Andrew

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