From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run Date: Wed, 20 May 2009 14:05:48 +0200 Message-ID: <4A13F21C.8060409@linux.vnet.ibm.com> References: <1241534358-32172-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1241534358-32172-2-git-send-email-ehrhardt@linux.vnet.ibm.com> <4A017C2E.6060306@redhat.com> <4A08217E.6000102@linux.vnet.ibm.com> <4A0824EF.5010201@redhat.com> <4A082C4E.60501@linux.vnet.ibm.com> <4A082FF3.4060908@redhat.com> <4A083956.2000200@linux.vnet.ibm.com> <4A083DCC.8000805@redhat.com> <4A093E1B.9030008@linux.vnet.ibm.com> <4A095EEA.60902@redhat.com> <4A097AA3.8000007@linux.vnet.ibm.com> <4A109056.2010003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm , Christian Borntraeger , Carsten Otte To: Avi Kivity Return-path: Received: from mtagate3.uk.ibm.com ([195.212.29.136]:34974 "EHLO mtagate3.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbZETMF4 (ORCPT ); Wed, 20 May 2009 08:05:56 -0400 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate3.uk.ibm.com (8.14.3/8.13.8) with ESMTP id n4KC5v8g502338 for ; Wed, 20 May 2009 12:05:57 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4KC5vlY1773600 for ; Wed, 20 May 2009 13:05:57 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4KC5vav005147 for ; Wed, 20 May 2009 13:05:57 +0100 In-Reply-To: <4A109056.2010003@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Christian Ehrhardt wrote: >>>>>> The bad thing on vcpu->request in that case is that I don't want= =20 >>>>>> the async behaviour of vcpu->requests in that case, I want the=20 >>>>>> memory slot updated in all vcpu's when the ioctl is returning. >>>>> >>>>> You mean, the hardware can access the vcpu control block even whe= n=20 >>>>> the vcpu is not running?=20 >>>> No, hardware only uses it with a running vcpu, but I realised my=20 >>>> own fault while changing the code to vcpu->request style. >>>> For s390 I need to update the KVM->arch and *all*=20 >>>> vcpu->arch->sie_block... data synchronously. >>> >>> Out of interest, can you explain why? >> Sure I'll try to give an example. >> >> a) The whole guest has "one" memory slot representing all it's=20 >> memory. Therefore some important values like guest_origin and=20 >> guest_memsize (one slot so it's just addr+size) are kept at VM level= =20 >> in kvm->arch. > > It should really be kept in kvm->memslots[0]->{userspace_addr,=20 > npages}. This is common to all architectures. As I said wanted to do that, but due to the need to relocate my work=20 environment to a new laptop I was a bit stalled the last few days. A patch series implementing it in a streamlined (storing in memslots=20 only, slots_lock, vcpu->request, ...) way will soon appear on the list. > [...] >> c) we have other code e.g. all our copy_from/to_guest stuff that use= s=20 >> the kvm->arch values > > You want to drop these and use kvm_read_guest() / kvm_write_guest(). I put it on my "low-prio-but-very-useful todo list" to take a look at=20 that too as one of the next opportunities to streamline our code. [...] --=20 Gr=C3=BCsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization