From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdAwl-0006Ak-DJ for qemu-devel@nongnu.org; Wed, 01 Apr 2015 01:12:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdAwa-0002EO-TG for qemu-devel@nongnu.org; Wed, 01 Apr 2015 01:12:11 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:42057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdAwa-0002E3-9v for qemu-devel@nongnu.org; Wed, 01 Apr 2015 01:12:00 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Apr 2015 15:11:56 +1000 From: Nikunj A Dadhania In-Reply-To: <20150331175234.15386.53344@loki> References: <1427449798-10345-1-git-send-email-nikunj@linux.vnet.ibm.com> <5518B259.1070609@ozlabs.ru> <20150330022516.GC9908@voom.fritz.box> <5518BE21.6030702@ozlabs.ru> <20150331175234.15386.53344@loki> Date: Wed, 01 Apr 2015 10:40:52 +0530 Message-ID: <878uectov7.fsf@abhimanyu.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] spapr: populate ibm,loc-code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , Alexey Kardashevskiy , David Gibson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, agraf@suse.de Michael Roth 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 =E2=80=9Cibm,loc-code=E2=80=9D property with a value that repres= ents 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 a= ll >> >> these callbacks - hypercalls, not RTAS calls? The hypercalls are numb= ered 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. >>=20 >>=20 >> There was a strong opposition to PCI scan done by QEMU (although it was = ok=20 >> 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 reason= s, > we'll be adding code that allows it to handle BAR assignments in the kern= el > 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