From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TazOT-00053F-4V for qemu-devel@nongnu.org; Tue, 20 Nov 2012 20:46:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TazOR-0001pp-LH for qemu-devel@nongnu.org; Tue, 20 Nov 2012 20:46:24 -0500 Date: Wed, 21 Nov 2012 12:14:32 +1100 From: David Gibson Message-ID: <20121121011432.GP18362@truffula.fritz.box> References: <1352774820-22804-1-git-send-email-david@gibson.dropbear.id.au> <1352774820-22804-9-git-send-email-david@gibson.dropbear.id.au> <69634422-E5DA-48E6-807D-5C0333424EB9@suse.de> <20121119224823.GC18362@truffula.fritz.box> <3F40C7F7-0687-4730-89D8-E2E414820117@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/12] target-ppc: Convert ppcemb_tlb_t to use fixed 64-bit RPN List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Tue, Nov 20, 2012 at 10:55:50AM +0100, Alexander Graf wrote: > > On 20.11.2012, at 10:53, Peter Maydell wrote: > > > On 20 November 2012 09:29, Alexander Graf wrote: > >> On 19.11.2012, at 23:48, David Gibson wrote: > >>> On Mon, Nov 19, 2012 at 05:26:45PM +0100, Alexander Graf wrote: > >>>> On 13.11.2012, at 03:46, David Gibson wrote: > >>>>> This patch therefore changes ppcemb_tlb_t to use a fixed 64-bit integer > >>>>> which we know is sufficient for all the machines which use this structure. > >>>> > >>>> hwaddr is always defined to 64bit by now. > >>> > >>> I know, but there aren't state save helpers for hwaddr, and there are > >>> objections to creating them. > > > > (previous discussion on this point: > > https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01456.html ) > > > >> Sure, but you can just use the 64bit save helpers now that hwaddr == uint64_t, no? > > > > That would be one approach. I'm a bit sceptical about putting hwaddr > > fields in CPU state, though -- it's suggestive that something's > > not modelled right. hwaddr is conceptually "big enough for the > > biggest bus in the system", and no single component should have > > internal state whose size depends on that. Right, that's the reason I was given for not adding VMSTATE helpers for hwaddr too. But more directly, as long as hwaddr is a different type from uint64_t, to me that at least admits the possibility that it could be changed again some day. And if we're using a uint64_t based VMSTATE helper on a type that could change, that could go badly wrong. Basically it's a subtle and ungreppable dependency on the fact that a hwaddr is actually a uint64_t, which seems like a bad idea. > *shrug* I'm more than happy to get a patch that just converts all > *the hwaddr fields in CPUState to uint64_t. So.. does that mean you'll apply this one or not? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson