[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 for 4.13] x86/e820: fix 640k - 1M region reservation logic



On 31.10.2019 12:45, Sergey Dyasli wrote:
> On 31/10/2019 11:07, Jan Beulich wrote:
>> On 31.10.2019 11:56, Sergey Dyasli wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5943,7 +5943,7 @@ const struct platform_bad_page *__init 
>>> get_platform_badpages(unsigned int *array
>>>      case 0x000806e0: /* erratum KBL??? */
>>>      case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
>>>          *array_size = (cpuid_eax(0) >= 7 &&
>>> -                       !(cpuid_ecx(1) & 
>>> cpufeat_mask(X86_FEATURE_HYPERVISOR)) &&
>>> +                       !early_cpu_has_hypervisor() &&
>>
>> Strictly speaking this makes clear that in early_cpu_has_hypervisor()
>> you should also check cpuid_eax(0) >= 1. We don't currently seem to
>> object to running on a system with only basic leaf 0 available (we
>> do object to there not being extended leaf 1). Andrew, do you have
>> any clear opinion one way or the other?
> 
> What gave you that impression? early_cpu_init() and generic_identify()
> do cpuid(0x1) unconditionally.

"do cpuid(0x1) unconditionally" != "object to running on a system
with only basic leaf 0 available", i.e. that code is simply buggy as
long as we don't elsewhere panic() if there's only leaf 0 available.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.