On Thu, Jan 20, 2022 at 04:17:37PM +0000, Andrew Cooper wrote: > On 17/01/2022 10:36, Jan Beulich wrote: > > For one, "using_pit" shouldn't be set ahead of the function's last > > (for now: only) error path. Otherwise "clocksource=pit" on the command > > line can lead to misbehavior when actually taking that error path. > > > > And then make an implicit assumption explicit: CALIBRATE_FRAC cannot, > > for example, simply be changed to 10. The way init_pit() works, the > > upper bound on the calibration period is about 54ms. > > > > Signed-off-by: Jan Beulich <[email protected]> > > Acked-by: Andrew Cooper <[email protected]> > > > --- > > Really I've noticed this while considering what would happen if someone > > specified "clocksource=pit" on the shim's command line. Unlike "hpet" > > and "acpi", "pit" presently wouldn't be (explicitly) ignored. While, > > aiui, right now the only error path would be taken (due to port 0x61 > > reads being supposed to get back 0xff), I don't think we can build on > > that longer term: Seeing what we use port 0x61 for in traps.c, I think > > sooner or later we will need to have some form of emulation for it. Such > > emulation is then not unlikely to continuously report 0 in the bit in > > question. That would leed to an infinite loop here. > > If we're not already doing it, pv shim really ought to set the FADT > hardware reduced bits. There should be no need to depend on heuristics > around ~0.
We have talked about setting the hardware reduced flag for PVH, it's however tricky. For once hardware-reduced ACPI mandates the usage of UEFI firmware, which we don't yet fully support for PVH. And then we cannot set that flag for a PVH dom0, because we use a mix of crafted and native ACPI tables, so we risk that setting the bit creates incompatibilities with the native tables we expose. Roger.
