From: Scott Wood <scottwood@freescale.com>
To: Matt Evans <matt@ozlabs.org>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Date: Wed, 07 Dec 2011 18:31:14 +0000 [thread overview]
Message-ID: <4EDFB0F2.3030806@freescale.com> (raw)
In-Reply-To: <4EDF1746.7090106@ozlabs.org>
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 <machine> 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.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Matt Evans <matt@ozlabs.org>
Cc: <kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>
Subject: Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Date: Wed, 7 Dec 2011 12:31:14 -0600 [thread overview]
Message-ID: <4EDFB0F2.3030806@freescale.com> (raw)
In-Reply-To: <4EDF1746.7090106@ozlabs.org>
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 <machine> 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.
-Scott
next prev parent reply other threads:[~2011-12-07 18:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1323143103.git.matt@ozlabs.org>
2011-12-06 4:05 ` [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support Matt Evans
2011-12-06 4:05 ` Matt Evans
2011-12-06 18:03 ` Scott Wood
2011-12-06 18:03 ` Scott Wood
2011-12-06 18:33 ` Pekka Enberg
2011-12-06 18:33 ` Pekka Enberg
2011-12-06 18:54 ` Scott Wood
2011-12-06 18:54 ` Scott Wood
2011-12-07 7:35 ` Matt Evans
2011-12-07 7:35 ` Matt Evans
2011-12-07 18:31 ` Scott Wood [this message]
2011-12-07 18:31 ` Scott Wood
2011-12-08 2:57 ` Matt Evans
2011-12-08 2:57 ` Matt Evans
2011-12-06 4:06 ` [PATCH 2/8] kvm tools: Generate SPAPR PPC64 guest device tree Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 3/8] kvm tools: Add SPAPR PPC64 hcall & rtascall structure Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 4/8] kvm tools: Add SPAPR PPC64 HV console Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 5/8] kvm tools: Add PPC64 XICS interrupt controller support Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 6/8] kvm tools: Add PPC64 PCI Host Bridge Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 7/8] kvm tools: Add PPC64 kvm_cpu__emulate_io() Matt Evans
2011-12-06 4:06 ` Matt Evans
2011-12-06 4:06 ` [PATCH 8/8] kvm tools: Make virtio-pci's ioeventfd__add_event() fall Matt Evans
2011-12-06 4:06 ` [PATCH 8/8] kvm tools: Make virtio-pci's ioeventfd__add_event() fall back gracefully if ioeventfds unavailable Matt Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDFB0F2.3030806@freescale.com \
--to=scottwood@freescale.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=matt@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.