From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZJuy-0006WR-8g for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:40:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZJuw-0001Qv-IO for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:40:16 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:50150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZJuw-0001Qj-6Z for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:40:14 -0400 Received: by pzk30 with SMTP id 30so435202pzk.4 for ; Wed, 22 Jun 2011 02:40:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1308660911-9840-1-git-send-email-jamie.iles@picochip.com> <20110621161300.GK2647@pulham.picochip.com> Date: Wed, 22 Jun 2011 10:40:12 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Iles Cc: Jamie Iles , qemu-devel@nongnu.org, Aurelien Jarno , Paul Brook On 22 June 2011 00:42, Jamie Iles wrote: > On 21 June 2011 23:13, Peter Maydell wrote: >> Ah yes, sorry, I misread the TRM there. So it does have those, it's >> just the SEV/WFI/WFE it is missing. I guess we'll want an >> ARM_FEATURE_VAPA too. > > Could we perhaps infer and detect some of these features? =C2=A0For examp= le, > my reading of the ARM ARM says that the VA<->PA translation registers > exist for >v7 or v6k if the security extensions exist. =C2=A0We can detec= t > the security extensions from the cpuid registers so we could > automatically set that feature. I thought about that, but there are a couple of reasons I'd rather not detect things from the cpuid/feature registers: * older cores don't have them, so you need to cope without them anyway * there's a tension between "emulate the same feature regs as the h/w" and "emulate feature regs matching what we implement" -- some guest OSes will actually refuse to boot unless they get exact matches on the feature reg values... (At the moment we tend to the former, so we probably advertise the security extensions even though we don't implement them, for instance) * at the moment the feature regs are just random hex values in helper.c; if we wanted to drive things from them we'd need to set up a lot of enumerations and constants anyway in order to have something maintainabl= e Inferring ARM_FEATURE_foo flags from other ARM_FEATURE_foo flags is fine, though. Mostly what I'd like is for the actual code implementing things to be gated on a fairly fine-grained set of flags, so that we can confine the "what does this core have? what things imply what other things?" code to a single place where it's easy to tweak if we get it wrong. -- PMM