From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxAoB-00045P-Fx for qemu-devel@nongnu.org; Tue, 26 May 2015 05:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxAo9-0000xU-A1 for qemu-devel@nongnu.org; Tue, 26 May 2015 05:05:59 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:101::1]:47708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxAo9-0000xK-4D for qemu-devel@nongnu.org; Tue, 26 May 2015 05:05:57 -0400 Date: Tue, 26 May 2015 11:05:54 +0200 From: Aurelien Jarno Message-ID: <20150526090554.GA12677@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> <20150525211347.GA28361@aurel32.net> <55639887.80302@suse.de> <20150526060216.GB28739@aurel32.net> <55642EE0.4000705@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55642EE0.4000705@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-26 10:29, Alexander Graf wrote: > > > On 26.05.15 08:02, Aurelien Jarno wrote: > > On 2015-05-25 23:47, Alexander Graf wrote: > >> > >> > >> 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 ;). > > > > It's trivial doing so for the facilities annotated in TCG. Just that > > they don't match one to one with the facilities bits in STFL/STFLE. Some > > bits enable multiple facilities and QEMU has also grouped some > > facilities together. Also some bits do not actually concern instructions > > but rather MMU features. Some other gives additional properties to a > > facility: some facilities might be present by disabled, some other might > > have a slow or fast implementation. > > > > We therefore need a conversion function before being able to do that, > > and we need to know which format IBM is going to provide in their > > patches: list of facilities or STFL/STFLE bits? > > Please check out this patch set: > > https://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg03436.html Thanks, at a first glance it seems we have what we need. I'll try to base my STFL/STFLE patches on this patchset in the next days. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net