From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Evans Subject: Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support Date: Thu, 08 Dec 2011 13:57:17 +1100 Message-ID: <4EE0278D.8000805@ozlabs.org> References: <4EDD94A4.2080003@ozlabs.org> <4EDE58FE.4040904@freescale.com> <4EDF1746.7090106@ozlabs.org> <4EDFB0F2.3030806@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org To: Scott Wood Return-path: In-Reply-To: <4EDFB0F2.3030806@freescale.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 08/12/11 05:31, Scott Wood wrote: > On 12/07/2011 01:35 AM, Matt Evans wrote: >> Hi Scott, >> >> On 07/12/11 05:03, Scott Wood wrote: >>> On 12/05/2011 10:05 PM, Matt Evans wrote: >>>> This patch adds a new arch directory, powerpc, basic file structure, register >>>> setup and where necessary stubs out arch-specific functions (e.g. interrupts, >>>> runloop exits) that later patches will provide. The target is an >>>> SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or >>>> 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and >>>> RTAS required to boot SPAPR pSeries kernels. >>> >>> You just sent out 28 patches removing "everything is x86" >>> dependencies -- may I suggest that the PPC code be structured so that >>> there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, >>> even if SPAPR is initially the only sub-arch present? >> >> I had anticipated this comment (though not the "28 patches" remark, easy now). > > I was just using that to illustrate how it's easier to handle earlier > than later -- no offense intended. :-) > >> It is a fair comment, but you hit the nail on the head with your other mail >> (regarding configuring in i8042, presumably to emulate crappy dev boards) >> asking whether kvmtool has a config system. It does not. >> >> Since we currently lack any kind of build-time configuration (or any fancy >> run-time -M a la QEMU) it's a bit hard to cater for multiple >> platforms. I'm aware that the PPC patches are painfully PPC64-with-SPAPR and I >> don't present them as perfect, but I really think we need to attack the >> configuration stuff before bifurcating. Is this something you'd like to see to? > > Just putting all SPAPR stuff in SPAPR-named files (or at least > SPAPR-named functions), and likewise for book3s stuff, etc. would be an > improvement. I see that you did this for some things, but not all. Try > to make it obvious where the target-specific branching would take place, > even if the actual branching mechanism is currently just a FIXME comment. No worries, that's a good suggestion-- I'll have a spin through the PPC stuff and see if there's anything worth splitting, or at least point out everywhere I can find with an appropriate comment. Thanks, Matt