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. Best regards, Maxim Levitsky > while the exception is pending. > This is currently not handled properly. > We can add/fix the indication with > ready_for_interrupt_injection, > but someone will ignore that > indication, so some handling > (like returning an error) should > be added. > So what would you propose the > KVM_SET_REGS should do if it is > called when an exception is pending? > The question is here because > currently KVM_SET_REGS and > KVM_SET_SREGS handle that differently: > one is trying to cancel the pending > excpetion, and the other one > does nothing, but both are wrong. >
