On 18/07/2025 2:28 pm, Jan Beulich wrote:
>> uint16_t model;
> Whereas the model is strictly limited to 8 bits.
There is space in here, if we need it, but you can't shrink it without
breaking the check for the NULL entry (going back to the first
obfuscation).
>>> Breaki
On 18.07.2025 12:29, Andrew Cooper wrote:
> On 18/07/2025 6:53 am, Jan Beulich wrote:
>> On 17.07.2025 21:39, Andrew Cooper wrote:
>>> On 17/07/2025 9:11 am, Jan Beulich wrote:
On 16.07.2025 19:31, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
On 18/07/2025 6:53 am, Jan Beulich wrote:
> On 17.07.2025 21:39, Andrew Cooper wrote:
>> On 17/07/2025 9:11 am, Jan Beulich wrote:
>>> On 16.07.2025 19:31, Andrew Cooper wrote:
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -1003,13 +1003,15 @@ const struct x86_cp
On 17.07.2025 21:39, Andrew Cooper wrote:
> On 17/07/2025 9:11 am, Jan Beulich wrote:
>> On 16.07.2025 19:31, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -1003,13 +1003,15 @@ const struct x86_cpu_id *x86_match_cpu(const struct
>>> x86_cpu_id
On 17/07/2025 9:11 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -1003,13 +1003,15 @@ const struct x86_cpu_id *x86_match_cpu(const struct
>> x86_cpu_id table[])
>> const struct x86_cpu_id *m;
>>
On 16.07.2025 19:31, Andrew Cooper wrote:
> Architecturally, stepping is a 4-bit field, so a uint16_t suffices for a
> bitmap of steppings.
>
> In order to keep the size of struct x86_cpu_id the same, shrink the vendor and
> family fields, neither of which need to be uint16_t in Xen.
>
> No funct
