Hello, 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. 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. 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. * tbuf_size and tevt_mask The command line documentation for these refers to the xentrace(8) documentation, and AFAICT, selecting these on the hypervisor command line only serves to prevent xentrace's ability to set them at runtime. Given that xentrace can set them at runtime, and it is debugging functionality, I don't see a plausible use the command line options at all. * 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? 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
