All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Chuang Xu <xuchuangxclwt@bytedance.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com,
	xieyongji@bytedance.com, imammedo@redhat.com,
	qemu-stable@nongnu.org, Guixiong Wei <weiguixiong@bytedance.com>,
	Yipeng Yin <yinyipeng@bytedance.com>
Subject: Re: [PATCH v2] i386/cpu: fixup number of addressable IDs for processor cores in the physical package
Date: Tue, 4 Jun 2024 17:43:03 +0800	[thread overview]
Message-ID: <Zl7hpyutlWN5iE+6@intel.com> (raw)
In-Reply-To: <20240603083641.97241-1-xuchuangxclwt@bytedance.com>

Hi Chuang,

On Mon, Jun 03, 2024 at 04:36:41PM +0800, Chuang Xu wrote:
> Date: Mon,  3 Jun 2024 16:36:41 +0800
> From: Chuang Xu <xuchuangxclwt@bytedance.com>
> Subject: [PATCH v2] i386/cpu: fixup number of addressable IDs for processor
>  cores in the physical package
> X-Mailer: git-send-email 2.24.3 (Apple Git-128)
> 
> When QEMU is started with:
> -cpu host,host-cache-info=on,l3-cache=off \
> -smp 2,sockets=1,dies=1,cores=1,threads=2
> Guest can't acquire maximum number of addressable IDs for processor cores in
> the physical package from CPUID[04H].
>
> When testing Intel TDX, guest attempts to acquire extended topology from CPUID[0bH],
> but because the TDX module doesn't provide the emulation of CPUID[0bH],
> guest will instead acquire extended topology from CPUID[04H]. However,
> due to QEMU's inaccurate emulation of CPUID[04H], one of the vcpus in 2c TDX
> guest would be offline.

I guess this case is based on downstream's TDX patches... Since TDX
hasn't landed in QEMU yet, it's a bit ahead of the curve to elaborate on
TDX-specific case.

Because normal VM will also face the such cache topology error, I think
it could be stated a bit more generically like:

When creating a CPU topology of 1 core per package, host-cache-info only
uses the Host's addressable core IDs field (CPUID.04H.EAX[bits 31-26]),
resulting in a conflict (on the multicore Host) between the Guest core
topology information in this field and the Guest's actual cores number.

Fix it by removing the unnecessary condition to cover 1 core per package
case. This is safe because cores_per_pkg will not be 0 and will be at
least 1.

> Fix it by removing the unnecessary condition.
> 
> Fixes: d7caf13b5fcf742e5680c1d3448ba070fc811644 ("x86: cpu: fixup number of addressable IDs for logical processors sharing cache")

12 characters (d7caf13b5fcf) is enough. No blank line. ;-)

> Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com>
> Signed-off-by: Yipeng Yin <yinyipeng@bytedance.com>
> Signed-off-by: Chuang Xu <xuchuangxclwt@bytedance.com>
> ---
>  target/i386/cpu.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index bc2dceb647..b68f7460db 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6426,10 +6426,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>              if (*eax & 31) {
>                  int host_vcpus_per_cache = 1 + ((*eax & 0x3FFC000) >> 14);
>  
> -                if (cores_per_pkg > 1) {
> -                    *eax &= ~0xFC000000;
> -                    *eax |= max_core_ids_in_package(&topo_info) << 26;
> -                }
> +                *eax &= ~0xFC000000;
> +                *eax |= max_core_ids_in_package(&topo_info) << 26;
>                  if (host_vcpus_per_cache > threads_per_pkg) {
>                      *eax &= ~0x3FFC000;
>  
> -- 
> 2.20.1
> 


  reply	other threads:[~2024-06-04  9:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03  8:36 [PATCH v2] i386/cpu: fixup number of addressable IDs for processor cores in the physical package Chuang Xu
2024-06-04  9:43 ` Zhao Liu [this message]
2024-06-04 14:53   ` Xiaoyao Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zl7hpyutlWN5iE+6@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=weiguixiong@bytedance.com \
    --cc=xieyongji@bytedance.com \
    --cc=xuchuangxclwt@bytedance.com \
    --cc=yinyipeng@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.