Gregory Haskins wrote: >>>> On Sun, Apr 22, 2007 at 4:50 AM, in message <[EMAIL PROTECTED]>, >>>> > Avi Kivity <[EMAIL PROTECTED]> wrote: > >> Gregory Haskins wrote: >> >>> /* >>> + * Signal that we have transitioned back to host mode >>> + */ >>> + spin_lock_irqsave(&vcpu- >irq.lock, irq_flags); >>> + vcpu- >irq.guest_mode = 0; >>> + spin_unlock_irqrestore(&vcpu- >irq.lock, irq_flags); >>> + >>> >>> >> You need to check for an interrupt here. Otherwise you might go back to >> user mode and sleep there, no? >> > > > It's subtle, but I'm not sure if you need to or not. I'm glad you brought it > up because its something I wanted to talk about. The case where interrupts > are raised outside the guest_mode brackets is obviously handled since we > inject a signal, so the area in question is while guest_mode = 1. > > In the simple case, an async-interrupt comes in and sends an IPI to cause a > VMEXIT. The guest exits with an EXTERNAL_INTERRUPT exception (IIUC), and the > current handler causes the system to loop back into the VMENTER code (and > thus injecting the interrupt). >
Okay. > If the guest exits because of HLT, this is also handled since the current > handle_halt() code checks if there are pending interrupts first before > allowing the halt. If there are interrupts, its loops back into VMENTER. > Okay. > For other cases, (e.g. the guest is VMEXITing for a reason other than the > IPI) the guest may need some userspace assistance: e.g. MMIO servicing, > exception handling, etc.. In this case, looping back to VMENTER would be > incorrect. The current code already handles this correctly too. However, > the potential problem (as you pointed out) is if the userspace wants to sleep > after servicing those types of requests, but doesn't realize that it cannot > due to a pending interrupt. I currently am not sure if this is a problem or > not since halt is handled. > I'm not sure either. It seems natural to assume that qemu will re-enter the guest without sleeping except for hlt. > Are there any other userspace sleeps that we need to handle (e.g. maybe AIO)? > If so, one way to handle this is to mark the exportable state of the VCPU > such that userspace can tell if interrupts are pending. However, I'm not > really sure if this is the best way to do it or if it can be easily done in a > way that doesn't break ABI compatiblity. Please advise. > The ABI can be extended by adding fields to struct kvm_vcpu_run and an extension check to indicate their availability. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
