From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 04/14] KVM: PPC: e500: MMU API Date: Wed, 02 Nov 2011 12:33:34 +0200 Message-ID: <4EB11C7E.6050703@redhat.com> References: <1320047596-20577-1-git-send-email-agraf@suse.de> <1320047596-20577-5-git-send-email-agraf@suse.de> <4EAEA184.4050807@redhat.com> <4EAF013C.7050206@freescale.com> <4EAFB4B9.2040806@redhat.com> <4EB01B4B.8090209@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm list , Marcelo Tosatti To: Scott Wood Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755241Ab1KBKdk (ORCPT ); Wed, 2 Nov 2011 06:33:40 -0400 In-Reply-To: <4EB01B4B.8090209@freescale.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/01/2011 06:16 PM, Scott Wood wrote: > > > > sizeof(struct kvm_tlb_dirty) == 12 for 32-bit userspace, but == 16 for > > 64-bit userspace and the kernel. ABI structures must have the same > > alignment and size for 32/64 bit userspace, or they need compat handling. > > The size is 16 on 32-bit ppc -- the alignment of __u64 forces this. It > looks like this is different in the 32x86 ABI. Right, __u64 alignment on i386 is 4. > We can pad explicitly if you prefer. No real need - unless it may be reused by another arch? I think that's unlikely. > >> This API has been discussed extensively, and the code using it is > >> already in mainline QEMU. This aspect of it hasn't changed since the > >> discussion back in February: > >> > >> http://www.spinics.net/lists/kvm/msg50102.html > >> > >> I'd prefer to avoid another round of major overhaul without a really > >> good reason. > > > > Me too, but I also prefer not to make ABI choices by inertia. ABI is > > practically the only thing I care about wrt non-x86 (other than > > whitespace, of course). Please involve me in the discussions earlier in > > the future. > > You participated in that thread. :-) Well, my memory isn't what it used to be, or at least what I seem to remember it used to be. > >> > >> These are the assumptions needed to make such an interface well-defined. > > > > Just remarking on the complexity, don't take it personally. > > :-) > > Just wasn't sure whether the implication was that it was too complex. > It is too complex, but that's entirely the fault of the hardware. All we can do is complain and enjoy the guaranteed job security. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Wed, 02 Nov 2011 10:33:34 +0000 Subject: Re: [PATCH 04/14] KVM: PPC: e500: MMU API Message-Id: <4EB11C7E.6050703@redhat.com> List-Id: References: <1320047596-20577-1-git-send-email-agraf@suse.de> <1320047596-20577-5-git-send-email-agraf@suse.de> <4EAEA184.4050807@redhat.com> <4EAF013C.7050206@freescale.com> <4EAFB4B9.2040806@redhat.com> <4EB01B4B.8090209@freescale.com> In-Reply-To: <4EB01B4B.8090209@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Scott Wood Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm list , Marcelo Tosatti On 11/01/2011 06:16 PM, Scott Wood wrote: > > > > sizeof(struct kvm_tlb_dirty) = 12 for 32-bit userspace, but = 16 for > > 64-bit userspace and the kernel. ABI structures must have the same > > alignment and size for 32/64 bit userspace, or they need compat handling. > > The size is 16 on 32-bit ppc -- the alignment of __u64 forces this. It > looks like this is different in the 32x86 ABI. Right, __u64 alignment on i386 is 4. > We can pad explicitly if you prefer. No real need - unless it may be reused by another arch? I think that's unlikely. > >> This API has been discussed extensively, and the code using it is > >> already in mainline QEMU. This aspect of it hasn't changed since the > >> discussion back in February: > >> > >> http://www.spinics.net/lists/kvm/msg50102.html > >> > >> I'd prefer to avoid another round of major overhaul without a really > >> good reason. > > > > Me too, but I also prefer not to make ABI choices by inertia. ABI is > > practically the only thing I care about wrt non-x86 (other than > > whitespace, of course). Please involve me in the discussions earlier in > > the future. > > You participated in that thread. :-) Well, my memory isn't what it used to be, or at least what I seem to remember it used to be. > >> > >> These are the assumptions needed to make such an interface well-defined. > > > > Just remarking on the complexity, don't take it personally. > > :-) > > Just wasn't sure whether the implication was that it was too complex. > It is too complex, but that's entirely the fault of the hardware. All we can do is complain and enjoy the guaranteed job security. -- error compiling committee.c: too many arguments to function