On Mon, 2023-01-09 at 16:29 +0000, Sean Christopherson wrote: > On Sat, Jan 07, 2023, Robert Hoo wrote: > > On Sat, 2023-01-07 at 00:38 +0000, Sean Christopherson wrote: > > > On Fri, Dec 09, 2022, Robert Hoo wrote: > > > > If LAM enabled, CR4.LAM_SUP is owned by guest; otherwise, > > > > reserved. > > > > > > Why is it passed through to the guest? > > > > I think no need to intercept guest's control over CR4.LAM_SUP, > > which > > controls LAM appliance to supervisor mode address. > > That's not a sufficient justification. KVM doesn't strictly need to > intercept > most CR4 bits, Yeah, that's also my experiential understanding. > but not intercepting has performance implications, e.g. KVM needs > to do a VMREAD(GUEST_CR4) to get LAM_SUP if the bit is pass > through. Right. On the other hand, intercepting has performance penalty by vm- exit, and much heavier. So, trade-off, right? > As a base > rule, KVM intercepts CR4 bits unless there's a reason not to, e.g. if > the CR4 bit > in question is written frequently by real guests and/or never > consumed by KVM. >From these 2 points to judge: CR4.LAM_SUP is written frequently by guest? I'm not sure, as native kernel enabling patch has LAM_U57 only yet, not sure its control will be per-process/thread or whole kernel-level. If it its use case is kasan kind of, would you expect it will be frequently guest written? Never consumed by KVM? false, e.g. kvm_untagged_addr() will read this bit. But not frequently, I think, at least by this patch set. So in general, you suggestion/preference? I'm all right on both choices.
