Avi Kivity wrote: > Jan Kiszka wrote: >>>>> But I think I see a bigger issue - if we inject an regular interrupt >>>>> while another is pending, then we will encounter this problem. Looks >>>>> like we have to enable the interrupt window after injecting an >>>>> interrupt >>>>> if there are still pending interrupts. >>>>> >>>> Yeah, probably. I'm just wondering now if we can set >>>> exit-on-interrupt-window while the vcpu state is interruptible (ie. >>>> _before_ the injection). There is some entry check like this for NMIs, >>>> but maybe no for interrupts. Need to check. >>>> >>> Turns out it's not necessary, since the guest eoi will cause an exit and >>> allow the code to request an interrupt window. >>> >> >> But you added explicit handling now nevertheless? >> > > Yes, in case some eoi-less mode is introduced either by hardware or > paravirt. I regard the fact that it works as accidental (though applies > to x86 virtualization in general). > >>> I've added an apic test program so we can track these issues >>> (user/test/x86/apic.c). >>> >>> >> >> That's good. BTW, your NMI race fix is still lacking support for the >> -no-kvm-irqchip case. Will post an according patch later today. >> > > Actually, I couldn't get the 5.2 guest to boot with -no-kvm-irqchip: it > hangs and needs some help by running 'info registers'.
Oh, yes, someone borked something here. That must have happened just recently I think. And it must be a userspace bug as some older kvm that happened to hang around here (-74) works fine against latest kernel. No time to investigate further right now, sorry. Jan -- Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
