On 14/11/2023 10:14 am, Jan Beulich wrote: > On 13.11.2023 18:53, Roger Pau Monné wrote: >> On Mon, Nov 13, 2023 at 04:50:23PM +0000, Alejandro Vallejo wrote: >>> Signed-off-by: Alejandro Vallejo <[email protected]> >> I do wonder whether we need to take any precautions with guests being >> able to trigger an APIC reset, and thus seeing a changed LDR register >> if the guest happens to be migrated from an older hypervisor version >> that doesn't have this fix. IOW: I wonder whether Xen should keep the >> previous bogus LDR value across APIC resets for guests that have >> already seen it. > That earlier change deliberately fixed up any bogus values. I wonder > whether what you suggest will do more good or more harm than going > even farther and once again fixing up bad values in lapic_load_fixup(). > After all LDR being wrong affects vlapic_match_logical_addr()'s outcome. > I think one of the two wants adding to the change, though.
OS software doesn't reset the APIC at runtime. Most OS software doesn't reset the APIC ever because it was impossible to recover from on the first two generations of APIC. (It required a full platform reset and model-specific logic.) On capable APIC versions you still lose interrupts by resetting, which is why a reset will only ever occur prior to setting up IRQs on boot. Linux does now reset the APIC (where possible) on boot in order to clear out any prior state. This also translates to resetting on kexec/etc. A guest which does reset the APIC Is never going to care what the old value was. Only a test case is liable to notice, and we're clearly not running one of those or we'd have found this bug already. So no, I really don't think we need to keep a breakage around in the APIC emulation forevermore to work around a theoretical-only problem. We should however discuss this in the commit message, just in case someone in another 9y is trying to figure out a bug... ~Andrew
