On 09/10/2018 19:54, Jim Mattson wrote: >> Today, KVM_GET_VCPU_EVENTS IOCTL returns in events->exception.injected >> the value of (vcpu->arch.exception.pending || vcpu->arch.exception.injected). >> Which means userspace have no way of knowing if exception was re-injected >> and thus cannot be intercepted by L1 or it is still pending and therefore can be intercepted. >> >> Similarly, KVM_SET_VCPU_EVENTS IOCTL sets cpu->arch.exception.pending >> to the value of events->exception.injected. Which means userspace only have the >> ability to inject exceptions which cannot be intercepted by a L1 guest. >> >> Before this series, userspace must have assumed that exception cannot be intercepted >> as exception side-effects (payload) is assumed to already been done by userspace. >> Now however, it is possible for userspace to set a pending exception via IOCTL together >> with it’s pending exception such that it can be correctly intercepted by L1. > Yes, that seems like a mess that should be cleaned up and tied to the > new capability. Or perhaps it _is_ actually better to have a KVM_GET/SET_VCPU_EVENTS2 (or event just the "set") that is unrelated to the capability. Maybe that would make the code cleaner. Paolo
