On 06/04/2023 10:59 am, Jan Beulich wrote:
> On 06.04.2023 11:52, Andrew Cooper wrote:
>> On 06/04/2023 10:31 am, Jan Beulich wrote:
>>> On 05.04.2023 22:44, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
>>>> +++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
>>>> @@ -450,6 +450,11 @@ struct vmcb_struct {
>>>>
>>>> uint64_t nrip;
>>>> } io;
>>>> + struct {
>>>> + uint64_t gpr:4;
>>>> + uint64_t :59;
>>>> + bool mov_insn:1; /* MOV, as opposed to LMSW, CLTS,
>>>> etc */
>>>> + } mov;
>>> The field being named just "mov" makes it apparently applicable to DRn
>>> moves, too (and the title supports this), yet the top bit doesn't have
>>> this meaning there. So perhaps say "MOV-CR" (or alike) in the comment?
>> Hmm - I'd not spotted that distinction.
>>
>> Xen never decodes the exitinfo for a DR access - we just resync dr
>> state, drop the intercept and reenter the guest.
>>
>> Therefore I think it would be better to rename "mov" to "mov_cr" so you
>> can't use the mov_insn field in a context that plausibly looks like a dr
>> access.
>>
>> Thoughts?
> That was my other thought; it merely seemed to me that updating the comment
> would allow future (if ever) use with MOV-DR. So yes, if you prefer going
> that route: Fine with me.
Will do. I don't foresee us ever needing to inspect the dr decode
information.
~Andrew
