Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <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.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux