On 03/01/2020 14:49, Jan Beulich wrote:
> On 24.12.2019 16:19, Andrew Cooper wrote:
>> @@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
>> raise RecordError("Static data end record found in v2 stream")
>>
>>
>> + def verify_record_x86_cpuid_policy(self, content):
>> + """ x86 CPUID policy record """
>> +
>> + if self.version < 3:
>> + raise RecordError("x86 CPUID policy record found in v2 stream")
>> +
>> + sz = calcsize(X86_CPUID_POLICY_FORMAT)
>> + contentsz = len(content)
>> +
>> + if contentsz < sz or (contentsz % sz) != 0:
>> + raise RecordError("Record length %u, expected multiple of %u" %
>> + (contentsz, sz))
>> +
>> +
>> + def verify_record_x86_msr_policy(self, content):
>> + """ x86 MSR policy record """
>> +
>> + if self.version < 3:
>> + raise RecordError("x86 MSR policy record found in v2 stream")
>> +
>> + sz = calcsize(X86_MSR_POLICY_FORMAT)
>> + contentsz = len(content)
>> +
>> + if contentsz < sz or (contentsz % sz) != 0:
>> + raise RecordError("Record length %u, expected multiple of %u" %
>> + (contentsz, sz))
> While I can't even see a theoretical case of the CPUID array
> having zero elements, is it really entirely implausible to have
> an empty MSRs array? I.e. wouldn't the left side of the "or"
> better go away?
MSRs will never have 0 entries, because unlike CPUID, we can't omit
records with 0s as their content. This becomes ambiguous when the
policy default is nonzero.
When we do gain more MSRs, I will see about organising elision based on
CPUID features, so we don't have to send a 0 for every single MSR in the
policy, but MSRs without CPUID enumeration must always be sent.
This means that the one MSR we have currently (MSR_INTEL_PLATFORM_INFO
for CPUID Faulting, which we also virtualise on AMD hardware) shall
unconditionally be present forever more.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
