From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 1/3] KVM: x86: add ioctls to get/set PIO state Date: Thu, 04 Feb 2010 23:46:25 +0200 Message-ID: <4B6B4031.80008@redhat.com> References: <20100128190300.414710338@redhat.com> <20100128190411.495771070@redhat.com> <4B6B1D1F.1080701@redhat.com> <20100204213643.GC2766@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, quintela@redhat.com To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22340 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413Ab0BDVqa (ORCPT ); Thu, 4 Feb 2010 16:46:30 -0500 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o14LkTFx008416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Feb 2010 16:46:30 -0500 In-Reply-To: <20100204213643.GC2766@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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.