From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcQ3x-0003GT-At for qemu-devel@nongnu.org; Sun, 29 Mar 2015 23:08:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcQ3t-0001iF-T1 for qemu-devel@nongnu.org; Sun, 29 Mar 2015 23:08:29 -0400 Received: from mail-pd0-f176.google.com ([209.85.192.176]:36361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcQ3t-0001i2-NE for qemu-devel@nongnu.org; Sun, 29 Mar 2015 23:08:25 -0400 Received: by pdcp1 with SMTP id p1so69596775pdc.3 for ; Sun, 29 Mar 2015 20:08:25 -0700 (PDT) Message-ID: <5518BE21.6030702@ozlabs.ru> Date: Mon, 30 Mar 2015 14:08:17 +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> In-Reply-To: <20150330022516.GC9908@voom.fritz.box> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2] spapr: populate ibm,loc-code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Michael Roth , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Nikunj A Dadhania , agraf@suse.de 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_:. >>> >>> 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). 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? I added Michael in cc: and hope Alexander may enlighten us on this topic... -- Alexey