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

[Nikunj A Dadhania]

Alexey Kardashevskiy <address@hidden> writes:

> On 03/30/2015 04:34 PM, Nikunj A Dadhania wrote:
>> Nikunj A Dadhania <address@hidden> writes:
>>
>>> David Gibson <address@hidden> writes:
>>>
>>>> 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 <address@hidden>
>>>> [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).
>>>
>>> For me it was a short term plan.
>>
>> Sorry, I meant PCI device enumeration removal from SLOF was a long term
>> plan.
>
>
> It does not have to be removal, rather adding a case if there are already 
> devices present (or resources assigned) on a PHB in the device tree, then 
> do not do scan, something like that.

Right, it would require time to analyze impact both on Qemu and SLOF
side. I havent looked at the qemu side of the things how
easy/complicated it would be to do PCI scanning

Regards
Nikunj