Re: [PATCH] KVM: SVM: Remove TSS reloading code after VMEXIT

[Mingwei Zhang <mizhang@google.com>]

On Thu, May 18, 2023, Sean Christopherson wrote:
> On Thu, May 18, 2023, Mingwei Zhang wrote:
> > Remove TSS reloading code after VMEXIT since upstream KVM after [1] has
> > already been using VMLOAD to load host segment state (including TSS).
> > Therefore, reload_tss() becomes redundant. Because of that, also remove the
> > relevant data field tss_desc in svm_cpu_data as well as its data structure
> > definition.
> > 
> > [1] commit e79b91bb3c91 ("KVM: SVM: use vmsave/vmload for saving/restoring additionalhost state")
> 
> This should be
> 
> Fixes: e79b91bb3c91 ("KVM: SVM: use vmsave/vmload for saving/restoring additional host state")
> 
> to make it clear that the code could have, and should have, been removed by that
> commit.

Sure, will do in next version.
> 
> Can you also explain what happens with the TSS busy bit?  I'm staring at a comically
> long internal discussion about this patch, I would likely to capture the important
> bits in the changelog.  Doesn't have to be super verbose, e.g. just an explanation
> that makes it abundantly clear reload_tss() is fully redundant.
> 

Oh, the busy bit was not related with the removal. I was confused about
the busy bit being 0 when being loaded by LTR on SVM side. I thought
this was an inconsistency since on VMX side, immediately after VMEXIT,
TR.type == 11 (1011b) which means busy bit (bit 1) is 1 (SDM vol 3
28.5.2).

It turns out it was just my confusion, since busy bit is to prevent
reloading a 'busy' segment, i.e., if LTR reloads a 'busy' segment, it
triggers #GP at host level. To avoid that, KVM clear the bit in
reload_tss() and make it 'available' (that's why the value is 9).
Immediately after being loaded by LTR, the busy bit will be set again.

> > Reported-by: Venkatesh Srinivas <venkateshs@google.com>
> > Suggested-by: Jim Mattson <jmattson@google.com>
> > Tested-by: Mingwei Zhang <mizhang@google.com>
> 
> Heh, you wrote the code and sent the patch, so it darn well better be tested :-)
> There are scenarios where a Tested-by for the _original_ author is warranted, e.g.
> if someone else tweaked and reposted the patch.  But in this case, there's no need.

I see. I can remove the Tested-by.