Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754903AbbBTPuD (ORCPT ); Fri, 20 Feb 2015 10:50:03 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:55800 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751870AbbBTPuA (ORCPT ); Fri, 20 Feb 2015 10:50:00 -0500 Date: Fri, 20 Feb 2015 16:49:44 +0100 From: Michael Mueller To: Alexander Graf Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Gleb Natapov , Christian Borntraeger , "Jason J. Herne" , Cornelia Huck , Paolo Bonzini , Andreas Faerber , Richard Henderson Subject: Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models Message-ID: <20150220164944.4eb4eeb3@bee> In-Reply-To: <89E3550E-9E2B-4D95-A809-B7C64EBCD7C5@suse.de> References: <1424183053-4310-1-git-send-email-mimu@linux.vnet.ibm.com> <1424183053-4310-5-git-send-email-mimu@linux.vnet.ibm.com> <54E73C8F.7000202@suse.de> <20150220160046.4743acc8@bee> <89E3550E-9E2B-4D95-A809-B7C64EBCD7C5@suse.de> Organization: IBM X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15022015-0013-0000-0000-00000309BF72 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 959 Lines: 25 On Fri, 20 Feb 2015 16:22:20 +0100 Alexander Graf wrote: > >> > >> Just make this uint64_t fac_list[2]. That way we don't have to track any > >> messy allocations. > > > > It will be something like "uint64_t fac_list[S390_CPU_FAC_LIST_SIZE_UINT64]" and in total 2KB > > not just 16 bytes but I will change it. > > Why? Do we actually need that many? This is a qemu internal struct. How do you know that 2 is a good size? I want to have this independent from a future machine of the z/Arch. The kernel stores the full facility set, KVM does and there is no good reason for QEMU not to do. If other accelerators decide to just implement 64 or 128 bits of facilities that's ok... Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/