From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 1/3] KVM: x86: add ioctls to get/set PIO state Date: Mon, 8 Feb 2010 20:41:19 -0200 Message-ID: <20100208224119.GA6516@amt.cnet> References: <20100128190300.414710338@redhat.com> <20100128190411.495771070@redhat.com> <4B6B1D1F.1080701@redhat.com> <20100204213643.GC2766@amt.cnet> <4B6B4031.80008@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, quintela@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58008 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751341Ab0BHWoK (ORCPT ); Mon, 8 Feb 2010 17:44:10 -0500 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o18MiA1P015285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Feb 2010 17:44:10 -0500 Content-Disposition: inline In-Reply-To: <4B6B4031.80008@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html