From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yx0E3-0007oY-Ih for qemu-devel@nongnu.org; Mon, 25 May 2015 17:48:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yx0Dy-0001xL-Im for qemu-devel@nongnu.org; Mon, 25 May 2015 17:47:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59313 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yx0Dy-0001xG-CH for qemu-devel@nongnu.org; Mon, 25 May 2015 17:47:54 -0400 Message-ID: <55639887.80302@suse.de> Date: Mon, 25 May 2015 23:47:51 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1432511251-22515-1-git-send-email-aurelien@aurel32.net> <1432511251-22515-8-git-send-email-aurelien@aurel32.net> <5563888A.5010705@suse.de> <20150525210219.GA28739@aurel32.net> <55638E4F.4090101@suse.de> <20150525211347.GA28361@aurel32.net> In-Reply-To: <20150525211347.GA28361@aurel32.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/10] target-s390x: enable fully implemented facilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Richard Henderson On 25.05.15 23:13, Aurelien Jarno wrote: > On 2015-05-25 23:04, Alexander Graf wrote: >> >> >> On 25.05.15 23:02, Aurelien Jarno wrote: >>> On 2015-05-25 22:39, Alexander Graf wrote: >>>> >>>> >>>> On 25.05.15 01:47, Aurelien Jarno wrote: >>>>> Cc: Alexander Graf >>>>> Cc: Richard Henderson >>>>> Signed-off-by: Aurelien Jarno >>>> >>>> Shouldn't this get populated based on the selected -cpu type? >>> >>> In the long term yes, but given we only implement one CPU type (or >>> rather none) in TCG mode, we can consider that's already the case. >> >> There are patches coming from IBM to at least add a list of a good >> number of s390x cpu types. I'd really like to make use of that and have >> actual CPU types selectable. > > I guess they are for the KVM mode. Do they provide the corresponding > facilities list? Probably otherwise that doesn't really differentiate > various CPUs. Please make sure of that when reviewing these patches. I could definitely use help on review - it's probably my weakest point ;). >> At least let's move towards that model. So the code in question should >> take the facility capabilities from the first cpu object (or the class?) >> for example and we bump it to the currently supported feature set in there. > > Yes, that would work for STFL/STFLE, though we should have a list of > facilities implemented by TCG so we can mask out the non-implemented > facilities. This basically corresponds to the informations provided by > the current patch. Ah, so you consider the current list the "these are the features TCG knows about" list? > That said that won't work for actually disabling the corresponding > instructions as we don't have a 1 to 1 mapping between the facilities > and the group of instructions. Anyway we don't even check that right > now. I agree, but the TCG code annotates which facility each opcode belongs to which means actually limiting it should become trivial. That's really all I'm asking for - I want to see the light at the end of the tunnel ;). Alex