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

[Erlon Cruz]

On 10/05/2012 11:42 AM, Anthony Liguori wrote:
> Benjamin Herrenschmidt <address@hidden> 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?

The RTAS call is how the guest will communicate with the host. It 
doesn't have a way to get interrupted and notified about any changes. So 
to start the changing of something, the guest need some kind of trigger

> Regards,
>
> Anthony Liguori
> .
>

Legal Disclaimer:
The information contained in this message may be privileged and confidential. 
It is intended to be read only by the individual or entity to whom it is 
addressed or by their designee. If the reader of this message is not the 
intended recipient, you are on notice that any distribution of this message, in 
any form, is strictly prohibited. If you have received this message in error, 
please immediately notify the sender and delete or destroy any copy of this 
message!