| Message ID | 4E6606F3.5020102@de.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 06.09.2011, at 13:41, Christian Borntraeger wrote: > Alex, > > Newer kernels will not always have a 0dd0 (basr 13,0) at address 0x10000. > (e.g. current linux-next). We must not rely on specific code at certain > addresses, so lets just remove this check. Is there any other sane way we can find out if the image we're loading is actually bootable? I don't want users to do qemu-system-s390x -kernel vmlinux and see it just plain fail. Alex
On 07/09/11 13:56, Alexander Graf wrote: > > On 06.09.2011, at 13:41, Christian Borntraeger wrote: > >> Alex, >> >> Newer kernels will not always have a 0dd0 (basr 13,0) at address 0x10000. >> (e.g. current linux-next). We must not rely on specific code at certain >> addresses, so lets just remove this check. > > Is there any other sane way we can find out if the image we're loading is > actually bootable? I don't want users to do qemu-system-s390x -kernel > vmlinux and see it just plain fail. No, in theory it could change arbitrarily. The vmlinux case is unfortunate but in the end its "shoot yourself in the foot", we just have to make sure that we allow a graceful exit from a looping qemu guest. Christian
On 07.09.2011, at 14:33, Christian Borntraeger wrote: > On 07/09/11 13:56, Alexander Graf wrote: >> >> On 06.09.2011, at 13:41, Christian Borntraeger wrote: >> >>> Alex, >>> >>> Newer kernels will not always have a 0dd0 (basr 13,0) at address 0x10000. >>> (e.g. current linux-next). We must not rely on specific code at certain >>> addresses, so lets just remove this check. >> >> Is there any other sane way we can find out if the image we're loading is >> actually bootable? I don't want users to do qemu-system-s390x -kernel >> vmlinux and see it just plain fail. > > No, in theory it could change arbitrarily. The vmlinux case is unfortunate > but in the end its "shoot yourself in the foot", we just have to make sure > that we allow a graceful exit from a looping qemu guest. That's not the answer I'd like to hear. Can't we put a magic constant somewhere for newer kernel versions that would identify those and keep the basr 13,0 hack around for older ones? Alex
On 07/09/11 14:34, Alexander Graf wrote: >> No, in theory it could change arbitrarily. The vmlinux case is unfortunate >> but in the end its "shoot yourself in the foot", we just have to make sure >> that we allow a graceful exit from a looping qemu guest. > > That's not the answer I'd like to hear. Can't we put a magic constant somewhere >for newer kernel versions that would identify those and keep the basr 13,0 hack > around for older ones? I will wire up the elf loader for s390, to make vmlinux simply work. That should make the test no longer needed. There are some small problems left, e.g. the elf loader loads the kernel as bios afterwards and therefore overwrites the kernel parameter line. Will fix this in the next days. Christian
Index: b/hw/s390-virtio.c =================================================================== --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -193,11 +193,6 @@ static void s390_init(ram_addr_t my_ram_ if (kernel_filename) { kernel_size = load_image(kernel_filename, qemu_get_ram_ptr(0)); - if (lduw_be_phys(KERN_IMAGE_START) != 0x0dd0) { - fprintf(stderr, "Specified image is not an s390 boot image\n"); - exit(1); - } - env->psw.addr = KERN_IMAGE_START; env->psw.mask = 0x0000000180000000ULL; } else {
Alex, Newer kernels will not always have a 0dd0 (basr 13,0) at address 0x10000. (e.g. current linux-next). We must not rely on specific code at certain addresses, so lets just remove this check. Reported-by: Philipp Muens <programming.philipp.muens@googlemail.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- hw/s390-virtio.c | 5 ----- 1 file changed, 5 deletions(-)