From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqg5q-0007tK-Pg for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:51:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sqg5p-0007a6-QY for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:51:46 -0400 Received: from ozlabs.org ([203.10.76.45]:44231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqg5p-0007ZQ-Ez for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:51:45 -0400 From: Rusty Russell In-Reply-To: References: <878veoz5yv.fsf@rustcorp.com.au> Date: Mon, 16 Jul 2012 16:49:43 +0930 Message-ID: <87pq7wxje8.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [kvmarm] [PATCH] target-arm: kvm: use KVM_SET_SREGS to set target to Cortex A15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Rusty Russell Cc: "peter.maydell@linaro.org" , "kvmarm@lists.cs.columbia.edu" , "qemu-devel@nongnu.org" On Fri, 13 Jul 2012 12:06:26 +0200, Alexander Graf wrote: > > struct kvm_sregs { > > + __u32 target; > > + __u32 num_features; > > + __u32 features[14]; > > }; > > Are you sure you want to use sregs? We did the mistake of reusing it > on ppc, but that doesn't mean you need to repeat the same one :) > > Basically sregs are an x86 specific struct for its segment register > information. I'm quite sure that this is not what your use of them is > here. Since each arch is given a hook already, I just abused it. I'll change this to a fresh KVM_ARM_SET_TARGET ioctl. > 3) ENABLE_CAP > > If you only need to enable a feature and care about backwards > compatibility of the API (which you don't yet), this is a good one. it > basically allows you to enable new features in newer kernel versions > which would otherwise break compatibility. You can also pass arbitrary > data to ENABLE_CAP to pass in additional information. Hmm, it's not quite a clean fit: this bitmap is for guest features, not kvm ones. Which ones you can enable depends on the target CPU, at least in theory. eg. FP/NEON support and debug register support are (in theory) optional features for an implementation. There may be more in future, I guess. And you really want to initialize this all at the same time; eg. the cpu identification registers need to be initialized depending on the presence of various features. It's also possible that various features may be related, so you can't turn a single one off at a time. Currently, it's a bit theoretical, since we don't have any guest features, but it was suggested that we'll want them in future. Cheers, Rusty.