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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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.
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 added Michael in cc: and hope Alexander may enlighten us on this topic...
> 
> 
> 
> -- 
> Alexey