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: Tue, 09 Feb 2010 08:38:56 +0200 Message-ID: <4B710300.7090903@redhat.com> References: <20100128190300.414710338@redhat.com> <20100128190411.495771070@redhat.com> <4B6B1D1F.1080701@redhat.com> <20100204213643.GC2766@amt.cnet> <4B6B4031.80008@redhat.com> <20100208224119.GA6516@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]:50974 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752793Ab0BIGjA (ORCPT ); Tue, 9 Feb 2010 01:39:00 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o196d0P6031736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Feb 2010 01:39:00 -0500 In-Reply-To: <20100208224119.GA6516@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 02/09/2010 12:41 AM, Marcelo Tosatti wrote: > 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"). > Why? you would handle stops exactly the same way: vcpu_loop: while running: process_last_in() run_vcpu() handle_exit_except_in() An IN that is stopped would simply be unprocessed, and the next entry, if at a new host, will simply re-execute it. > 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. > Definitely bad. > 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). > RCX is always consistent, no? So if we migrate in the middle of REP OUTS, the operation will restart at the correct place? > 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? > First, let's see if it's feasible or not. If it's feasible, it's probably just a matter of rearranging things to get userspace sane. A small price to pay for backward compatibility. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.