Re: [Qemu-devel] [PATCH v2] spapr: populate ibm,loc-code

[Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>]

Michael Roth <mdroth@linux.vnet.ibm.com> writes:

> Quoting Alexey Kardashevskiy (2015-03-29 22:08:17)
>> On 03/30/2015 01:25 PM, David Gibson wrote:
>> > On Mon, Mar 30, 2015 at 01:18:01PM +1100, Alexey Kardashevskiy wrote:
>> >> On 03/27/2015 08:49 PM, Nikunj A Dadhania wrote:
>> >>> Each hardware instance has a platform unique location code.  The OF
>> >>> device tree that describes a part of a hardware entity must include
>> >>> the “ibm,loc-code” property with a value that represents the location
>> >>> code for that hardware entity.
>> >>>
>> >>> Introduce an hcall to populate ibm,loc-code.
>> >>> 1) PCI passthru devices need to identify with its own ibm,loc-code
>> >>>     available on the host.
>> >>> 2) Emulated devices encode as following: qemu_<name>:<slot>.<fn>
>> >>>
>> >>> Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
>> > [snip]
>> >>> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
>> >>> index af71e8b..95157ac 100644
>> >>> --- a/include/hw/ppc/spapr.h
>> >>> +++ b/include/hw/ppc/spapr.h
>> >>> @@ -310,7 +310,10 @@ typedef struct sPAPREnvironment {
>> >>>   #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
>> >>>   /* Client Architecture support */
>> >>>   #define KVMPPC_H_CAS            (KVMPPC_HCALL_BASE + 0x2)
>> >>> -#define KVMPPC_HCALL_MAX        KVMPPC_H_CAS
>> >>> +#define KVMPPC_H_RTAS_UPDATE    (KVMPPC_HCALL_BASE + 0x3)
>> >>> +#define KVMPPC_H_REPORT_MC_ERR  (KVMPPC_HCALL_BASE + 0x4)
>> >>> +#define KVMPPC_H_GET_LOC_CODE   (KVMPPC_HCALL_BASE + 0x5)
>> >>> +#define KVMPPC_HCALL_MAX        KVMPPC_H_GET_LOC_CODE
>> >>
>> >>
>> >> Please add only relevant codes. And what happened to patches adding
>> >> H_RTAS_UPDATE and H_REPORT_MC_ERR?
>> >>
>> >> Also (it is probably a very stupid question but still :) ), why are all
>> >> these callbacks - hypercalls, not RTAS calls? The hypercalls are numbered in
>> >> sPAPR and we kind of stealing numbers from that space while we are
>> >> allocating RTAS tokens ourselves and have more freedom.
>> >
>> > Also, I thought the plan was to remove PCI device enumeration from
>> > SLOF and move it to qemu (since we need to partially do that for
>> > hotplug).  That removes the need for the hcall entirely.
>> 
>> 
>> There was a strong opposition to PCI scan done by QEMU (although it was ok 
>> if PCI hotplug does some resource assignment in QEMU). Has this changed?
>
> Was this WRT to hotplug, or was there previous discussion?
>
> As far as hotplug, the main question was handling actual BAR assignments in
> QEMU, rather than SLOF, for hotplugged devices. (since RPAPHP hotplug code
> expects those assignments to be handled by firmware and encoded in device-tree).
>
> We've worked around that so far by avoiding BAR assignments completely...
>
> To get rpaphp working again, since it was already broken for other reasons,
> we'll be adding code that allows it to handle BAR assignments in the kernel
> in cases where 'reg'/'assigned-resources' properties don't indicate that
> they've already been assigned by QEMU/firmware. Alex seemed okay with this
> approach when we discussed it during his IBM visit a few weeks ago.
>
> So, I'd imagine we can take the same approach for offloading PCI DT node
> creation to QEMU: handle node creation, but don't do actual BAR
> assignments.

Yes, thats what I have been playing with since yesterday. I am using
following of your patches:

  pci: make pci_bar useable outside pci.c
  spapr_pci: enable basic hotplug operations

> Just let SLOF inherit whatever DT node we give it, and let it update
> 'reg'/'assigned-properties' and other properties as needed, but otherwise
> pass on what QEMU provides.

I still need to pass the updated DT blob to SLOF.

Regards
Nikunj