On 8/14/2023 7:59 AM, Zhao Liu wrote:
> Hi Qian,
>
> On Sun, Aug 13, 2023 at 06:49:40PM +0800, Wen, Qian wrote:
>
> [snip]
>
>>> also perhaps double check if we could do induce similar overflow
>>> tweaking other -smp properties (todo for another patch[es] if there are
>>> such places).
>> I have a check, the CPUID.0x4:EAX[31:26] indicates the Maximum number of
>> addressable IDs for processor cores in the physical package.
>> If we launch over 64 cores VM, the 6-bits field will also overflow. I will
>> add the following fix to patch2 in v3.
> Good catch!
>
> Just discussion, I find if we use APIC ID offset to encode 0x4, then it
> seems no need for an explicit check [1], right?
>
> [1]: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00027.html
Yes. The offset is always power of 2, so the value written to the 6-bit field
likes 0b1111, 0b11111, 0b111111, 0b1111111...
So, EAX[31:26] will be expected, i.e., 0x3f, when the value is overflow and
truncated.
>
> Thanks,
> Zhao
>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 52a2a1a1c7..9c1ae3d83d 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -243,6 +243,7 @@ static void encode_cache_cpuid4(CPUCacheInfo *cache,
>> cache->partitions * cache->sets);
>>
>> assert(num_apic_ids > 0);
>> + num_cores = num_cores > 64 ? 64 : num_cores;
>> *eax = CACHE_TYPE(cache->type) |
>> CACHE_LEVEL(cache->level) |
>> (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0) |
>>
>>
>> Thanks,
>> Qian
>>>>>> *edx |= CPUID_HT;
>>>>>> }
>>>>>> if (!cpu->enable_pmu) {
