Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries

[Anthony Liguori <anthony@codemonkey.ws>]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> On Wed, 2012-09-12 at 17:53 +0200, Alexander Graf wrote:
>> On 09/12/2012 04:54 PM, Erlon Cruz wrote:
>> > Hi all,
>> >
>> > We are planning to implement DLPAR capacity on QEMU pSeries. As we
>> 
>> What is DLPAR? Hotplug support?
>
> Yes.
>
>> > lack of experience in the internals of the arch we would like you guys
>> > to give us some design directions
>> > and confirm if we going in the right direction. Our first idea is:
>> >
>> >      1 - to patch 'spapr.c' so it can dynamically insert/remove basic
>> > items into the device tree.
>> 
>> What exactly would you like to patch into it? We already do have support 
>> for dynamic dt creation with the spapr target.
>
> No we don't. We don't have the necessary bits and pieces to pass the DT
> updates down to the guest. PAPR defines a mechanism using RTAS calls
> which we need to implement, but there are some issues remaining:
>
>  - We don't have a way to "initiate" a DLPAR operation. This is
> currently done by proprietary tools that communicate with the HMC. We
> want to invent some kind of hotplug "interrupt" (using existing RTAS
> event facilities). All it needs to do is indicate the DT path (ie.
> connector) where something is to be plugged to or unplugged, which can
> then trigger the relevant configure-connector calls to retrieve the DT
> bits.
>
>  - We have a problem with PCI. Currently, the content of the PCI
> bus(ses) is discovered by SLOF running inside the guest. Not by qemu.
> It's SLOF that assigns the BARs and create the device-tree nodes for the
> various PCI devices. However, with hotplug, the guest expects to get
> fully populated DT nodes for hotplugged PCI devices and fully assigned
> BARS. Under pHyp that works because under the hood, RTAS contains an OFW
> implementation which does all the assignment before passing the stuff to
> the OS, but under qemu, RTAS is actually in qemu. This means we'll
> probably have to move back the PCI device node creation and resource
> assignment to qemu (like it was in the very early versions of the spapr
> support).

I know you and I have discussed this in the past, but not on the list
and now I don't recall the reasoning.

Why not add a proper RTAS and do this work there?

Regards,

Anthony Liguori