On Tue, Sep 15, 2026, Sohil Mehta wrote: > On 9/15/2026 7:04 AM, Sean Christopherson wrote: > > That said, I love Sohil's idea of adding a function comment. Someting > > along the > > lines of "The basic flow is this: <example>, but the actual behavior is far > > more > > subtle due to many exceptions and edge cases". > > Great, how about this?
LGTM. > > /* > > * Check if an access violates LASS purely based on bit 63 of the linear > > address > > * and whether the access targets the "wrong" half of the address space. The > > * basic flow is straightforward: > > * > > * if (exempt from LASS) > > * no violation; > > * else if (user access) > > * violation when address is in the supervisor half; > > * else > > * violation when address is in the user half; > > * > > * but the actual behavior is far more subtle due to the many exceptions and > > * edge cases. For example, the implementation depends on which accesses are > > * exempt, what constitutes a user access, and how supervisor data accesses > > * differ from instruction fetches. > > */ > > bool vmx_is_lass_violation(struct kvm_vcpu *vcpu, gva_t gva, > > unsigned int size, unsigned int flags) > > > > Sean, other than this, do you want to see any big change in the series? Dunno, I haven't looked at anything else in the series, I just saw that I got summoned :-) It's on my list of things to review, but I'm behind on reviews this kernel cycle for a variety of reasons. > The sashiko complains are false-positives. There are a couple of nits to > be addressed, and I need to change Binbin's SoBs into Reviewed-bys. > Otherwise, I think the series (1-5) is getting ready to be picked up. >
