Re: [Xen-devel] [PATCH 10/12] docs/migration: Specify X86_{CPUID, MSR}_POLICY records

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.01.2020 15:55, Andrew Cooper wrote:
> 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.

Isn't the same true for CPUID, in particular some of the non-boolean
fields?

> 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.

Hmm, yes. Still the special casing of there needing to be at least
one entry looks a little odd here (and also for CPUID). I would
find it more logical if there was just the remainder-must-be-zero
check. But this is libxc code, so I'm not the one to really judge
anyway.

Jan

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