[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for logical pro
From: |
Zhao Liu |
Subject: |
Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for logical processors in the physical package |
Date: |
Tue, 3 Dec 2024 23:35:34 +0800 |
On Tue, Dec 03, 2024 at 11:04:12PM +0800, Xiaoyao Li wrote:
> Date: Tue, 3 Dec 2024 23:04:12 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for
> logical processors in the physical package
>
> On 12/3/2024 3:33 PM, Zhao Liu wrote:
> > > However, back to the patch, I think we cannot change it as this patch
> > > directly. Instead, we need a compat_props for the changed behavior,
> > > because
> > > this isn't a bug fix and it introduces guest-visible differences.
> >
> > This is a fix, not a new feature, so compat_props is not needed.
>
> Fix what? QEMU behaves as it for so many years and if the guest OS uses the
> algorithm recommended by SDM, there is no issue.
I've spent a lot time to explain why current behavior doesn't match the
SDM and real machine's implementation.
> > > For ancient Intel CPUs, EBX[23:16] did represent the number of Logical
> > > processor per package. I believe this should be the reason why QEMU
> > > implemented it as is:
> > >
> > > - on SDM version 013, EBX[23:16]: Number of logical processors per
> > > physical processor; two for the Pentium 4 processor supporting
> > > Hyper-Threading Technology.
> > >
> > > - on SDM version 015, it changed to: Number of initial APIC IDs
> > > reserved
> > > for this physical package. Normally, this is the number of logical
> > > processors per physical package.
> > >
> > > - on SDM version 016, it changed to: Maximum number of logical
> > > processors
> > > in this physical package.
> > >
> > > - finally, starting from SDM version 026, it changed to what reads now:
> > > Maximum number of addressable IDs for logical processors in this physical
> > > package.
> >
> > And this is an architecturally defined CPUID, so SDM ensures backward
> > compatibility.
>
> SDM ensure the backwards compatibility by recommending to round the number
> up to the power-of 2 when using it to calculate the topology with legacy
> method.
Please, *always* refer the latest SDM.
Regarding historical changes, older machines didn't have spare APIC ID
slots, so the actual number is the same as the maximum number of
addressable IDs.