From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a16fI-0004D0-6Y for qemu-devel@nongnu.org; Tue, 24 Nov 2015 01:01:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a16fE-0001Jx-NT for qemu-devel@nongnu.org; Tue, 24 Nov 2015 01:01:19 -0500 Date: Tue, 24 Nov 2015 13:43:51 +1100 From: David Gibson Message-ID: <20151124024351.GF26118@voom.fritz.box> References: <1447201710-10229-1-git-send-email-benh@kernel.crashing.org> <1447201710-10229-27-git-send-email-benh@kernel.crashing.org> <20151120082158.GG7118@voom.redhat.com> <1448329548.4574.47.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline In-Reply-To: <1448329548.4574.47.camel@kernel.crashing.org> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 26/77] ppc/pnv: Add skeletton PowerNV platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 12:45:48PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2015-11-20 at 19:21 +1100, David Gibson wrote: > > On Wed, Nov 11, 2015 at 11:27:39AM +1100, Benjamin Herrenschmidt > > wrote: > > > No devices yet, not even an interrupt controller, just to get > > > started. > > >=20 > > > Signed-off-by: Benjamin Herrenschmidt > > > --- > > > =A0default-configs/ppc64-softmmu.mak |=A0=A0=A01 + > > > =A0hw/ppc/Makefile.objs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0= =A0=A02 + > > > =A0hw/ppc/pnv.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0| 600 > > > ++++++++++++++++++++++++++++++++++++++ > > > =A0include/hw/ppc/pnv.h=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0= =A036 +++ > > > =A04 files changed, 639 insertions(+) > > > =A0create mode 100644 hw/ppc/pnv.c > > > =A0create mode 100644 include/hw/ppc/pnv.h > >=20 > > Many of my comments below may be made irrelevant by later patches in > > the series. >=20 > Heh, well there is where the "meat" of the new platform starts showing > up :-) >=20 > =A0.../... >=20 > > > +#define _FDT(exp) \ > > > +=A0=A0=A0=A0do { \ > > > +=A0=A0=A0=A0=A0=A0=A0=A0int ret =3D (exp);=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\ > > > +=A0=A0=A0=A0=A0=A0=A0=A0if (ret < 0) {=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\ > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0fprintf(stderr, "qemu: error cre= ating device tree: %s: %s\n", \ > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0#exp, fd= t_strerror(ret));=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0\ > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0exit(1);=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\ > > > +=A0=A0=A0=A0=A0=A0=A0=A0}=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\ > > > +=A0=A0=A0=A0} while (0) > >=20 > > We should probably make a file where helper routines used by both > > spapr.c and pnv.c can live. >=20 > Probably but I'd see that as a later cleanup rather than doing it > in this series... Ok. >=20 > .../... >=20 > > > +=A0=A0=A0=A0if (pcc->l1_dcache_size) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_property_cell(fdt, "d-cache-size",= pcc->l1_dcache_size))); > > > +=A0=A0=A0=A0} else { > > > +=A0=A0=A0=A0=A0=A0=A0=A0fprintf(stderr, "Warning: Unknown L1 dcache = size for cpu\n"); > >=20 > > Hmm (note to self) should probably change a bunch of these both in > > spapr.c and pnv.c from explicit fprintfs() to modern error_report() > > and similar. >=20 > That's a train I completely missed, but yes. >=20 > =A0 .../... >=20 > > > +=A0=A0=A0=A0} > > > +=A0=A0=A0=A0_FDT((fdt_property(fdt, "ibm,ppc-interrupt-server#s", > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0servers_prop, sizeof(servers_prop)))); > > > +=A0=A0=A0=A0_FDT((fdt_property(fdt, "ibm,ppc-interrupt-gserver#s", > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0gservers_prop, sizeof(gservers_prop)))); > > > + > > > +=A0=A0=A0=A0_FDT((fdt_end_node(fdt))); > > > +} > > > + > > > +static void *powernv_create_fdt(PnvSystem *sys, uint32_t initrd_base= , uint32_t initrd_size) > > > +{ > >=20 > > So.. does it make sense for qemu to create a device tree for powernv, > > rather than leaving it to Opal? >=20 > Well, OPAL only creates a device-tree if you are on an FSP machine in > which case it expects a complex data structure (HDAT) coming from the > FSP to use as a source of info. >=20 > On OpenPower machines, which is closer to what we simulate here, we > do get a device-tree as an input in OPAL, it's generated by HostBoot. >=20 > Now, I am not running HostBoot in qemu because most of what it does > is completely irrelevant to an emulated system (training the various > links, initializing the memory buffer chips, etc...). >=20 > However we do need to pass a number of platform information to OPAL > which HB does via the device-tree, such as which cores are enabled, > the memory map configured for PCI, which PHBs are enabled, etc... =A0so > creating a DT in qemu makes sense, it mimmics HB in essence. >=20 > OPAL will enrich that device-tree before starting Linux. Ok. Some comments mentioning that you're simulating the exit state =66rom HostBoot would be good then. > > > +=A0=A0=A0=A0/* > > > +=A0=A0=A0=A0=A0* Add info to guest to indentify which host is it bei= ng run on > > > +=A0=A0=A0=A0=A0* and what is the uuid of the guest > > > +=A0=A0=A0=A0=A0*/ > > > +=A0=A0=A0=A0if (kvmppc_get_host_model(&buf)) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_property_string(fdt, "host-model",= buf))); > > > +=A0=A0=A0=A0=A0=A0=A0=A0g_free(buf); > > > +=A0=A0=A0=A0} > > > +=A0=A0=A0=A0if (kvmppc_get_host_serial(&buf)) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_property_string(fdt, "host-serial"= , buf))); > > > +=A0=A0=A0=A0=A0=A0=A0=A0g_free(buf); > > > +=A0=A0=A0=A0} > >=20 > > Since you're emulating a "bare metal" machine, surely the host > > properties aren't relevant here. >=20 > They may or may not. But yes, I can take that out. >=20 > > > +=A0=A0=A0=A0buf =3D g_strdup_printf(UUID_FMT, qemu_uuid[0], qemu_uui= d[1], > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0qemu_uuid[2], qemu_uuid[3], qemu_uuid[4], > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0qemu_uuid[5], qemu_uuid[6], qemu_uuid[7], > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0qemu_uuid[8], qemu_uuid[9], qemu_uuid[10], > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0qemu_uuid[11], qemu_uuid[12], qemu_uuid[13], > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0qemu_uuid[14], qemu_uuid[15]); > > > + > > > +=A0=A0=A0=A0_FDT((fdt_property_string(fdt, "vm,uuid", buf))); > > > +=A0=A0=A0=A0g_free(buf); > > > + > > > +=A0=A0=A0=A0_FDT((fdt_begin_node(fdt, "chosen"))); > > > +=A0=A0=A0=A0_FDT((fdt_property(fdt, "linux,initrd-start", > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0&start_prop, sizeof(start_prop)))); > > > +=A0=A0=A0=A0_FDT((fdt_property(fdt, "linux,initrd-end", > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0&end_prop, sizeof(end_prop)))); > > > +=A0=A0=A0=A0_FDT((fdt_end_node(fdt))); > > > + > > > +=A0=A0=A0=A0_FDT((fdt_property_cell(fdt, "#address-cells", 0x2))); > > > +=A0=A0=A0=A0_FDT((fdt_property_cell(fdt, "#size-cells", 0x2))); > > > + > > > +=A0=A0=A0=A0/* cpus */ > > > +=A0=A0=A0=A0_FDT((fdt_begin_node(fdt, "cpus"))); > > > +=A0=A0=A0=A0_FDT((fdt_property_cell(fdt, "#address-cells", 0x1))); > > > +=A0=A0=A0=A0_FDT((fdt_property_cell(fdt, "#size-cells", 0x0))); > > > + > > > +=A0=A0=A0=A0CPU_FOREACH(cs) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0powernv_create_cpu_node(fdt, cs, smt); > > > +=A0=A0=A0=A0} > > > + > > > +=A0=A0=A0=A0_FDT((fdt_end_node(fdt))); > > > + > > > +=A0=A0=A0=A0/* Memory */ > > > +=A0=A0=A0=A0_FDT((powernv_populate_memory(fdt))); > > > + > > > +=A0=A0=A0=A0/* /hypervisor node */ > > > +=A0=A0=A0=A0if (kvm_enabled()) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0uint8_t hypercall[16]; > > > + > > > +=A0=A0=A0=A0=A0=A0=A0=A0/* indicate KVM hypercall interface */ > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_begin_node(fdt, "hypervisor"))); > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_property_string(fdt, "compatible",= "linux,kvm"))); > > > +=A0=A0=A0=A0=A0=A0=A0=A0if (kvmppc_has_cap_fixup_hcalls()) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/* > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* Older KVM versions with old= er guest kernels were broken with the > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* magic page, don't allow the= guest to map it. > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0*/ > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0kvmppc_get_hypercall(first_cpu->= env_ptr, hypercall, > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0sizeof(hypercall)); > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_property(fdt, "hcall-i= nstructions", hypercall, > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0sizeof(hypercall)))); > > > +=A0=A0=A0=A0=A0=A0=A0=A0} > > > +=A0=A0=A0=A0=A0=A0=A0=A0_FDT((fdt_end_node(fdt))); > > > +=A0=A0=A0=A0} > >=20 > > And a hypercall interface surely doesn't make sense for powernv. >=20 > It's qemu paravirt, it exist on G5 too :-) It's for PR KVM, it allows > to speed up some bits and pieces. But yeah we don't yet really > "support" it at this point. However we might. Ah, yes, I forgot about that. > > > + > > > +=A0=A0=A0=A0_FDT((fdt_end_node(fdt))); /* close root node */ > > > +=A0=A0=A0=A0_FDT((fdt_finish(fdt))); > > > + > > > +=A0=A0=A0=A0return fdt; > > > +} > > > + > > > +static void powernv_cpu_reset(void *opaque) > > > +{ > > > +=A0=A0=A0=A0PowerPCCPU *cpu =3D opaque; > > > +=A0=A0=A0=A0CPUState *cs =3D CPU(cpu); > > > +=A0=A0=A0=A0CPUPPCState *env =3D &cpu->env; > > > + > > > +=A0=A0=A0=A0cpu_reset(cs); > > > + > > > +=A0=A0=A0=A0env->spr[SPR_PIR] =3D ppc_get_vcpu_dt_id(cpu); > > > +=A0=A0=A0=A0env->spr[SPR_HIOR] =3D 0; > > > +=A0=A0=A0=A0env->gpr[3] =3D FDT_ADDR; > > > +=A0=A0=A0=A0env->nip =3D 0x10; > > > +=A0=A0=A0=A0env->msr |=3D MSR_HVB; > > > +} > >=20 > > So, I believe the qemu-ishly correct way of doing this is to have the > > cpu initialization in the cpu code, rather than the platform code, as > > much as possible.=A0=A0On PAPR we kind of get away with initialization = in > > the platform code on the grounds that it's a paravirt platform, but > > powernv doesn't have that excuse. > >=20 > > But this may well be stuff that changes in later patches, so.. >=20 > Well no, not really. But here too, we mimmic the state as coming out of > HostBoot, which isn't quite the same thing. We need to provide the FDT > entry, etc... >=20 > The "real" reset state of a P8 isn't something we can easily > simulate...=A0 >=20 > It runs some microcode from a SEEPROM with a small microcontroller > which initializes a core, which then runs some HB code off it's L3 > cache etc... really not something we want to do in qemu at least > for now. >=20 > So the initial state here is somewhat in between full virt and > paravirt, we simulate a platform that has been partially initialized by > HostBoot, to the state it has when it enters OPAL. Ok, that makes sense, but I think it needs a bit more explanation in the code to that effect. > > > +static const VMStateDescription vmstate_powernv =3D { > > > +=A0=A0=A0=A0.name =3D "powernv", > > > +=A0=A0=A0=A0.version_id =3D 1, > > > +=A0=A0=A0=A0.minimum_version_id =3D 1, > > > +}; > >=20 > > It might be best to leave out the vmstate entirely until you're ready > > to implement migration, rather than having a partial, probably not > > working migration implementation. >=20 > Ok. >=20 > > > + > > > +static void pnv_create_chip(PnvSystem *sys, unsigned int chip_no) > > > +{ > > > +=A0=A0=A0=A0PnvChip *chip =3D &sys->chips[chip_no]; > > > + > > > +=A0=A0=A0=A0if (chip_no >=3D PNV_MAX_CHIPS) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return; > > > +=A0=A0=A0=A0} > > > + > > > +=A0=A0=A0=A0/* XXX Improve chip numbering to better match HW */ > > > +=A0=A0=A0=A0chip->chip_id =3D chip_no; > >=20 > > I think modern qemu conventions would suggest creating the chips as > > QOM objects rather than having a fixed array. >=20 > Yeah, more code & much larger memory footprint for the same result :-) >=20 > I can look into it but it's low priority. I still want to rework some > of that chip stuff in future patches anyway. >=20 > > > +} > > > + > > > +static void ppc_powernv_init(MachineState *machine) > > > +{ > > > +=A0=A0=A0=A0ram_addr_t ram_size =3D machine->ram_size; > > > +=A0=A0=A0=A0const char *cpu_model =3D machine->cpu_model; > > > +=A0=A0=A0=A0const char *kernel_filename =3D machine->kernel_filename; > > > +=A0=A0=A0=A0const char *initrd_filename =3D machine->initrd_filename; > > > +=A0=A0=A0=A0uint32_t initrd_base =3D 0; > > > +=A0=A0=A0=A0long initrd_size =3D 0; > > > +=A0=A0=A0=A0PowerPCCPU *cpu; > > > +=A0=A0=A0=A0CPUPPCState *env; > > > +=A0=A0=A0=A0MemoryRegion *sysmem =3D get_system_memory(); > > > +=A0=A0=A0=A0MemoryRegion *ram =3D g_new(MemoryRegion, 1); > > > +=A0=A0=A0=A0sPowerNVMachineState *pnv_machine =3D POWERNV_MACHINE(ma= chine); > > > +=A0=A0=A0=A0PnvSystem *sys =3D &pnv_machine->sys; > > > +=A0=A0=A0=A0long fw_size; > > > +=A0=A0=A0=A0char *filename; > > > +=A0=A0=A0=A0void *fdt; > > > +=A0=A0=A0=A0int i; > > > + > > > +=A0=A0=A0=A0/* init CPUs */ > > > +=A0=A0=A0=A0if (cpu_model =3D=3D NULL) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0cpu_model =3D kvm_enabled() ? "host" : "POWE= R8"; > > > +=A0=A0=A0=A0} > > > + > > > +=A0=A0=A0=A0for (i =3D 0; i < smp_cpus; i++) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0cpu =3D cpu_ppc_init(cpu_model); > > > +=A0=A0=A0=A0=A0=A0=A0=A0if (cpu =3D=3D NULL) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0fprintf(stderr, "Unable to find = PowerPC CPU definition\n"); > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0exit(1); > > > +=A0=A0=A0=A0=A0=A0=A0=A0} > > > +=A0=A0=A0=A0=A0=A0=A0=A0env =3D &cpu->env; > > > + > > > +=A0=A0=A0=A0=A0=A0=A0=A0/* Set time-base frequency to 512 MHz */ > > > +=A0=A0=A0=A0=A0=A0=A0=A0cpu_ppc_tb_init(env, TIMEBASE_FREQ); > > > + > > > +=A0=A0=A0=A0=A0=A0=A0=A0/* MSR[IP] doesn't exist nowadays */ > > > +=A0=A0=A0=A0=A0=A0=A0=A0env->msr_mask &=3D ~(1 << 6); > > > + > > > +=A0=A0=A0=A0=A0=A0=A0=A0qemu_register_reset(powernv_cpu_reset, cpu); > > > +=A0=A0=A0=A0} > > > + > > > +=A0=A0=A0=A0/* allocate RAM */ > > > +=A0=A0=A0=A0memory_region_allocate_system_memory(ram, NULL, "ppc_pow= ernv.ram", ram_size); > > > +=A0=A0=A0=A0memory_region_add_subregion(sysmem, 0, ram); > > > + > > > +=A0=A0=A0=A0/* XXX We should decide how many chips to create based o= n #cores and > > > +=A0=A0=A0=A0=A0* Venice vs. Murano vs. Naples chip type etc..., for = now, just create > > > +=A0=A0=A0=A0=A0* one chip. Also creation of the CPUs should be done = per-chip > > > +=A0=A0=A0=A0=A0*/ > > > +=A0=A0=A0=A0sys->num_chips =3D 1; > > > + > > > +=A0=A0=A0=A0/* Create only one PHB for now until I figure out what's= wrong > > > +=A0=A0=A0=A0=A0* when I create more (resource assignment failures in= Linux) > > > +=A0=A0=A0=A0=A0*/ > > > +=A0=A0=A0=A0pnv_create_chip(sys, 0); > > > + > > > +=A0=A0=A0=A0if (bios_name =3D=3D NULL) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0bios_name =3D FW_FILE_NAME; > > > +=A0=A0=A0=A0} > > > +=A0=A0=A0=A0filename =3D qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_na= me); > > > +=A0=A0=A0=A0fw_size =3D load_image_targphys(filename, 0, FW_MAX_SIZE= ); > > > +=A0=A0=A0=A0if (fw_size < 0) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0hw_error("qemu: could not load OPAL '%s'\n",= filename); > > > +=A0=A0=A0=A0=A0=A0=A0=A0exit(1); > > > +=A0=A0=A0=A0} > > > +=A0=A0=A0=A0g_free(filename); > > > + > > > + > > > +=A0=A0=A0=A0if (kernel_filename =3D=3D NULL) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0kernel_filename =3D KERNEL_FILE_NAME; > > > +=A0=A0=A0=A0} > > > +=A0=A0=A0=A0filename =3D qemu_find_file(QEMU_FILE_TYPE_BIOS, > > > kernel_filename); > >=20 > > The commit withe Opal image should go in before this, no? >=20 > Now this is a bit of an open discussion at the moment :-) >=20 > The way OPAL is built on OPP machines today is by essentially building > a complete flash image which contains HostBoot, OPAL and the petitboot- > based bootloader which contains a Linux kernel etc... >=20 > We could create a target without HB and with a slimmed down Linux but > it would still probably be about 12MB I reckon, if not more. It feels a > bit "big" to ship as a binary as part of qemu... >=20 > We would also have to add code to qemu to "find" OPAL in that image, > and then add a model for the flash controller. >=20 > The other option is to bundle just OPAL itself. However that means > you can't go anywhere without a -kernel argument, which would then > be either a petitboot-based bootloader or your actual target kernel. Hm, ok. But in order for this to be usable, we need some way to get a suitable image. So medium term, I think it makes sense to include both opal and PetitBoot, so you can boot the guest like a real machine. However, including only Opal and requiring -kernel would be a reasonable interim step. --=20 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 --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWU87nAAoJEGw4ysog2bOSkGwQAKvUUGSLwCz4Wq4RD+tSXSQK SrVK9RyYI/iVW5iPTbCvfGcDVfz+HrcxEUGMhbv3s2uxIc23cclIMnc/bf5k7VjD JbT4oaZgKSe+yURn+80ZL3aT4otxU4tpur0ZcU5qtja7eLsNFR9R4zgLO7PgpC5J KzRRltKul+t6MmoAyEoOKS0B0YX9ADz6O7zDED5HkznVfJGSnn7sDbW69UJW8ba5 FKNVo7MyV0UoKKuYsPD9bwa2tpSWKY1m36g7gxRLD/uDUn7K3K/qzl4NObZDt9uL C5pUYI6ErwKYrxl/PihnuGEZ3X7omIRdsDGaCvrGMmJAdKDI1gvxfnhCmr01Zh4T cxtg4vTH2dIjn8BOCKRNYh4iLTedIG5VaE8cdFaGtSg+qLNqSFRmDzbcYq9Qi9AE 1NByhgIteXVvJ7FAdiHj/40wkcNxg5g0f0EwVT9XR+Y4Mt+sCQZeeVZNWjat+VMx 1x3vvLBjCl9X8fLcxnaZxqmtgJtLZPPk0Kg16CrDdODzfz6FLwsKitxuz+5II6DF 4xkQp2IWiQy92958R5Gb0STKN6SMNNyzAbxrZvavfNThC/AgrGiRi9tKew6E64gg Z7jVJaaZzDi03DKZQoKL+c8tnR6Om/zuU3OLsxP9ksYZbdjAajbgQw+BM7TCUijs N/SqhAeE20H5+IFpbt1+ =NfV6 -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE--