From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ywzh0-0002vu-R2 for qemu-devel@nongnu.org; Mon, 25 May 2015 17:13:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ywzgz-0000GY-Hy for qemu-devel@nongnu.org; Mon, 25 May 2015 17:13:50 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:101::1]:45168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ywzgz-0000GK-D1 for qemu-devel@nongnu.org; Mon, 25 May 2015 17:13:49 -0400 Date: Mon, 25 May 2015 23:13:47 +0200 From: Aurelien Jarno Message-ID: <20150525211347.GA28361@aurel32.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55638E4F.4090101@suse.de> 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: Alexander Graf Cc: qemu-devel@nongnu.org, Richard Henderson 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. > 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. 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. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net