Avi Kivity wrote: > On 02/10/2010 06:25 PM, Marcelo Tosatti wrote: >> On Wed, Feb 10, 2010 at 09:02:00AM +0200, Avi Kivity wrote: >> >>> On 02/09/2010 10:58 PM, Marcelo Tosatti wrote: >>> >>>> You're right... this should be enough to avoid a stop with uncomplete >>>> PIO (and this is what happens for MMIO already). The signal will not >>>> be dequeued, so KVM will complete_pio and exit before entering with >>>> -EAGAIN. Please review and queue for stable. >>>> >>>> >>> Not right enough. This is very fragile, we depend on the kernel >>> noticing the signal after completing pio but before starting >>> execution. I don't think we guarantee that. >>> >> As long as the signal is blocked, we do (and for older kernels too). >> > > I meant, that was not an intentional part of the design, but rather a > side effect of the implementation. We can pretend it was all part of > a master plan and document it, though. > >>> Maybe we should turn complete_pio/complete_mmio to an ioctl, so that >>> we can control what happens exactly. Or maybe it's simplest to >>> document it as a feature and guarantee it. There's some merit in it >>> - only guest execution is the nonatomic part, so we only interrupt >>> that. >>> >> Right. So would you like a patch to x86.c to comment on this, on top of >> complete_pio / mmio completion? >> > > Documentation/kvm/api.txt. Note it's not x86 specific. Alex, can you > check if ppc complies? Hrm, trying to read the thread I'm still somewhat lost. What exactly do you want to document? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
