From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcTyc-00075B-AL for qemu-devel@nongnu.org; Mon, 30 Mar 2015 03:19:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcTyX-0001Xn-AI for qemu-devel@nongnu.org; Mon, 30 Mar 2015 03:19:14 -0400 Received: from mail-pd0-f172.google.com ([209.85.192.172]:35931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcTyX-0001Xj-5Q for qemu-devel@nongnu.org; Mon, 30 Mar 2015 03:19:09 -0400 Received: by pdcp1 with SMTP id p1so75382648pdc.3 for ; Mon, 30 Mar 2015 00:19:08 -0700 (PDT) Message-ID: <5518F752.4010201@ozlabs.ru> Date: Mon, 30 Mar 2015 18:12:18 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1427449798-10345-1-git-send-email-nikunj@linux.vnet.ibm.com> <5518B259.1070609@ozlabs.ru> <20150330022516.GC9908@voom.fritz.box> <87a8yvjcwa.fsf@abhimanyu.in.ibm.com> <877ftzjbfo.fsf@abhimanyu.in.ibm.com> In-Reply-To: <877ftzjbfo.fsf@abhimanyu.in.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] spapr: populate ibm, loc-code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania , David Gibson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 03/30/2015 04:34 PM, Nikunj A Dadhania wrote: > Nikunj A Dadhania writes: > >> David Gibson 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_:. >>>>> >>>>> Signed-off-by: Nikunj A Dadhania >>> [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. > > >> IMHO, this cant be done in short time. >> >>> That removes the need for the hcall entirely. >>> >>> -- >>> David Gibson | I'll have my music baroque, and my code >>> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ >>> | _way_ _around_! >>> http://www.ozlabs.org/~dgibson > -- Alexey