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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.12.18 at 19:46, <andrew.cooper3@xxxxxxxxxx> wrote:
> As I've spent a while staring at the command line docs recently, I've
> come to the conclusion that we should probably remove these:
> 
> * ro-hpet
> 
> I'm afraid that I didn't spot this one going in, and would have objected
> to it if I'd found it.

Not how the commit introducing this actually tightened things,
rather than (like you make it sound) unduly relaxing them. The
option was introduced as a safe guard in case people run into
problems.

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

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.

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

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

Jan



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