On 14/11/2023 2:11 pm, Roger Pau Monné wrote: > On Tue, Nov 14, 2023 at 12:55:46PM +0000, Andrew Cooper wrote: >> On 14/11/2023 12:32 pm, Jan Beulich wrote: >>> On 14.11.2023 13:18, Alejandro Vallejo wrote: >>>> On Tue, Nov 14, 2023 at 11:14:22AM +0100, Jan Beulich wrote: >>>>> On 13.11.2023 18:53, Roger Pau Monné wrote: >>>> I don't think vlapic_match_logical_addr() is affected. The LDR's are still >>>> unique in the bogus case so the matching ought to work. Problem would arise >>>> if the guest makes assumptions about APIC_ID and LDR relationships. >>> The LDRs still being unique (or not) isn't what I'm concerned about. It is >>> the function's return value which would be wrong, as the incoming "mda" >>> presumably was set in its respective field on the assumption that the LDRs >>> are set in a spec-compliant way. There not having been problem reports >>> makes me wonder whether any guests actually use logical delivery mode in a >>> wider fashion. >> They likely don't. >> >> Logical delivery for xAPIC only works in a tiny fraction of cases >> (assuming correct topology information, which we don't give), and >> persuading a VM to turn on x2APIC without a vIOMMU is not something >> we've managed to do in Xen. > We do, in fact the pvshim (or nested Xen) will run in x2APIC mode if > available. > Linux >= 5.17 will also use x2APIC mode if available when running as a > Xen HVM guest: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8980fcb210851138cb34c9a8cb0cf0c09f07bf9
Yeah that's never actually been tested with 256 vCPUs. A VM *must* have either a vIOMMU, or know (via whatever means) that there are no IO-APICs, or (via whatever means) that all IO-APICs can use reserved bits for 32k destination APIC ID support. As it stands, this is just something which will explode on us in the future. Hopefully the worst that will happen is a panic on boot. > If a guest has been booted with the bogus LDR we need to keep it on > migrate, otherwise at least Xen will break (because it does read the > LDR from the hardware instead of building it based on the APIC ID). Of course. That would be data corruption otherwise. > Switching to the correct LDR on APIC reset can be sensible, any APIC > device reset should be done together with updating whatever registers > have been previously cached, and OSes don't do APIC resets anyway. Yes. We can just set it properly on reset and the problem ought to disappear. ~Andrew
