> >>>>>+ } >>>> >>>> >>>> A possible optimization would be to check if we have an irq to >> inject. >>>> If we have, then ignore the signal and enter guest mode. >>>> Since an irq is already pending, the signal would not be resulting in >>>> another irq injection. >>>> What do you think? >>> >>>I am a little fuzzy on whether this is necessary myself. The >> motivation >>>for this code block originally was really more for the cases where >> signals >>>are sent that *aren't* related to interrupts. For instance, what if >> QEMU >>>was trying to force the vCPU to exit for some reason (e.g. an AIO >>>completion event that has to be decoded by userspace before a IRQ is >>>generated)? If the signal is queued beforehand AND linux doesn't >> already >>>reschedule things for us, I think there is a race against the VCPU >> being >>>stuck in guest mode until the next (unrelated) VMEXIT since the IPI >> would >>>have already happened. This code (I believe) closes the window on that >>>scenario. I am just not sure if its a realistic one. Perhaps someone >> with >>>more linux signal handling knowledge than myself can chime in and >> confirm? >>>(And I am not saying that person isn't you, Dor. I am only saying it >> isn't >>>me ;) >> >> >> You're right that there is a slight chance for a qemu signal such as AIO >> completion to reach right after we enter the kernel. My intention was to >> unit the signal pending checks - there is another one after the guest >> exits vmx mode. Then once we're back on host mode we can optimize the >> path by checking whether we need to re- inject in- kernel- apic pending >irq >> or a case where a physical irq prevented us from injecting the virq. >> >> The optimization is not specific to apic and can take place even now. > >I'm not entirely following you, but you if elaborate a little more perhaps >I can get it incorporated. Otherwise, we could just wait till this logic >is merged and do a follow on patch. >
I was thinking of optimize cases where the guest exits vmx mode but has virq to inject. In that point a signal might be pending. The current code exits to userspace although userspace would not be able to inject another irq before the pending one will be injected. Instead, don't exit to userspace and inject the pending irq. I'm not sure it will make a big different. At least collapsing the two places we check for signal is good. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
