[Qemu-devel] [PATCH 1/1] s390: IPL device for s390
An IPL (booting) on s390 of SCSI disks is done by a firmware component.
Lets implement this scheme as an qemu device that also allows to
configure the IPL like the HMC. We have a parameter iplid that
refers to a disk device and a load parm that specifies the entry
on the disk to be ipled. We also provide a default device
if no -device s390-ipl statement is given.
Signed-off-by: Christian Borntraeger
---
Makefile.target |2 +-
hw/s390-loader.c | 463 ++
hw/s390-loader.h | 81 ++
hw/s390-virtio.c | 36 +
vl.c |7 +
5 files changed, 554 insertions(+), 35 deletions(-)
create mode 100644 hw/s390-loader.c
create mode 100644 hw/s390-loader.h
diff --git a/Makefile.target b/Makefile.target
index 1582904..7b8cd84 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -374,7 +374,7 @@ obj-sh4-y += ide/mmio.o
obj-m68k-y = an5206.o mcf5206.o mcf_uart.o mcf_intc.o mcf5208.o mcf_fec.o
obj-m68k-y += m68k-semi.o dummy_m68k.o
-obj-s390x-y = s390-virtio-bus.o s390-virtio.o
+obj-s390x-y = s390-virtio-bus.o s390-virtio.o s390-loader.o
obj-alpha-y = mc146818rtc.o
obj-alpha-y += alpha_pci.o alpha_dp264.o alpha_typhoon.o
diff --git a/hw/s390-loader.c b/hw/s390-loader.c
new file mode 100644
index 000..2d63ecf
--- /dev/null
+++ b/hw/s390-loader.c
@@ -0,0 +1,463 @@
+/*
+ * bootloader support
+ * Copyright IBM Corp. 2007,2012
+ * Author: Christian Borntraeger
+ *
+ * This file is licensed under the terms of the GNU General Public License(GPL)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cpu.h"
+#include "hw/loader.h"
+#include "hw/s390-loader.h"
+#include "hw/s390-virtio-bus.h"
+#include "hw/sysbus.h"
+
+#define KERN_IMAGE_START0x01UL
+
+typedef struct {
+BlockDriverState *bs;
+uint64_t (*blockno)(BlockPtr *blockptr);
+uint64_t (*offset)(BlockPtr *blockptr);
+uint64_t (*size)(BlockPtr *blockptr);
+bool (*empty)(BlockPtr *blockptr);
+BlockPtr *(*element)(BlockPtr *blockptr, int num);
+uint32_t (*entries)(void);
+uint32_t loadparm;
+uint8_t heads;
+uint8_t secs;
+uint16_t blk_size;
+} Loader;
+
+/*
+ * We have one structure that is setup with the right callbacks for the
+ * detected type of boot loader
+ */
+static Loader loader;
+
+/* here are the FCP Callbacks */
+static uint64_t getblockno_fcp(BlockPtr *entry)
+{
+return be64_to_cpu(entry->u.fcp.blockno);
+}
+
+static uint64_t getoffset_fcp(BlockPtr *entry)
+{
+return getblockno_fcp(entry) * be16_to_cpu(entry->u.fcp.size);
+}
+
+static uint64_t getsize_fcp(BlockPtr *entry)
+{
+return loader.blk_size * (be16_to_cpu(entry->u.fcp.blockct) + 1);
+}
+
+static bool getempty_fcp(BlockPtr *entry)
+{
+return getblockno_fcp(entry) == 0UL;
+}
+
+static BlockPtr *getelement_fcp(BlockPtr *blockptr, int num)
+{
+ FCPBlockPtr *fcp = (FCPBlockPtr *) blockptr;
+
+ return (BlockPtr *) &fcp[num];
+}
+
+static uint32_t entries_fcp(void)
+{
+return loader.blk_size / sizeof(FCPBlockPtr);
+};
+
+/* and here the callbacks for the new and old eckd map */
+static uint64_t getblockno_eckd(BlockPtr *entry)
+{
+return 1UL * loader.secs * loader.heads * entry->u.eckd.cyls +
+ 1UL * loader.secs * entry->u.eckd.heads +
+ 1UL * entry->u.eckd.secs - 1UL;
+}
+
+static uint64_t getoffset_eckd(BlockPtr *entry)
+{
+return getblockno_eckd(entry) * entry->u.eckd.block_size;
+}
+
+static uint64_t getsize_eckd(BlockPtr *entry)
+{
+return loader.blk_size * (entry->u.eckd.count + 1);
+}
+
+static bool getempty_eckd(BlockPtr *entry)
+{
+return getblockno_eckd(entry) == -1UL;
+}
+
+static BlockPtr *getelement_eckd(BlockPtr *blockptr, int num)
+{
+ ECKDBlockPtr *eckd = (ECKDBlockPtr *) blockptr;
+
+ return (BlockPtr *) &eckd[num];
+}
+
+static BlockPtr *getelement_neckd(BlockPtr *blockptr, int num)
+{
+ NECKDBlockPtr *neckd = (NECKDBlockPtr *) blockptr;
+
+ return (BlockPtr *) &neckd[num];
+}
+
+
+static uint32_t entries_eckd(void)
+{
+return loader.blk_size / sizeof(ECKDBlockPtr);
+};
+
+static uint32_t entries_neckd(void)
+{
+return loader.blk_size / sizeof(NECKDBlockPtr);
+};
+
+static int magic_ok(void *tmp)
+{
+return memcmp(tmp, "zIPL", 4) == 0 ? 1 : 0;
+}
+
+static uint64_t parse_segment_elements(BlockPtr *bprs,
+ uint64_t *address,
+ Loader *loader)
+{
+unsigned d;
+int len;
+
+for (d = 0; d < loader->entries() - 1; d++) {
+if (*address > ram_size) {
+error_report("s390-ipl: bootmap points to illegal address");
+exit(1);
+}
+if (loader->empty(loader->element(bprs, d))) {
+return 0;
+}
+len = bdrv_pread(loader->bs,
+loader->offset(loader->element(bprs, d)),
+(void *)
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 04.05.2012, at 15:44, Christian Borntraeger wrote: > An IPL (booting) on s390 of SCSI disks is done by a firmware component. > Lets implement this scheme as an qemu device that also allows to > configure the IPL like the HMC. We have a parameter iplid that > refers to a disk device and a load parm that specifies the entry > on the disk to be ipled. We also provide a default device > if no -device s390-ipl statement is given. Any reason we can't do this in guest firmware code? Alex
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 04/05/12 15:53, Alexander Graf wrote: > > On 04.05.2012, at 15:44, Christian Borntraeger wrote: > >> An IPL (booting) on s390 of SCSI disks is done by a firmware component. >> Lets implement this scheme as an qemu device that also allows to >> configure the IPL like the HMC. We have a parameter iplid that >> refers to a disk device and a load parm that specifies the entry >> on the disk to be ipled. We also provide a default device >> if no -device s390-ipl statement is given. > > Any reason we can't do this in guest firmware code? Conceptually guest firmware does not exist in the guest address space on s390. It is separate in a storage area called HSA. (you could say the existing hardware is semi-hosted, you cant buy it bare metal. Doing the boot code in guest address space will fail if the guest firmware address collides with the addresses specified by a bootmap. Christian
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 04/05/12 16:00, Christian Borntraeger wrote: >>> An IPL (booting) on s390 of SCSI disks is done by a firmware component. >>> Lets implement this scheme as an qemu device that also allows to >>> configure the IPL like the HMC. We have a parameter iplid that >>> refers to a disk device and a load parm that specifies the entry >>> on the disk to be ipled. We also provide a default device >>> if no -device s390-ipl statement is given. >> >> Any reason we can't do this in guest firmware code? > > Conceptually guest firmware does not exist in the guest address space > on s390. It is separate in a storage area called HSA. > (you could say the existing hardware is semi-hosted, you cant buy it bare > metal. > Doing the boot code in guest address space will fail if the guest firmware > address collides with the addresses specified by a bootmap. Or in other words, this code is closer to the real s390 boxes.
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 04.05.2012, at 16:02, Christian Borntraeger wrote: > On 04/05/12 16:00, Christian Borntraeger wrote: An IPL (booting) on s390 of SCSI disks is done by a firmware component. Lets implement this scheme as an qemu device that also allows to configure the IPL like the HMC. We have a parameter iplid that refers to a disk device and a load parm that specifies the entry on the disk to be ipled. We also provide a default device if no -device s390-ipl statement is given. >>> >>> Any reason we can't do this in guest firmware code? >> >> Conceptually guest firmware does not exist in the guest address space >> on s390. It is separate in a storage area called HSA. >> (you could say the existing hardware is semi-hosted, you cant buy it bare >> metal. >> Doing the boot code in guest address space will fail if the guest firmware >> address collides with the addresses specified by a bootmap. > > Or in other words, this code is closer to the real s390 boxes. Yeah, I see the point. I'd really like to get Anthony's comments on this one first though. Alex
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 04/05/12 20:12, Alexander Graf wrote: > > On 04.05.2012, at 16:02, Christian Borntraeger wrote: > >> On 04/05/12 16:00, Christian Borntraeger wrote: > An IPL (booting) on s390 of SCSI disks is done by a firmware component. > Lets implement this scheme as an qemu device that also allows to > configure the IPL like the HMC. We have a parameter iplid that > refers to a disk device and a load parm that specifies the entry > on the disk to be ipled. We also provide a default device > if no -device s390-ipl statement is given. Any reason we can't do this in guest firmware code? >>> >>> Conceptually guest firmware does not exist in the guest address space >>> on s390. It is separate in a storage area called HSA. >>> (you could say the existing hardware is semi-hosted, you cant buy it bare >>> metal. >>> Doing the boot code in guest address space will fail if the guest firmware >>> address collides with the addresses specified by a bootmap. >> >> Or in other words, this code is closer to the real s390 boxes. > > Yeah, I see the point. I'd really like to get Anthony's comments on this one > first though. Right. Anthony, this is the prototype of the IPL device that we have talked about some weeks ago. Is an external device to do the IPL process for s390 still ok with you? Christian
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 08.05.2012, at 14:32, Christian Borntraeger wrote: > On 04/05/12 20:12, Alexander Graf wrote: >> >> On 04.05.2012, at 16:02, Christian Borntraeger wrote: >> >>> On 04/05/12 16:00, Christian Borntraeger wrote: >> An IPL (booting) on s390 of SCSI disks is done by a firmware component. >> Lets implement this scheme as an qemu device that also allows to >> configure the IPL like the HMC. We have a parameter iplid that >> refers to a disk device and a load parm that specifies the entry >> on the disk to be ipled. We also provide a default device >> if no -device s390-ipl statement is given. > > Any reason we can't do this in guest firmware code? Conceptually guest firmware does not exist in the guest address space on s390. It is separate in a storage area called HSA. (you could say the existing hardware is semi-hosted, you cant buy it bare metal. Doing the boot code in guest address space will fail if the guest firmware address collides with the addresses specified by a bootmap. >>> >>> Or in other words, this code is closer to the real s390 boxes. >> >> Yeah, I see the point. I'd really like to get Anthony's comments on this one >> first though. > > Right. > > Anthony, this is the prototype of the IPL device that we have talked about > some weeks > ago. Is an external device to do the IPL process for s390 still ok with you? Even with an external IPL, we should still be able to detect that a guest provides its own virtio-zipl code that contains a boot menu and execute that instead of directly booting into the first entry, right? Alex
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
>> Anthony, this is the prototype of the IPL device that we have talked about >> some weeks >> ago. Is an external device to do the IPL process for s390 still ok with you? > > Even with an external IPL, we should still be able to detect that a guest > provides > its own virtio-zipl code that contains a boot menu and execute that instead > of directly > booting into the first entry, right? This is something that we can argue about to find a way to cover all our use cases Some of my goals are - make it possible to install the boot loader in lpar/vm and boot in kvm and vice versa - follow the real HW ipl process (which I do for FCP, but not for dasd/eckd) - be able to choose a boot device (-boot is not the right thing for s390) - be able to choose an program (loadparm) - get a disk booted no matter if FCP, ECKD CDL, ECKD LDL, block size etc as long as this configuration can exist with the current tool sets (that includes ipling disks prepared with the sles11 tools) - have some code that can be extended to non-disk boot devices (s390-ipl takes a qdev id as parameter) Can you clarify what you need? the code should be modular enough to add a detection, a switch or something else to make that possible. Christian PS: long term we probably also want to have real ECKD dasd passthrough as an alternative to virtio for dasds. Then the IPL process will also include interpretation of ipl ccws, but this is something that wont be ready anytime soon
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 08.05.2012, at 16:43, Christian Borntraeger wrote: >>> Anthony, this is the prototype of the IPL device that we have talked about >>> some weeks >>> ago. Is an external device to do the IPL process for s390 still ok with you? >> >> Even with an external IPL, we should still be able to detect that a guest >> provides >> its own virtio-zipl code that contains a boot menu and execute that instead >> of directly >> booting into the first entry, right? > > This is something that we can argue about to find a way to cover all our use > cases > Some of my goals are > - make it possible to install the boot loader in lpar/vm and boot in kvm and > vice versa > - follow the real HW ipl process (which I do for FCP, but not for dasd/eckd) > - be able to choose a boot device (-boot is not the right thing for s390) > - be able to choose an program (loadparm) > - get a disk booted no matter if FCP, ECKD CDL, ECKD LDL, block size etc as > long as this > configuration can exist with the current tool sets (that includes ipling > disks prepared > with the sles11 tools) > - have some code that can be extended to non-disk boot devices (s390-ipl > takes a qdev id > as parameter) > > Can you clarify what you need? the code should be modular enough to add a > detection, a switch > or something else to make that possible. Well, the only shortcomings I'm aware of of the external IPL are: * You lose the boot menu. All you get is "entry 0", "entry 1", etc. as the description is not part of the boot map * You can't choose different entries during runtime. Doing a reboot of a VM and selecting a different entry won't work. The former is pretty annoying if you don't know all of your VMs by heart. The latter is an issue when you don't own the qemu process, but do own the VM. Think of a hosted environment. Issue 1 could be fixed for the future by changing the bootmap format to include the entry description in a well known format. As for the runtime selection, we can do some small piece of code that runs inside the guest, provides a choice to the user and then issues a call into QEMU to IPL into the "real" image. That way QEMU would still read out the bootmap and all of the guest RAM is available for the IPL'ed program. We would still maintain the ability to interact with the user though. > Christian > > PS: long term we probably also want to have real ECKD dasd passthrough as an > alternative to > virtio for dasds. Then the IPL process will also include interpretation of > ipl ccws, but this is > something that wont be ready anytime soon Makes sense. Though it might be useful to be able to run the on-disk code there too. Alex
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
> Well, the only shortcomings I'm aware of of the external IPL are: > > * You lose the boot menu. All you get is "entry 0", "entry 1", etc. as the > description is not part of the boot map > * You can't choose different entries during runtime. Doing a reboot of a VM > and selecting a different entry won't work. > > The former is pretty annoying if you don't know all of your VMs by heart. The > latter is an issue when you don't own the qemu process, > but do own the VM. Think of a hosted environment. Those are valid points. Regarding the former, I see two things that we might do here: 1. have the current zipl-"bios" as a fallback if the user does not specify an s390-ipl device. That should be pretty easy and might even have the advantage to minimize the surprise to existing users of kvm on s390(are there any?). If the user provides an s390-ipl device then this is a conscious decision. (I will move the specific virtio-zipl bios code into the s390-ipl device nevertheless,see below for rationale) 2. I will check with the zipl maintainer if we could sneak in the necessary information in the boot map, the program table or something else (e.g. defining an component_description, after component_execute). It just have to be compatible with the layout that the firmware loader expects. Not sure yet, if this will work out I definitely want to concentrate all booting in this device: kernel, zipl-virtio, firmware loader and everything else, because on system_reset we have to reset the cpus and set the PSW accordingly. As a device we are being called during reset at the right time. Does that make sense? If yes I will try to refresh that patch as outlined above Christian
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 05/08/2012 07:32 AM, Christian Borntraeger wrote: On 04/05/12 20:12, Alexander Graf wrote: On 04.05.2012, at 16:02, Christian Borntraeger wrote: On 04/05/12 16:00, Christian Borntraeger wrote: An IPL (booting) on s390 of SCSI disks is done by a firmware component. Lets implement this scheme as an qemu device that also allows to configure the IPL like the HMC. We have a parameter iplid that refers to a disk device and a load parm that specifies the entry on the disk to be ipled. We also provide a default device if no -device s390-ipl statement is given. Any reason we can't do this in guest firmware code? Conceptually guest firmware does not exist in the guest address space on s390. It is separate in a storage area called HSA. (you could say the existing hardware is semi-hosted, you cant buy it bare metal. Doing the boot code in guest address space will fail if the guest firmware address collides with the addresses specified by a bootmap. Or in other words, this code is closer to the real s390 boxes. Yeah, I see the point. I'd really like to get Anthony's comments on this one first though. Right. Anthony, this is the prototype of the IPL device that we have talked about some weeks ago. Is an external device to do the IPL process for s390 still ok with you? I don't really understand the point about collision. If you chain load carefully, you ought to be able to relocate or something like that I would imagine. But at any rate, for these semi-hosted platforms, I don't see a lot better choices than doing these things as devices since there's no "real hardware" to model. So doing this as a device and limiting it to s390 seems like the right strategy to me. Regards, Anthony Liguori Christian
Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
On 08.05.2012, at 20:54, Christian Borntraeger wrote: >> Well, the only shortcomings I'm aware of of the external IPL are: >> >> * You lose the boot menu. All you get is "entry 0", "entry 1", etc. as the >> description is not part of the boot map >> * You can't choose different entries during runtime. Doing a reboot of a VM >> and selecting a different entry won't work. >> >> The former is pretty annoying if you don't know all of your VMs by heart. >> The latter is an issue when you don't own the qemu process, >> but do own the VM. Think of a hosted environment. > > Those are valid points. Regarding the former, I see two things that we might > do here: > 1. have the current zipl-"bios" as a fallback if the user does not specify an > s390-ipl device. > That should be pretty easy and might even have the advantage to minimize the > surprise to > existing users of kvm on s390(are there any?). If the user provides an > s390-ipl device > then this is a conscious decision. (I will move the specific virtio-zipl bios > code into > the s390-ipl device nevertheless,see below for rationale) I would certainly want that, yes. What I was also envisioning on top was to run a new version of the zipl-"bios" that only communicates with the special bootup device and virtio-console. It could use all the memory it wants, read out the menu from the bootup device and when it's either run into a timeout or the user chose an entry, it could call into the bootup device to IPL the box for real. On reboot, IPL would happen into this new zipl-"bios", which would then IPL into the default entry or another user give choice if the user wants to choose something different. This gives us the possibility of the use case where the VMM owner is different from the VM owner. The VM owner only needs access to its console and is still able to boot however he likes. I don't think at this point that it'd make sense to share any code with zipl though, as we basically moved all zipl functionality into the bootup device. Maybe we could even do all of this in grub2 with a special pseudo-fs for the entries? Then the user could even modify kernel parameters on the fly! Omg :). Usability meets z ;) Either way, this is just an idea of the direction we should go here, to make sure the code we write today doesn't go against that direction. As long as we can have an "auto" mode that just loads some guest blob and runs that (zipl-bios today), I think we're good for now. > 2. I will check with the zipl maintainer if we could sneak in the necessary > information in > the boot map, the program table or something else (e.g. defining an > component_description, > after component_execute). It just have to be compatible with the layout that > the firmware > loader expects. Not sure yet, if this will work out That'd be great, yes! Worst case we can always add a "special" entry that is invisible in the boot menu, but contains metadata, no? It'd just be a normal IPL entry after all the user defined entries, just that nobody knows it exists ;). > I definitely want to concentrate all booting in this device: kernel, > zipl-virtio, firmware > loader and everything else, because on system_reset we have to reset the cpus > and set > the PSW accordingly. As a device we are being called during reset at the > right time. > > Does that make sense? If yes I will try to refresh that patch as outlined > above Yes, that makes perfect sense :) Alex
