From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH 2/2]: kvm-s390: add KVM_S390_GET/SET_SREGS2 call for additional hw regs Date: Wed, 21 Dec 2011 07:52:17 +0100 Message-ID: <4EF18221.4090602@de.ibm.com> References: <4EF0577D.6010902@de.ibm.com> <4EF05AD0.8050808@redhat.com> <4EF05C9D.6040306@de.ibm.com> <4EF05EDA.2040604@redhat.com> <4EF07454.8000705@de.ibm.com> <4EF0B4C1.2010905@de.ibm.com> <2AE8A2B7-06BB-4091-ACFE-1D42A7851F61@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , KVM list , Cornelia Huck , Jens Freimann , Martin Schwidefsky , Heiko Carstens , Carsten Otte To: Alexander Graf Return-path: Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:45247 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751192Ab1LUGwX (ORCPT ); Wed, 21 Dec 2011 01:52:23 -0500 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Dec 2011 06:52:21 -0000 Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBL6qIE92789618 for ; Wed, 21 Dec 2011 06:52:18 GMT Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBL6qIid029923 for ; Tue, 20 Dec 2011 23:52:18 -0700 In-Reply-To: <2AE8A2B7-06BB-4091-ACFE-1D42A7851F61@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 20/12/11 17:28, Alexander Graf wrote: >>> Would it make sense to instead use the GET_ONE_REG and SET_ONE_REG interfaces? >>> >>> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/80854 What is the status of these patches? > >> - Is the interface limited to 56 registers? (see the ID) > > Uh. It's limited to 0x0fffffffffffffff registers per architecture :). Yes, I see. > Do you expect the prefix register to be synced often? If so, then you should maybe put it into kvm_struct > and always have it shared between kernel and user space, always updating it on every user space exit > and entry (you can optimize by checking if it changed). > > I don't think user space should worry about prefix too often though. Unless you expect anyone to DMA > into the CPU prefix area :). In theory: To be architecture compliant we actually must check for _every_ memory access to the guest if it is 0 < address < 8192 or prefix < address < prefix+8192 and swap that. Usually this should not not happen very often, but you dont know until you check. As of today: Only a small part of the guest OS actually touches the lowcore and current KVM guests never cause exits to qemu that have to deal with such an case - it was handled by SIE or by the host kernel - so not a problem. Future: Additional components and non-para-virtualized I/O will pass addresses in the prefix pages to some instructions that qemu might have to handle, so we might need that more often. To play safe, we might want to do the prefix translation for all handled intercepts. Then we would need the prefix value almost always. Christian