Re: [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.02.2021 22:19, Boris Ostrovsky wrote:
> 
> On 2/22/21 6:08 AM, Roger Pau Monné wrote:
>> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>>> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
>>>> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
>>>>> When toolstack updates MSR policy, this MSR offset (which is the last
>>>>> index in the hypervisor MSR range) is used to indicate hypervisor
>>>>> behavior when guest accesses an MSR which is not explicitly emulated.
>>>> It's kind of weird to use an MSR to store this. I assume this is done
>>>> for migration reasons?
>>>
>>> Not really. It just seemed to me that MSR policy is the logical place to do 
>>> that. Because it *is* a policy of how to deal with such accesses, isn't it?
>> I agree that using the msr_policy seems like the most suitable place
>> to convey this information between the toolstack and Xen. I wonder if
>> it would be fine to have fields in msr_policy that don't directly
>> translate into an MSR value?
> 
> 
> We have xen_msr_entry_t.flags that we can use when passing policy array back 
> and forth. Then we can ignore xen_msr_entry_t.idx for that entry (although in 
> earlier version of this series Jan preferred to use idx and leave flags 
> alone).

Which, just to clarify, was not the least because of the flags
field being per-entry, i.e. per MSR, while here we want a global
indicator.

Jan