From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)
Date: Wed, 11 May 2016 14:37:38 +0200 [thread overview]
Message-ID: <20160511123733.GG12472@potion> (raw)
In-Reply-To: <20160510195336.GA4457@thinpad.lan.raisama.net>
2016-05-10 16:53-0300, Eduardo Habkost:
> On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote:
>> I looked at a dozen Intel CPU that have this CPUID and all of them
>> always had Core offset as 1 (a wasted bit when hyperthreading is
>> disabled) and Package offset at least 4 (wasted bits at <= 4 cores).
>>
>> QEMU uses more compact IDs and it doesn't make much sense to change it
>> now. I keep the SMT and Core sub-leaves even if there is just one
>> thread/core; it makes the code simpler and there should be no harm.
>
> If in the future we really want to make the APIC ID offsets match
> the CPUs you looked at, we can add extra X86CPU properties to
> allow configuration of APIC ID bit offsets larger than the ones
> calculated from smp_cores and smp_threads.
Sounds good. No hurry with that as virt has no problem with routing a
x2APIC cluster that covers two packages and I'm not sure what the
reasoning for HT is.
> What about compatiblity on migration? With this patch, guests
> will see CPUID data change when upgrading QEMU.
Ah, thanks, I always forget that QEMU doesn't migrate all configuration
and has machine types ...
I don't think that we can directly override values from cpu_x86_cpuid()
with machine type wrappers. What about adding a compatibility flags
into X86CPUDefinition and assigning one flag to disable CPUID 0xB, or a
global flag?
>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>> ---
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> @@ -2460,6 +2461,32 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>> + switch (*ecx) {
>> + case 0:
>> + *eax = apicid_core_offset(smp_cores, smp_threads);
>> + *ebx = smp_threads;
>> + *ecx |= CPUID_TOPOLOGY_LEVEL_SMT;
>> + break;
>> + case 1:
>> + *eax = apicid_pkg_offset(smp_cores, smp_threads);
>> + *ebx = smp_cores * smp_threads;
>> + *ecx |= CPUID_TOPOLOGY_LEVEL_CORE;
>> + break;
>> + default:
>> + *eax = 0;
>> + *ebx = 0;
>> + *ecx |= CPUID_TOPOLOGY_LEVEL_INVALID;
>> + }
>> +
>> + /* Preserve reserved bits. Extremely unlikely to make a difference. */
>> + *eax &= 0x1f;
>> + *ebx &= 0xffff;
>
> That means we don't know how to handle apicid_*_offset() >= 32,
> smp_threads > 2^16, or smp_cores * smp_threads > 2^16. If that
> happen one day, I would prefer to see QEMU abort than silently
> truncating data in CPUID[0xB]. What about an assert()?
I skipped an assert because the spec says that *ebx cannot be taken
seriously, so killing the guest didn't seem worth it:
Software must not use EBX[15:0] to enumerate processor topology of the
system. This value in this field (EBX[15:0]) is only intended for
display/diagnostic purposes. The actual number of logical processors
available to BIOS/OS/Applications may be different from the value of
EBX[15:0], depending on software and platform hardware configurations.
I'd warn, but I don't know if 'printf' is ok, so I skipped it too,
because the overflow really doesn't matter.
next prev parent reply other threads:[~2016-05-11 12:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 20:49 [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration) Radim Krčmář
2016-05-10 12:23 ` Radim Krčmář
2016-05-10 19:53 ` Eduardo Habkost
2016-05-11 12:37 ` Radim Krčmář [this message]
2016-05-11 15:26 ` Eduardo Habkost
2016-05-11 15:59 ` Radim Krčmář
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=20160511123733.GG12472@potion \
--to=rkrcmar@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).