Re: [PATCH] xen/x86: On x2APIC mode, derive LDR from APIC_ID

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Nov 14, 2023 at 02:44:09PM +0000, Andrew Cooper wrote:
> 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.

Linux already accounts for this, vCPUs with APIC IDs > 255 won't be
used if there's no IOMMU or extended destination ID support:

https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/apic/apic.c#L1844

We should see how that goes once we allow APIC IDs > 255 for guests.

That makes me remember I should add an item to get extended
destination ID functional for Xen.

Thanks, Roger.