On Tue, Jul 6, 2021 at 4:06 PM stsp <stsp2@xxxxxxxxx> wrote: > > 07.07.2021 02:00, Maxim Levitsky пишет: > > On Wed, 2021-07-07 at 00:50 +0300, stsp wrote: > >> 06.07.2021 23:29, Maxim Levitsky пишет: > >>> On Tue, 2021-07-06 at 15:06 +0300, stsp wrote: > >>>> 06.07.2021 14:49, Maxim Levitsky пишет: > >>>>> Now about the KVM's userspace API where this is exposed: > >>>>> > >>>>> I see now too that KVM_SET_REGS clears the pending exception. > >>>>> This is new to me and it is IMHO *wrong* thing to do. > >>>>> However I bet that someone somewhere depends on this, > >>>>> since this behavior is very old. > >>>> What alternative would you suggest? > >>>> Check for ready_for_interrupt_injection > >>>> and never call KVM_SET_REGS if it indicates > >>>> "not ready"? > >>>> But what if someone calls it nevertheless? > >>>> Perhaps return an error from KVM_SET_REGS > >>>> if exception is pending? Also KVM_SET_SREGS > >>>> needs some treatment here too, as it can > >>>> also be called when an exception is pending, > >>>> leading to problems. > >>> As I explained you can call KVM_GET_VCPU_EVENTS before calling > >>> KVM_SET_REGS and then call KVM_SET_VCPU_EVENTS with the struct > >>> that was filled by KVM_GET_VCPU_EVENTS. > >>> That will preserve all the cpu events. > >> The question is different. > >> I wonder how _should_ the KVM > >> API behave when someone calls > >> KVM_SET_REGS/KVM_SET_SREGS > > KVM_SET_REGS should not clear the pending exception. > > but fixing this can break API compatibilitly if some > > hypervisor (not qemu) relies on it. > > > > Thus either a new ioctl is needed or as I said, > > KVM_GET_VCPU_EVENTS/KVM_SET_VCPU_EVENTS can be used > > to preserve the events around that call as workaround. > But I don't need to preserve > events. Canceling is perfectly > fine with me because, if I inject > the interrupt at that point, the > exception will be re-triggered > anyway after interrupt handler > returns. The exception will not be re-triggered if it was a trap, because the instruction that caused the exception will already have retired, and RIP will have advanced. Moreover, if the exception had any side-effects (#PF and sometimes #DB), those side-effects have already happened, so if IDT vectoring is cancelled, the vCPU is left in an architecturally unreachable state. > What I ask is how SHOULD the > KVM_SET_REGS and KVM_SET_SREGS > behave when someone (mistakenly) > calls them with the exception pending. > Should they return an error > instead of canceling exception?
