On Thu, Feb 04, 2010 at 11:46:25PM +0200, Avi Kivity wrote: > On 02/04/2010 11:36 PM, Marcelo Tosatti wrote: > >On Thu, Feb 04, 2010 at 09:16:47PM +0200, Avi Kivity wrote: > >>On 01/28/2010 09:03 PM, Marcelo Tosatti wrote: > >>>A vcpu can be stopped after handling IO in userspace, > >>>but before returning to kernel to finish processing. > >>> > >>Is this strictly needed? If we teach qemu to migrate before > >>executing the pio request, I think we'll be all right? should work > >>at least for IN/INS, not sure about OUT/OUTS. > >It would be nice (instead of more state to keep track of between > >kernel/user) but the drawbacks i see are: > > > >You'd have to add a limitation so that any IN which was processed > >by device emulation has to re-entry kernel to complete it (so it > >complicates vcpu stop in userspace). > > > > You could fix that by moving the IN emulation to before guest entry. > It complicates the vcpu loop a bit, but is backwards compatible and > all that.
Under such scheme, to avoid a stream of IN's from temporarily blocking vcpu stop capability, you'd have to requeue a signal to stop the vcpu (so the next IN in the stream is not executed, but complete_pio does). Or not process the stop signal in the first place (new state for main loop, "pending pio/mmio"). Or even just copy the result from QEMU device to RAX in userspace, which is somewhat nasty since you'd have either userspace or kernel finishing the op. For REP OUTS larger than page size, the current position is held in RCX, but complete_pio uses vcpu->arch.pio.cur_count and count to hold the position. So you either make it possible to writeback vcpu->arch.pio to the kernel, or wait for the operation to finish (with similar complications regarding signal processing). As i see it, the benefit of backward compatibility is not worthwhile compared to the complications introduced to vcpu loop processing (and potential for damaging vcpu stop -> vcpu stopped latency). Are you certain its worth avoiding the restore ioctl for pio/mmio? > >And for OUTS larger than page size (== arch->pio_data size) you need to > >know the current position to continue it on the destination (or roll > >back the entire effect of the instruction in device emulation, and RIP). > > What to you mean by current position? > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
