From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgj2h-0000vP-1L for qemu-devel@nongnu.org; Thu, 27 Aug 2009 13:45:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgj2c-0000ur-7n for qemu-devel@nongnu.org; Thu, 27 Aug 2009 13:45:46 -0400 Received: from [199.232.76.173] (port=59221 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgj2b-0000ul-Vm for qemu-devel@nongnu.org; Thu, 27 Aug 2009 13:45:42 -0400 Received: from thoth.sbs.de ([192.35.17.2]:23667) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mgj2b-0006OP-Ap for qemu-devel@nongnu.org; Thu, 27 Aug 2009 13:45:41 -0400 Message-ID: <4A96C643.4080306@siemens.com> Date: Thu, 27 Aug 2009 19:45:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1247781328-17249-1-git-send-email-glommer@redhat.com> <4A96BF30.7090200@siemens.com> <20090827174036.GC5746@mothafucka.localdomain> In-Reply-To: <20090827174036.GC5746@mothafucka.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: "aliguori@us.ibm.com" , "qemu-devel@nongnu.org" , Avi Kivity Glauber Costa wrote: > On Thu, Aug 27, 2009 at 07:15:28PM +0200, Jan Kiszka wrote: >> Glauber Costa wrote: >>> on_vcpu is a qemu-kvm function that will make sure that a specific >>> piece of code will run on a requested cpu. We don't need that because >>> we're restricted to -smp 1 right now, but those days are likely to end soon. >>> >>> So for the benefit of having qemu-kvm share more code with us, I'm >>> introducing our own version of on_vcpu(). Right now, we either run >>> a function on the current cpu, or abort the execution, because it would >>> mean something is seriously wrong. >>> >>> As an example code, I "ported" kvm_update_guest_debug to use it, >>> with some slight differences from qemu-kvm. >>> >>> This is probably 0.12 material >>> >>> Signed-off-by: Glauber Costa >>> CC: Jan Kiszka >>> --- >>> kvm-all.c | 35 +++++++++++++++++++++++++++++------ >>> 1 files changed, 29 insertions(+), 6 deletions(-) >>> >>> diff --git a/kvm-all.c b/kvm-all.c >>> index 61194b8..07a1cdb 100644 >>> --- a/kvm-all.c >>> +++ b/kvm-all.c >>> @@ -155,6 +155,15 @@ static void kvm_reset_vcpu(void *opaque) >>> } >>> } >>> >>> +static void on_vcpu(CPUState *env, void (*func)(void *data), void *data) >>> +{ >>> + if (env == cpu_single_env) { >>> + func(data); >>> + return; >>> + } >>> + abort(); >> Sorry, missed this before it went in: This abort fires already now when >> kvm_update_guest_debug is invoked by the gdbstub (where cpu_single_env >> is 0). This completely breaks guest debugging int kvm mode. >> >> Moreover, if you enable I/O thread support, you already have a need for >> true on_vcpu, don't you? Or is locking around the I/O thread still >> broken in kvm mode? Anyway, please fix. > It is, but I just sent two patches that would leave us in a better shape. > Not sure what was made of them. > > Anyway, I still have something almost ready for on_vcpu. > Actually, I want to hear input on it: I was thinking the best architecture > would be to drop it completely, and do automatically whenever we call vcpu_ioctl. > My only concern then would be speed. In this case, we could make this non-blocking, > and introduce explicit flush requests for remote cpus. > > What do you think about it ? Is on_vcpu only used for issuing vcpu_ioctl? Then combining both is surely a reasonable step. If you are concerned about performance, I think crafting a first version over qemu-kvm, probably also merging it into that branch first makes some sense. Though I think we should get along with a simple test for the caller context in vcpu_ioctl for the fast path. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux