> On 9 Oct 2018, at 20:54, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Tue, Oct 9, 2018 at 10:04 AM, Liran Alon <liran.alon@xxxxxxxxxx> 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. That’s why I asked if you plan to cleanup this mess as-well in v2 of this series or should I in a separate one? :P -Liran
