| Message ID | 1301023292-24977-28-git-send-email-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
On 03/24/2011 10:21 PM, David Gibson wrote: > Currently, the emulated pSeries machine requires the use of the > -kernel parameter in order to explicitly load a guest kernel. This > means booting from the virtual disk, cdrom or network is not possible. > > This patch addresses this limitation by inserting a within-partition > firmware image (derived from the "SLOF" free Open Firmware project). > If -kernel is not specified, qemu will now load the SLOF image, which > has access to the qemu boot device list through the device tree, and > can boot from any of the usual virtual devices. > > In order to support the new firmware, an extension to the emulated > machine/hypervisor is necessary. Unlike Linux, which expects > multi-CPU entry to be handled kexec() style, the SLOF firmware expects > only one CPU to be active at entry, and to use a hypervisor RTAS > method to enable the other CPUs one by one. > > This patch also implements this 'start-cpu' method, so that SLOF can > start the secondary CPUs and marshal them into the kexec() holding > pattern ready for entry into the guest OS. Linux should, and in the > future might directly use the start-cpu method to enable initially > disabled CPUs, but for now it does require kexec() entry. > > Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org> > Signed-off-by: Paul Mackerras<paulus@samba.org> > Signed-off-by: David Gibson<dwg@au1.ibm.com> We should pull in SLOF via a git submodule. That ensures we ship the source code along with the binary. Regards, Anthony Liguori
On Fri, Mar 25, 2011 at 01:29:17PM -0500, Anthony Liguori wrote: > On 03/24/2011 10:21 PM, David Gibson wrote: > >Currently, the emulated pSeries machine requires the use of the > >-kernel parameter in order to explicitly load a guest kernel. This > >means booting from the virtual disk, cdrom or network is not possible. > > > >This patch addresses this limitation by inserting a within-partition > >firmware image (derived from the "SLOF" free Open Firmware project). > >If -kernel is not specified, qemu will now load the SLOF image, which > >has access to the qemu boot device list through the device tree, and > >can boot from any of the usual virtual devices. > > > >In order to support the new firmware, an extension to the emulated > >machine/hypervisor is necessary. Unlike Linux, which expects > >multi-CPU entry to be handled kexec() style, the SLOF firmware expects > >only one CPU to be active at entry, and to use a hypervisor RTAS > >method to enable the other CPUs one by one. > > > >This patch also implements this 'start-cpu' method, so that SLOF can > >start the secondary CPUs and marshal them into the kexec() holding > >pattern ready for entry into the guest OS. Linux should, and in the > >future might directly use the start-cpu method to enable initially > >disabled CPUs, but for now it does require kexec() entry. > > > >Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org> > >Signed-off-by: Paul Mackerras<paulus@samba.org> > >Signed-off-by: David Gibson<dwg@au1.ibm.com> > > We should pull in SLOF via a git submodule. That ensures we ship > the source code along with the binary. Um, ok. Do I need to do anything about this?
On 28.03.2011, at 03:19, David Gibson wrote: > On Fri, Mar 25, 2011 at 01:29:17PM -0500, Anthony Liguori wrote: >> On 03/24/2011 10:21 PM, David Gibson wrote: >>> Currently, the emulated pSeries machine requires the use of the >>> -kernel parameter in order to explicitly load a guest kernel. This >>> means booting from the virtual disk, cdrom or network is not possible. >>> >>> This patch addresses this limitation by inserting a within-partition >>> firmware image (derived from the "SLOF" free Open Firmware project). >>> If -kernel is not specified, qemu will now load the SLOF image, which >>> has access to the qemu boot device list through the device tree, and >>> can boot from any of the usual virtual devices. >>> >>> In order to support the new firmware, an extension to the emulated >>> machine/hypervisor is necessary. Unlike Linux, which expects >>> multi-CPU entry to be handled kexec() style, the SLOF firmware expects >>> only one CPU to be active at entry, and to use a hypervisor RTAS >>> method to enable the other CPUs one by one. >>> >>> This patch also implements this 'start-cpu' method, so that SLOF can >>> start the secondary CPUs and marshal them into the kexec() holding >>> pattern ready for entry into the guest OS. Linux should, and in the >>> future might directly use the start-cpu method to enable initially >>> disabled CPUs, but for now it does require kexec() entry. >>> >>> Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org> >>> Signed-off-by: Paul Mackerras<paulus@samba.org> >>> Signed-off-by: David Gibson<dwg@au1.ibm.com> >> >> We should pull in SLOF via a git submodule. That ensures we ship >> the source code along with the binary. > > Um, ok. Do I need to do anything about this? I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. Alex
On 25.03.2011, at 04:21, David Gibson wrote: > Currently, the emulated pSeries machine requires the use of the > -kernel parameter in order to explicitly load a guest kernel. This > means booting from the virtual disk, cdrom or network is not possible. > > This patch addresses this limitation by inserting a within-partition > firmware image (derived from the "SLOF" free Open Firmware project). > If -kernel is not specified, qemu will now load the SLOF image, which > has access to the qemu boot device list through the device tree, and > can boot from any of the usual virtual devices. > > In order to support the new firmware, an extension to the emulated > machine/hypervisor is necessary. Unlike Linux, which expects > multi-CPU entry to be handled kexec() style, the SLOF firmware expects > only one CPU to be active at entry, and to use a hypervisor RTAS > method to enable the other CPUs one by one. > > This patch also implements this 'start-cpu' method, so that SLOF can > start the secondary CPUs and marshal them into the kexec() holding > pattern ready for entry into the guest OS. Linux should, and in the > future might directly use the start-cpu method to enable initially > disabled CPUs, but for now it does require kexec() entry. > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Signed-off-by: Paul Mackerras <paulus@samba.org> > Signed-off-by: David Gibson <dwg@au1.ibm.com> > --- > Makefile | 2 +- > hw/spapr.c | 35 +++++++++++++++++++++--- > hw/spapr_rtas.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > pc-bios/README | 5 +++ > pc-bios/slof.bin | Bin 0 -> 579072 bytes > 5 files changed, 115 insertions(+), 5 deletions(-) > create mode 100644 pc-bios/slof.bin > > diff --git a/Makefile b/Makefile > index e0b3fea..989622b 100644 > --- a/Makefile > +++ b/Makefile > @@ -214,7 +214,7 @@ pxe-rtl8139.bin pxe-virtio.bin \ > bamboo.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \ > multiboot.bin linuxboot.bin \ > s390-zipl.rom \ > -spapr-rtas.bin > +spapr-rtas.bin slof.bin > else > BLOBS= > endif > diff --git a/hw/spapr.c b/hw/spapr.c > index 9d611a7..c6454e6 100644 > --- a/hw/spapr.c > +++ b/hw/spapr.c > @@ -44,6 +44,10 @@ > #define INITRD_LOAD_ADDR 0x02800000 > #define FDT_MAX_SIZE 0x10000 > #define RTAS_MAX_SIZE 0x10000 > +#define FW_MAX_SIZE 0x400000 > +#define FW_FILE_NAME "slof.bin" > + > +#define MIN_RAM_SLOF 512UL > > #define TIMEBASE_FREQ 512000000ULL > > @@ -56,6 +60,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, > sPAPREnvironment *spapr, > target_phys_addr_t initrd_base, > target_phys_addr_t initrd_size, > + const char *boot_device, > const char *kernel_cmdline, > target_phys_addr_t rtas_addr, > target_phys_addr_t rtas_size, > @@ -104,6 +109,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, > &start_prop, sizeof(start_prop)))); > _FDT((fdt_property(fdt, "linux,initrd-end", > &end_prop, sizeof(end_prop)))); > + _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device))); > > _FDT((fdt_end_node(fdt))); > > @@ -260,7 +266,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, > ram_addr_t ram_offset; > target_phys_addr_t fdt_addr, rtas_addr; > uint32_t kernel_base, initrd_base; > - long kernel_size, initrd_size, htab_size, rtas_size; > + long kernel_size, initrd_size, htab_size, rtas_size, fw_size; > long pteg_shift = 17; > int fdt_size; > char *filename; > @@ -392,13 +398,33 @@ static void ppc_spapr_init(ram_addr_t ram_size, > initrd_size = 0; > } > } else { > - fprintf(stderr, "pSeries machine needs -kernel for now"); > - exit(1); > + if (ram_size < (MIN_RAM_SLOF << 20)) { > + fprintf(stderr, "qemu: pSeries SLOF firmware requires >= " > + "%ldM guest RAM\n", MIN_RAM_SLOF); > + exit(1); > + } > + filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, "slof.bin"); > + fw_size = load_image_targphys(filename, 0, FW_MAX_SIZE); > + if (fw_size < 0) { > + hw_error("qemu: could not load LPAR rtas '%s'\n", filename); > + exit(1); > + } > + qemu_free(filename); > + kernel_base = 0x100; > + initrd_base = 0; > + initrd_size = 0; > + > + /* SLOF will startup the secondary CPUs using RTAS, > + rather than expecting a kexec() style entry */ > + for (i = 0; i < smp_cpus; i++) { > + envs[i]->halted = 1; > + } > } > > /* Prepare the device tree */ > fdt = spapr_create_fdt(&fdt_size, ram_size, cpu_model, envs, spapr, > - initrd_base, initrd_size, kernel_cmdline, > + initrd_base, initrd_size, > + boot_device, kernel_cmdline, > rtas_addr, rtas_size, pteg_shift + 7); > assert(fdt != NULL); > > @@ -409,6 +435,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, > envs[0]->gpr[3] = fdt_addr; > envs[0]->gpr[5] = 0; > envs[0]->hreset_vector = kernel_base; > + envs[0]->halted = 0; > } > > static QEMUMachine spapr_machine = { > diff --git a/hw/spapr_rtas.c b/hw/spapr_rtas.c > index 7226853..16b6542 100644 > --- a/hw/spapr_rtas.c > +++ b/hw/spapr_rtas.c > @@ -90,6 +90,81 @@ static void rtas_power_off(sPAPREnvironment *spapr, > rtas_st(rets, 0, 0); > } > > +static void rtas_query_cpu_stopped_state(sPAPREnvironment *spapr, > + uint32_t token, uint32_t nargs, > + target_ulong args, > + uint32_t nret, target_ulong rets) > +{ > + target_ulong id; > + CPUState *env; > + > + if (nargs != 1 || nret != 2) { > + rtas_st(rets, 0, -3); > + return; > + } > + > + id = rtas_ld(args, 0); > + for (env = first_cpu; env; env = env->next_cpu) { > + if (env->cpu_index != id) { > + continue; > + } > + > + if (env->halted) { > + rtas_st(rets, 1, 0); > + } else { > + rtas_st(rets, 1, 2); > + } > + > + rtas_st(rets, 0, 0); > + return; > + } > + > + /* Didn't find a matching cpu */ > + rtas_st(rets, 0, -3); > +} > + > +static void rtas_start_cpu(sPAPREnvironment *spapr, > + uint32_t token, uint32_t nargs, > + target_ulong args, > + uint32_t nret, target_ulong rets) > +{ > + target_ulong id, start, r3; > + CPUState *env; > + > + if (nargs != 3 || nret != 1) { > + rtas_st(rets, 0, -3); > + return; > + } > + > + id = rtas_ld(args, 0); > + start = rtas_ld(args, 1); > + r3 = rtas_ld(args, 2); > + > + for (env = first_cpu; env; env = env->next_cpu) { > + if (env->cpu_index != id) { > + continue; > + } > + > + if (!env->halted) { > + rtas_st(rets, 0, -1); > + return; > + } > + > + env->msr = (1ULL << MSR_SF) | (1ULL << MSR_ME); > + env->nip = start; > + env->gpr[3] = r3; > + env->halted = 0; > + > + qemu_cpu_kick(env); > + > + rtas_st(rets, 0, 0); > + return; > + } > + > + /* Didn't find a matching cpu */ > + rtas_st(rets, 0, -3); > +} > + > static struct rtas_call { > const char *name; > spapr_rtas_fn fn; > @@ -196,5 +271,8 @@ static void register_core_rtas(void) > spapr_rtas_register("display-character", rtas_display_character); > spapr_rtas_register("get-time-of-day", rtas_get_time_of_day); > spapr_rtas_register("power-off", rtas_power_off); > + spapr_rtas_register("query-cpu-stopped-state", > + rtas_query_cpu_stopped_state); > + spapr_rtas_register("start-cpu", rtas_start_cpu); > } > device_init(register_core_rtas); > diff --git a/pc-bios/README b/pc-bios/README > index 3fc0944..646a31a 100644 > --- a/pc-bios/README > +++ b/pc-bios/README > @@ -13,6 +13,11 @@ > The included image for PowerPC (for 32 and 64 bit PPC CPUs), Sparc32 > and Sparc64 are built from OpenBIOS SVN revision 1018. > > +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware > + implementation for certain IBM POWER hardware. The sources are at > + https://github.com/dgibson/SLOF, and the image currently in qemu is > + built from git tag qemu-slof-20110323. > + > - The PXE roms come from Rom-o-Matic gPXE 0.9.9 with BANNER_TIMEOUT=0 Is this a line removal? Alex
On 03/28/2011 12:30 PM, Alexander Graf wrote: > > On 25.03.2011, at 04:21, David Gibson wrote: > >> Currently, the emulated pSeries machine requires the use of the >> -kernel parameter in order to explicitly load a guest kernel. This >> means booting from the virtual disk, cdrom or network is not possible. >> >> This patch addresses this limitation by inserting a within-partition >> firmware image (derived from the "SLOF" free Open Firmware project). >> If -kernel is not specified, qemu will now load the SLOF image, which >> has access to the qemu boot device list through the device tree, and >> can boot from any of the usual virtual devices. >> >> In order to support the new firmware, an extension to the emulated >> machine/hypervisor is necessary. Unlike Linux, which expects >> multi-CPU entry to be handled kexec() style, the SLOF firmware expects >> only one CPU to be active at entry, and to use a hypervisor RTAS >> method to enable the other CPUs one by one. >> >> This patch also implements this 'start-cpu' method, so that SLOF can >> start the secondary CPUs and marshal them into the kexec() holding >> pattern ready for entry into the guest OS. Linux should, and in the >> future might directly use the start-cpu method to enable initially >> disabled CPUs, but for now it does require kexec() entry. >> >> Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org> >> Signed-off-by: Paul Mackerras<paulus@samba.org> >> Signed-off-by: David Gibson<dwg@au1.ibm.com> >> --- >> Makefile | 2 +- >> hw/spapr.c | 35 +++++++++++++++++++++--- >> hw/spapr_rtas.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> pc-bios/README | 5 +++ >> pc-bios/slof.bin | Bin 0 -> 579072 bytes >> 5 files changed, 115 insertions(+), 5 deletions(-) >> create mode 100644 pc-bios/slof.bin >> >> diff --git a/Makefile b/Makefile >> index e0b3fea..989622b 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -214,7 +214,7 @@ pxe-rtl8139.bin pxe-virtio.bin \ >> bamboo.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \ >> multiboot.bin linuxboot.bin \ >> s390-zipl.rom \ >> -spapr-rtas.bin >> +spapr-rtas.bin slof.bin >> else >> BLOBS= >> endif >> diff --git a/hw/spapr.c b/hw/spapr.c >> index 9d611a7..c6454e6 100644 >> --- a/hw/spapr.c >> +++ b/hw/spapr.c >> @@ -44,6 +44,10 @@ >> #define INITRD_LOAD_ADDR 0x02800000 >> #define FDT_MAX_SIZE 0x10000 >> #define RTAS_MAX_SIZE 0x10000 >> +#define FW_MAX_SIZE 0x400000 >> +#define FW_FILE_NAME "slof.bin" >> + >> +#define MIN_RAM_SLOF 512UL >> >> #define TIMEBASE_FREQ 512000000ULL >> >> @@ -56,6 +60,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, >> sPAPREnvironment *spapr, >> target_phys_addr_t initrd_base, >> target_phys_addr_t initrd_size, >> + const char *boot_device, >> const char *kernel_cmdline, >> target_phys_addr_t rtas_addr, >> target_phys_addr_t rtas_size, >> @@ -104,6 +109,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, >> &start_prop, sizeof(start_prop)))); >> _FDT((fdt_property(fdt, "linux,initrd-end", >> &end_prop, sizeof(end_prop)))); >> + _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device))); >> >> _FDT((fdt_end_node(fdt))); >> >> @@ -260,7 +266,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, >> ram_addr_t ram_offset; >> target_phys_addr_t fdt_addr, rtas_addr; >> uint32_t kernel_base, initrd_base; >> - long kernel_size, initrd_size, htab_size, rtas_size; >> + long kernel_size, initrd_size, htab_size, rtas_size, fw_size; >> long pteg_shift = 17; >> int fdt_size; >> char *filename; >> @@ -392,13 +398,33 @@ static void ppc_spapr_init(ram_addr_t ram_size, >> initrd_size = 0; >> } >> } else { >> - fprintf(stderr, "pSeries machine needs -kernel for now"); >> - exit(1); >> + if (ram_size< (MIN_RAM_SLOF<< 20)) { >> + fprintf(stderr, "qemu: pSeries SLOF firmware requires>= " >> + "%ldM guest RAM\n", MIN_RAM_SLOF); >> + exit(1); >> + } >> + filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, "slof.bin"); >> + fw_size = load_image_targphys(filename, 0, FW_MAX_SIZE); >> + if (fw_size< 0) { >> + hw_error("qemu: could not load LPAR rtas '%s'\n", filename); >> + exit(1); >> + } >> + qemu_free(filename); >> + kernel_base = 0x100; >> + initrd_base = 0; >> + initrd_size = 0; >> + >> + /* SLOF will startup the secondary CPUs using RTAS, >> + rather than expecting a kexec() style entry */ >> + for (i = 0; i< smp_cpus; i++) { >> + envs[i]->halted = 1; >> + } >> } >> >> /* Prepare the device tree */ >> fdt = spapr_create_fdt(&fdt_size, ram_size, cpu_model, envs, spapr, >> - initrd_base, initrd_size, kernel_cmdline, >> + initrd_base, initrd_size, >> + boot_device, kernel_cmdline, >> rtas_addr, rtas_size, pteg_shift + 7); >> assert(fdt != NULL); >> >> @@ -409,6 +435,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, >> envs[0]->gpr[3] = fdt_addr; >> envs[0]->gpr[5] = 0; >> envs[0]->hreset_vector = kernel_base; >> + envs[0]->halted = 0; >> } >> >> static QEMUMachine spapr_machine = { >> diff --git a/hw/spapr_rtas.c b/hw/spapr_rtas.c >> index 7226853..16b6542 100644 >> --- a/hw/spapr_rtas.c >> +++ b/hw/spapr_rtas.c >> @@ -90,6 +90,81 @@ static void rtas_power_off(sPAPREnvironment *spapr, >> rtas_st(rets, 0, 0); >> } >> >> +static void rtas_query_cpu_stopped_state(sPAPREnvironment *spapr, >> + uint32_t token, uint32_t nargs, >> + target_ulong args, >> + uint32_t nret, target_ulong rets) >> +{ >> + target_ulong id; >> + CPUState *env; >> + >> + if (nargs != 1 || nret != 2) { >> + rtas_st(rets, 0, -3); >> + return; >> + } >> + >> + id = rtas_ld(args, 0); >> + for (env = first_cpu; env; env = env->next_cpu) { >> + if (env->cpu_index != id) { >> + continue; >> + } >> + >> + if (env->halted) { >> + rtas_st(rets, 1, 0); >> + } else { >> + rtas_st(rets, 1, 2); >> + } >> + >> + rtas_st(rets, 0, 0); >> + return; >> + } >> + >> + /* Didn't find a matching cpu */ >> + rtas_st(rets, 0, -3); >> +} >> + >> +static void rtas_start_cpu(sPAPREnvironment *spapr, >> + uint32_t token, uint32_t nargs, >> + target_ulong args, >> + uint32_t nret, target_ulong rets) >> +{ >> + target_ulong id, start, r3; >> + CPUState *env; >> + >> + if (nargs != 3 || nret != 1) { >> + rtas_st(rets, 0, -3); >> + return; >> + } >> + >> + id = rtas_ld(args, 0); >> + start = rtas_ld(args, 1); >> + r3 = rtas_ld(args, 2); >> + >> + for (env = first_cpu; env; env = env->next_cpu) { >> + if (env->cpu_index != id) { >> + continue; >> + } >> + >> + if (!env->halted) { >> + rtas_st(rets, 0, -1); >> + return; >> + } >> + >> + env->msr = (1ULL<< MSR_SF) | (1ULL<< MSR_ME); >> + env->nip = start; >> + env->gpr[3] = r3; >> + env->halted = 0; >> + >> + qemu_cpu_kick(env); >> + >> + rtas_st(rets, 0, 0); >> + return; >> + } >> + >> + /* Didn't find a matching cpu */ >> + rtas_st(rets, 0, -3); >> +} >> + >> static struct rtas_call { >> const char *name; >> spapr_rtas_fn fn; >> @@ -196,5 +271,8 @@ static void register_core_rtas(void) >> spapr_rtas_register("display-character", rtas_display_character); >> spapr_rtas_register("get-time-of-day", rtas_get_time_of_day); >> spapr_rtas_register("power-off", rtas_power_off); >> + spapr_rtas_register("query-cpu-stopped-state", >> + rtas_query_cpu_stopped_state); >> + spapr_rtas_register("start-cpu", rtas_start_cpu); >> } >> device_init(register_core_rtas); >> diff --git a/pc-bios/README b/pc-bios/README >> index 3fc0944..646a31a 100644 >> --- a/pc-bios/README >> +++ b/pc-bios/README >> @@ -13,6 +13,11 @@ >> The included image for PowerPC (for 32 and 64 bit PPC CPUs), Sparc32 >> and Sparc64 are built from OpenBIOS SVN revision 1018. >> >> +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware >> + implementation for certain IBM POWER hardware. The sources are at >> + https://github.com/dgibson/SLOF, and the image currently in qemu is >> + built from git tag qemu-slof-20110323. >> + >> - The PXE roms come from Rom-o-Matic gPXE 0.9.9 with BANNER_TIMEOUT=0 > > Is this a line removal? No, it's a bug in your mailer. :) Glad to see Thunderbird isn't the only one that butcher replies to patches (in addition to patches of course). Paolo
On 03/28/2011 12:30 PM, Alexander Graf wrote: >> diff --git a/pc-bios/README b/pc-bios/README >> index 3fc0944..646a31a 100644 >> --- a/pc-bios/README >> +++ b/pc-bios/README >> @@ -13,6 +13,11 @@ >> The included image for PowerPC (for 32 and 64 bit PPC CPUs), Sparc32 >> and Sparc64 are built from OpenBIOS SVN revision 1018. >> >> +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware >> + implementation for certain IBM POWER hardware. The sources are at >> + https://github.com/dgibson/SLOF, and the image currently in qemu is >> + built from git tag qemu-slof-20110323. >> + >> - The PXE roms come from Rom-o-Matic gPXE 0.9.9 with BANNER_TIMEOUT=0 > > Is this a line removal? No, it's a bug in your mailer. :) Glad to see Thunderbird isn't the only one that butcher replies to patches (in addition to patches of course). Paolo
On 28.03.2011, at 12:51, Paolo Bonzini wrote: > On 03/28/2011 12:30 PM, Alexander Graf wrote: >>> diff --git a/pc-bios/README b/pc-bios/README >>> index 3fc0944..646a31a 100644 >>> --- a/pc-bios/README >>> +++ b/pc-bios/README >>> @@ -13,6 +13,11 @@ >>> The included image for PowerPC (for 32 and 64 bit PPC CPUs), Sparc32 >>> and Sparc64 are built from OpenBIOS SVN revision 1018. >>> >>> +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware >>> + implementation for certain IBM POWER hardware. The sources are at >>> + https://github.com/dgibson/SLOF, and the image currently in qemu is >>> + built from git tag qemu-slof-20110323. >>> + >>> - The PXE roms come from Rom-o-Matic gPXE 0.9.9 with BANNER_TIMEOUT=0 >> >> Is this a line removal? > > No, it's a bug in your mailer. :) > > Glad to see Thunderbird isn't the only one that butcher replies to patches (in addition to patches of course). Glad to head that it's a bug O_o. Phew :) Alex
On 03/28/2011 11:03 AM, Alexander Graf wrote: > I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. > We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that.
On 28.03.2011, at 14:49, Avi Kivity wrote: > On 03/28/2011 11:03 AM, Alexander Graf wrote: >> I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. >> > > We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that. *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of scope of this patch set :). I personally don't mind the listing in the README file. Alex
On 03/28/2011 02:53 PM, Alexander Graf wrote: > On 28.03.2011, at 14:49, Avi Kivity wrote: > > > On 03/28/2011 11:03 AM, Alexander Graf wrote: > >> I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. > >> > > > > We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that. > > *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of scope of this patch set :). I personally don't mind the listing in the README file. It depends on how often the code changes. If it changes regularly and qemu is expected to take in newer versions, then we need to record which slof version comes with which qemu version. Submodules do just that.
On 28.03.2011, at 15:02, Avi Kivity wrote: > On 03/28/2011 02:53 PM, Alexander Graf wrote: >> On 28.03.2011, at 14:49, Avi Kivity wrote: >> >> > On 03/28/2011 11:03 AM, Alexander Graf wrote: >> >> I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. >> >> >> > >> > We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that. >> >> *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of scope of this patch set :). I personally don't mind the listing in the README file. > > It depends on how often the code changes. If it changes regularly and qemu is expected to take in newer versions, then we need to record which slof version comes with which qemu version. Submodules do just that. A commit id / tag in the README document it pretty well, no? Also, a README file is human readable. Submodules don't really buy anyone anything. Normal users don't care about the source - they use the bundled binaries. Distributers will have to bundle the source code anyways, because the build process is always offline. You can't always build everything either, as there are targets in qemu that people don't have cross-compilers for. It feels like the submodule idea is more of a feature that's "cool to play with" rather than of benefit for anyone. Alex
On 03/27/2011 08:19 PM, David Gibson wrote: >> We should pull in SLOF via a git submodule. That ensures we ship >> the source code along with the binary. > Um, ok. Do I need to do anything about this? We should introduce SLOF as one patch that adds the git submodule and the binary. The best way to do this is for me to pull as binary diffs on the list kind of suck. But before we do the git submodule, I need to mirror SLOF on qemu.org such that everything can be fetched from one place. Ping me later today when you get online and I'll explain how to do the git submodule part. Regards, Anthony Liguori
On 03/28/2011 04:03 AM, Alexander Graf wrote: > >> Um, ok. Do I need to do anything about this? > I'm also not sure this is too important. It's GPL compliance so yes, it's very important. > Most of our firmware blobs come from svn repos which can't be submoduled. The only firmware blob we're not currently including as a git submodule is OpenBIOS. I believe the main reason is that different boards use different commits so a single submodule is a bit challenge. We probably ought to figure something out here though for the next release. Can anyone comment a bit more about OpenBIOS? BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's needed is a patch that does a git submodule add with the appropriate commit. > And as long as we don't have a consistent policy about it, we can just as well stick with the README file. We do have a consistent policy :-) We're just not enforcing it as tightly as we should. Any binary we ship in the release tgz's should also have corresponding source in a submodule. Regards, Anthony Liguori > > Alex > >
On 03/28/2011 08:08 AM, Alexander Graf wrote: > >> It depends on how often the code changes. If it changes regularly and qemu is expected to take in newer versions, then we need to record which slof version comes with which qemu version. Submodules do just that. > A commit id / tag in the README document it pretty well, no? Also, a README file is human readable. Submodules don't really buy anyone anything. When I do a release, I do the equivalent of: git submodule update --init rm -rf roms/*/.git rm -rf .git Having the information is submodules makes this process automated and repeatable. The main motivation is that we need to ship source for any binary we include in our tarball. Regards, Anthony Liguori
On Mon, Mar 28, 2011 at 08:16:51AM -0500, Anthony Liguori wrote: > On 03/28/2011 04:03 AM, Alexander Graf wrote: > > > >>Um, ok. Do I need to do anything about this? > >I'm also not sure this is too important. > > It's GPL compliance so yes, it's very important. > > > Most of our firmware blobs come from svn repos which can't be submoduled. > > The only firmware blob we're not currently including as a git > submodule is OpenBIOS. I believe the main reason is that different > boards use different commits so a single submodule is a bit > challenge. We probably ought to figure something out here though > for the next release. Um.. where? I don't see these sources. > Can anyone comment a bit more about OpenBIOS? > > BTW, OpenBIOS is already actively mirrored on git.qemu.org so all > that's needed is a patch that does a git submodule add with the > appropriate commit. > > > And as long as we don't have a consistent policy about it, we can > > just as well stick with the README file. > > We do have a consistent policy :-) We're just not enforcing it as > tightly as we should. > > Any binary we ship in the release tgz's should also have > corresponding source in a submodule. So, again, what do I need to do?
On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: > On 03/28/2011 04:03 AM, Alexander Graf wrote: >> >>> Um, ok. Do I need to do anything about this? >> >> I'm also not sure this is too important. > > It's GPL compliance so yes, it's very important. > >> Most of our firmware blobs come from svn repos which can't be submoduled. > > The only firmware blob we're not currently including as a git submodule is > OpenBIOS. No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > I believe the main reason is that different boards use different > commits so a single submodule is a bit challenge. We probably ought to > figure something out here though for the next release. > > Can anyone comment a bit more about OpenBIOS? > > BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > needed is a patch that does a git submodule add with the appropriate commit. That would be an improvement. Though building various OpenBIOS images depends on appropriate cross compilers. The situation is actually same as with SeaBIOS. >> And as long as we don't have a consistent policy about it, we can just as >> well stick with the README file. > > We do have a consistent policy :-) We're just not enforcing it as tightly > as we should. > > Any binary we ship in the release tgz's should also have corresponding > source in a submodule. What about OpenHack'Ware (and PReP machine), should it be deleted?
On 03/28/2011 12:42 PM, Blue Swirl wrote: > On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: >> On 03/28/2011 04:03 AM, Alexander Graf wrote: >>>> Um, ok. Do I need to do anything about this? >>> I'm also not sure this is too important. >> It's GPL compliance so yes, it's very important. >> >>> Most of our firmware blobs come from svn repos which can't be submoduled. >> The only firmware blob we're not currently including as a git submodule is >> OpenBIOS. > No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. Alex, what's the source of zipl? >> I believe the main reason is that different boards use different >> commits so a single submodule is a bit challenge. We probably ought to >> figure something out here though for the next release. >> >> Can anyone comment a bit more about OpenBIOS? >> >> BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's >> needed is a patch that does a git submodule add with the appropriate commit. > That would be an improvement. Though building various OpenBIOS images > depends on appropriate cross compilers. The situation is actually same > as with SeaBIOS. Can you do a git submodule add then? >>> And as long as we don't have a consistent policy about it, we can just as >>> well stick with the README file. >> We do have a consistent policy :-) We're just not enforcing it as tightly >> as we should. >> >> Any binary we ship in the release tgz's should also have corresponding >> source in a submodule. > What about OpenHack'Ware (and PReP machine), should it be deleted? Yes. I don't think the source for that is available, correct? I don't think we have any other choice. Regards, Anthony Liguori
On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: > On 03/28/2011 12:42 PM, Blue Swirl wrote: > >On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: > >>On 03/28/2011 04:03 AM, Alexander Graf wrote: > >>>>Um, ok. Do I need to do anything about this? > >>>I'm also not sure this is too important. > >>It's GPL compliance so yes, it's very important. > >> > >>> Most of our firmware blobs come from svn repos which can't be submoduled. > >>The only firmware blob we're not currently including as a git submodule is > >>OpenBIOS. > >No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > > Alex, what's the source of zipl? > > >> I believe the main reason is that different boards use different > >>commits so a single submodule is a bit challenge. We probably ought to > >>figure something out here though for the next release. > >> > >>Can anyone comment a bit more about OpenBIOS? > >> > >>BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > >>needed is a patch that does a git submodule add with the appropriate commit. > >That would be an improvement. Though building various OpenBIOS images > >depends on appropriate cross compilers. The situation is actually same > >as with SeaBIOS. > > Can you do a git submodule add then? > > >>> And as long as we don't have a consistent policy about it, we can just as > >>>well stick with the README file. > >>We do have a consistent policy :-) We're just not enforcing it as tightly > >>as we should. > >> > >>Any binary we ship in the release tgz's should also have corresponding > >>source in a submodule. > >What about OpenHack'Ware (and PReP machine), should it be deleted? > > Yes. I don't think the source for that is available, correct? I > don't think we have any other choice. > Debian still holds a copy of the code. People have worked recently to restore prep support that has been broken by various patches, it would be a pitty to remove it without before asking them.
On 03/28/2011 01:24 PM, Aurelien Jarno wrote: > On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: >> On 03/28/2011 12:42 PM, Blue Swirl wrote: >>> On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: >>>> On 03/28/2011 04:03 AM, Alexander Graf wrote: >>>>>> Um, ok. Do I need to do anything about this? >>>>> I'm also not sure this is too important. >>>> It's GPL compliance so yes, it's very important. >>>> >>>>> Most of our firmware blobs come from svn repos which can't be submoduled. >>>> The only firmware blob we're not currently including as a git submodule is >>>> OpenBIOS. >>> No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. >> Alex, what's the source of zipl? >> >>>> I believe the main reason is that different boards use different >>>> commits so a single submodule is a bit challenge. We probably ought to >>>> figure something out here though for the next release. >>>> >>>> Can anyone comment a bit more about OpenBIOS? >>>> >>>> BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's >>>> needed is a patch that does a git submodule add with the appropriate commit. >>> That would be an improvement. Though building various OpenBIOS images >>> depends on appropriate cross compilers. The situation is actually same >>> as with SeaBIOS. >> Can you do a git submodule add then? >> >>>>> And as long as we don't have a consistent policy about it, we can just as >>>>> well stick with the README file. >>>> We do have a consistent policy :-) We're just not enforcing it as tightly >>>> as we should. >>>> >>>> Any binary we ship in the release tgz's should also have corresponding >>>> source in a submodule. >>> What about OpenHack'Ware (and PReP machine), should it be deleted? >> Yes. I don't think the source for that is available, correct? I >> don't think we have any other choice. >> > Debian still holds a copy of the code. I had thought that the actual binary was from Jocelyn and contains patches that noone else has. In fact, the last commit is: commit 55aa45ddde3283cdd781326d001f7456bf02f684 Author: j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162> Date: Mon Oct 1 06:44:33 2007 +0000 Quickly hack PowerPC BIOS able to boot on CDROM again. > People have worked recently to > restore prep support that has been broken by various patches, it would > be a pitty to remove it without before asking them. I'd be very happy to just submodule whatever sources Debian is using. Regards, Anthony Liguori
On Mon, Mar 28, 2011 at 01:50:40PM -0500, Anthony Liguori wrote: > On 03/28/2011 01:24 PM, Aurelien Jarno wrote: > >On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: > >>On 03/28/2011 12:42 PM, Blue Swirl wrote: > >>>On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: > >>>>On 03/28/2011 04:03 AM, Alexander Graf wrote: > >>>>>>Um, ok. Do I need to do anything about this? > >>>>>I'm also not sure this is too important. > >>>>It's GPL compliance so yes, it's very important. > >>>> > >>>>> Most of our firmware blobs come from svn repos which can't be submoduled. > >>>>The only firmware blob we're not currently including as a git submodule is > >>>>OpenBIOS. > >>>No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > >>Alex, what's the source of zipl? > >> > >>>> I believe the main reason is that different boards use different > >>>>commits so a single submodule is a bit challenge. We probably ought to > >>>>figure something out here though for the next release. > >>>> > >>>>Can anyone comment a bit more about OpenBIOS? > >>>> > >>>>BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > >>>>needed is a patch that does a git submodule add with the appropriate commit. > >>>That would be an improvement. Though building various OpenBIOS images > >>>depends on appropriate cross compilers. The situation is actually same > >>>as with SeaBIOS. > >>Can you do a git submodule add then? > >> > >>>>> And as long as we don't have a consistent policy about it, we can just as > >>>>>well stick with the README file. > >>>>We do have a consistent policy :-) We're just not enforcing it as tightly > >>>>as we should. > >>>> > >>>>Any binary we ship in the release tgz's should also have corresponding > >>>>source in a submodule. > >>>What about OpenHack'Ware (and PReP machine), should it be deleted? > >>Yes. I don't think the source for that is available, correct? I > >>don't think we have any other choice. > >> > >Debian still holds a copy of the code. > > I had thought that the actual binary was from Jocelyn and contains > patches that noone else has. In fact, the last commit is: > > commit 55aa45ddde3283cdd781326d001f7456bf02f684 > Author: j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162> > Date: Mon Oct 1 06:44:33 2007 +0000 > > Quickly hack PowerPC BIOS able to boot on CDROM again. > > > People have worked recently to > >restore prep support that has been broken by various patches, it would > >be a pitty to remove it without before asking them. > > I'd be very happy to just submodule whatever sources Debian is using. > I am not sure that it corresponds to the latest code, so it might have some issues, but at least it is something that is usable. The code is a vailable from: http://ftp.debian.org/debian/pool/main/o/openhackware/ Note that the .diff.gz contains a few patches needed to fix build issues.
On Mon, Mar 28, 2011 at 08:13:04AM -0500, Anthony Liguori wrote: > On 03/27/2011 08:19 PM, David Gibson wrote: > >>We should pull in SLOF via a git submodule. That ensures we ship > >>the source code along with the binary. > >Um, ok. Do I need to do anything about this? > > We should introduce SLOF as one patch that adds the git submodule > and the binary. > > The best way to do this is for me to pull as binary diffs on the > list kind of suck. > > But before we do the git submodule, I need to mirror SLOF on > qemu.org such that everything can be fetched from one place. Ping > me later today when you get online and I'll explain how to do the > git submodule part. Sorry, I slept badly last night and wasn't up until after you'd gone. Can you email the instructions instead.
On 28.03.2011, at 20:02, Anthony Liguori wrote: > On 03/28/2011 12:42 PM, Blue Swirl wrote: >> On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: >>> On 03/28/2011 04:03 AM, Alexander Graf wrote: >>>>> Um, ok. Do I need to do anything about this? >>>> I'm also not sure this is too important. >>> It's GPL compliance so yes, it's very important. >>> >>>> Most of our firmware blobs come from svn repos which can't be submoduled. >>> The only firmware blob we're not currently including as a git submodule is >>> OpenBIOS. >> No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > > Alex, what's the source of zipl? See the README file :P. git://repo.or.cz/s390-tools.git virtio-zipl Alex
On 28.03.2011, at 21:52, Aurelien Jarno wrote: > On Mon, Mar 28, 2011 at 01:50:40PM -0500, Anthony Liguori wrote: >> On 03/28/2011 01:24 PM, Aurelien Jarno wrote: >>> On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: >>>> On 03/28/2011 12:42 PM, Blue Swirl wrote: >>>>> On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: >>>>>> On 03/28/2011 04:03 AM, Alexander Graf wrote: >>>>>>>> Um, ok. Do I need to do anything about this? >>>>>>> I'm also not sure this is too important. >>>>>> It's GPL compliance so yes, it's very important. >>>>>> >>>>>>> Most of our firmware blobs come from svn repos which can't be submoduled. >>>>>> The only firmware blob we're not currently including as a git submodule is >>>>>> OpenBIOS. >>>>> No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. >>>> Alex, what's the source of zipl? >>>> >>>>>> I believe the main reason is that different boards use different >>>>>> commits so a single submodule is a bit challenge. We probably ought to >>>>>> figure something out here though for the next release. >>>>>> >>>>>> Can anyone comment a bit more about OpenBIOS? >>>>>> >>>>>> BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's >>>>>> needed is a patch that does a git submodule add with the appropriate commit. >>>>> That would be an improvement. Though building various OpenBIOS images >>>>> depends on appropriate cross compilers. The situation is actually same >>>>> as with SeaBIOS. >>>> Can you do a git submodule add then? >>>> >>>>>>> And as long as we don't have a consistent policy about it, we can just as >>>>>>> well stick with the README file. >>>>>> We do have a consistent policy :-) We're just not enforcing it as tightly >>>>>> as we should. >>>>>> >>>>>> Any binary we ship in the release tgz's should also have corresponding >>>>>> source in a submodule. >>>>> What about OpenHack'Ware (and PReP machine), should it be deleted? >>>> Yes. I don't think the source for that is available, correct? I >>>> don't think we have any other choice. >>>> >>> Debian still holds a copy of the code. >> >> I had thought that the actual binary was from Jocelyn and contains >> patches that noone else has. In fact, the last commit is: >> >> commit 55aa45ddde3283cdd781326d001f7456bf02f684 >> Author: j_mayer <j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162> >> Date: Mon Oct 1 06:44:33 2007 +0000 >> >> Quickly hack PowerPC BIOS able to boot on CDROM again. >> >>> People have worked recently to >>> restore prep support that has been broken by various patches, it would >>> be a pitty to remove it without before asking them. >> >> I'd be very happy to just submodule whatever sources Debian is using. >> > > I am not sure that it corresponds to the latest code, so it might have > some issues, but at least it is something that is usable. The code is a > vailable from: > > http://ftp.debian.org/debian/pool/main/o/openhackware/ > > Note that the .diff.gz contains a few patches needed to fix build > issues. I really wouldn't want to see PREP getting removed, now that we have a maintainer for it again :). It might be a good idea to recompile the binary we ship from that source though? Alex
diff --git a/Makefile b/Makefile index e0b3fea..989622b 100644 --- a/Makefile +++ b/Makefile @@ -214,7 +214,7 @@ pxe-rtl8139.bin pxe-virtio.bin \ bamboo.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \ multiboot.bin linuxboot.bin \ s390-zipl.rom \ -spapr-rtas.bin +spapr-rtas.bin slof.bin else BLOBS= endif diff --git a/hw/spapr.c b/hw/spapr.c index 9d611a7..c6454e6 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -44,6 +44,10 @@ #define INITRD_LOAD_ADDR 0x02800000 #define FDT_MAX_SIZE 0x10000 #define RTAS_MAX_SIZE 0x10000 +#define FW_MAX_SIZE 0x400000 +#define FW_FILE_NAME "slof.bin" + +#define MIN_RAM_SLOF 512UL #define TIMEBASE_FREQ 512000000ULL @@ -56,6 +60,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, sPAPREnvironment *spapr, target_phys_addr_t initrd_base, target_phys_addr_t initrd_size, + const char *boot_device, const char *kernel_cmdline, target_phys_addr_t rtas_addr, target_phys_addr_t rtas_size, @@ -104,6 +109,7 @@ static void *spapr_create_fdt(int *fdt_size, ram_addr_t ramsize, &start_prop, sizeof(start_prop)))); _FDT((fdt_property(fdt, "linux,initrd-end", &end_prop, sizeof(end_prop)))); + _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device))); _FDT((fdt_end_node(fdt))); @@ -260,7 +266,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, ram_addr_t ram_offset; target_phys_addr_t fdt_addr, rtas_addr; uint32_t kernel_base, initrd_base; - long kernel_size, initrd_size, htab_size, rtas_size; + long kernel_size, initrd_size, htab_size, rtas_size, fw_size; long pteg_shift = 17; int fdt_size; char *filename; @@ -392,13 +398,33 @@ static void ppc_spapr_init(ram_addr_t ram_size, initrd_size = 0; } } else { - fprintf(stderr, "pSeries machine needs -kernel for now"); - exit(1); + if (ram_size < (MIN_RAM_SLOF << 20)) { + fprintf(stderr, "qemu: pSeries SLOF firmware requires >= " + "%ldM guest RAM\n", MIN_RAM_SLOF); + exit(1); + } + filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, "slof.bin"); + fw_size = load_image_targphys(filename, 0, FW_MAX_SIZE); + if (fw_size < 0) { + hw_error("qemu: could not load LPAR rtas '%s'\n", filename); + exit(1); + } + qemu_free(filename); + kernel_base = 0x100; + initrd_base = 0; + initrd_size = 0; + + /* SLOF will startup the secondary CPUs using RTAS, + rather than expecting a kexec() style entry */ + for (i = 0; i < smp_cpus; i++) { + envs[i]->halted = 1; + } } /* Prepare the device tree */ fdt = spapr_create_fdt(&fdt_size, ram_size, cpu_model, envs, spapr, - initrd_base, initrd_size, kernel_cmdline, + initrd_base, initrd_size, + boot_device, kernel_cmdline, rtas_addr, rtas_size, pteg_shift + 7); assert(fdt != NULL); @@ -409,6 +435,7 @@ static void ppc_spapr_init(ram_addr_t ram_size, envs[0]->gpr[3] = fdt_addr; envs[0]->gpr[5] = 0; envs[0]->hreset_vector = kernel_base; + envs[0]->halted = 0; } static QEMUMachine spapr_machine = { diff --git a/hw/spapr_rtas.c b/hw/spapr_rtas.c index 7226853..16b6542 100644 --- a/hw/spapr_rtas.c +++ b/hw/spapr_rtas.c @@ -90,6 +90,81 @@ static void rtas_power_off(sPAPREnvironment *spapr, rtas_st(rets, 0, 0); } +static void rtas_query_cpu_stopped_state(sPAPREnvironment *spapr, + uint32_t token, uint32_t nargs, + target_ulong args, + uint32_t nret, target_ulong rets) +{ + target_ulong id; + CPUState *env; + + if (nargs != 1 || nret != 2) { + rtas_st(rets, 0, -3); + return; + } + + id = rtas_ld(args, 0); + for (env = first_cpu; env; env = env->next_cpu) { + if (env->cpu_index != id) { + continue; + } + + if (env->halted) { + rtas_st(rets, 1, 0); + } else { + rtas_st(rets, 1, 2); + } + + rtas_st(rets, 0, 0); + return; + } + + /* Didn't find a matching cpu */ + rtas_st(rets, 0, -3); +} + +static void rtas_start_cpu(sPAPREnvironment *spapr, + uint32_t token, uint32_t nargs, + target_ulong args, + uint32_t nret, target_ulong rets) +{ + target_ulong id, start, r3; + CPUState *env; + + if (nargs != 3 || nret != 1) { + rtas_st(rets, 0, -3); + return; + } + + id = rtas_ld(args, 0); + start = rtas_ld(args, 1); + r3 = rtas_ld(args, 2); + + for (env = first_cpu; env; env = env->next_cpu) { + if (env->cpu_index != id) { + continue; + } + + if (!env->halted) { + rtas_st(rets, 0, -1); + return; + } + + env->msr = (1ULL << MSR_SF) | (1ULL << MSR_ME); + env->nip = start; + env->gpr[3] = r3; + env->halted = 0; + + qemu_cpu_kick(env); + + rtas_st(rets, 0, 0); + return; + } + + /* Didn't find a matching cpu */ + rtas_st(rets, 0, -3); +} + static struct rtas_call { const char *name; spapr_rtas_fn fn; @@ -196,5 +271,8 @@ static void register_core_rtas(void) spapr_rtas_register("display-character", rtas_display_character); spapr_rtas_register("get-time-of-day", rtas_get_time_of_day); spapr_rtas_register("power-off", rtas_power_off); + spapr_rtas_register("query-cpu-stopped-state", + rtas_query_cpu_stopped_state); + spapr_rtas_register("start-cpu", rtas_start_cpu); } device_init(register_core_rtas); diff --git a/pc-bios/README b/pc-bios/README index 3fc0944..646a31a 100644 --- a/pc-bios/README +++ b/pc-bios/README @@ -13,6 +13,11 @@ The included image for PowerPC (for 32 and 64 bit PPC CPUs), Sparc32 and Sparc64 are built from OpenBIOS SVN revision 1018. +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware + implementation for certain IBM POWER hardware. The sources are at + https://github.com/dgibson/SLOF, and the image currently in qemu is + built from git tag qemu-slof-20110323. + - The PXE roms come from Rom-o-Matic gPXE 0.9.9 with BANNER_TIMEOUT=0 e1000 8086:100E