On 12.03.2024 11:08, Vaishali Thakkar wrote:
> On 3/12/24 08:59, Jan Beulich wrote:
>> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>>> @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct
>>> cpu_user_regs *regs,
>>> /* Convert explicitely to boolean. Deals with l1 guests
>>> * that use flush-by-asid w/o checking the cpuid bits */
>>> nv->nv_flushp2m = !!ns_vmcb->tlb_control;
>>> - if ( svm->ns_guest_asid != ns_vmcb->_guest_asid )
>>> + if ( svm->ns_asid != ns_vmcb->_asid )
>>> {
>>> nv->nv_flushp2m = 1;
>>> hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
>>> - svm->ns_guest_asid = ns_vmcb->_guest_asid;
>>> + svm->ns_asid = ns_vmcb->_asid;
>>> }
>>>
>>> /* nested paging for the guest */
>>> @@ -1046,7 +1046,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct
>>> cpu_user_regs *regs)
>>> /* Keep it. It's maintainted by the l1 guest. */
>>>
>>> /* ASID */
>>> - /* ns_vmcb->_guest_asid = n2vmcb->_guest_asid; */
>>> + /* ns_vmcb->_asid = n2vmcb->_asid; */
>>
>> Unlike in the earlier patch, where I could accept the request to switch
>> to using accessor functions as scope-creep-ish, here I'm pretty firm
>> with my request to stop their open-coding at the same time. Unless of
>> course there's a technical reason the accessors cannot be used here.
>
> Yes, so as mentioned in the other patch's reply, I plan to tackle this
> instance too in the followup patchset along with others. So, if you're
> fine with it, I'll leave this one here for now. Unless you prefer otherwise.
I thought I said pretty clearly that here I'm stronger with my request
than on the other patch.
Jan
