From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTeaO-000835-92 for qemu-devel@nongnu.org; Wed, 22 Jul 2009 12:22:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTeaJ-0007yt-Ix for qemu-devel@nongnu.org; Wed, 22 Jul 2009 12:22:31 -0400 Received: from [199.232.76.173] (port=59979 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTeaJ-0007yS-Cr for qemu-devel@nongnu.org; Wed, 22 Jul 2009 12:22:27 -0400 Received: from mail-qy0-f174.google.com ([209.85.221.174]:49060) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTeaI-0007Cr-Ow for qemu-devel@nongnu.org; Wed, 22 Jul 2009 12:22:26 -0400 Received: by qyk4 with SMTP id 4so345316qyk.4 for ; Wed, 22 Jul 2009 09:22:25 -0700 (PDT) Message-ID: <4A673CBE.8040003@codemonkey.ws> Date: Wed, 22 Jul 2009 11:22:22 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/7] Add mp_state to PPC CPU struct References: <1247831508-19023-1-git-send-email-agraf@suse.de> <1247831508-19023-2-git-send-email-agraf@suse.de> <1247831508-19023-3-git-send-email-agraf@suse.de> <1247831508-19023-4-git-send-email-agraf@suse.de> <4A673180.4030108@codemonkey.ws> <1248278346.4521.5.camel@slab.beaverton.ibm.com> In-Reply-To: <1248278346.4521.5.camel@slab.beaverton.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: Alexander Graf , qemu-devel@nongnu.org Hollis Blanchard wrote: > On Wed, 2009-07-22 at 10:34 -0500, Anthony Liguori wrote: > >> Alexander Graf wrote: >> >>> Some generic code tries to access env->mp_state. Let's just make >>> it happy and provide it. >>> >>> Signed-off-by: Alexander Graf >>> >>> >> Or we can move that code from kvm-all.c to target-i386/kvm.c where it >> belongs :-) >> > > Common code uses mp_state, and i386 is the only thing calling that code. > However, the ioctl used by that code is valid for all architectures; it > will just return -EINVAL. Someday we might need it in common code, but > then again it's not even clear to me it will be useful outside of x86. > > I'm fine with moving it too, as long as it's also renamed at the same > time. :) > Why is it a common ioctl instead of an arch specific ioctl? Regards, Anthony Liguori