| Message ID | 20100819112414.GH22245@os.inf.tu-dresden.de |
|---|---|
| State | New |
| Headers | show |
On 19.08.2010, at 13:24, Adam Lackorzynski wrote: > A via -kernel supplied x86_64 ELF image is being started in 32bit mode. > Detect and exit if a 64bit image has been supplied. According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... Alex
On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: > > On 19.08.2010, at 13:24, Adam Lackorzynski wrote: > > > A via -kernel supplied x86_64 ELF image is being started in 32bit mode. > > Detect and exit if a 64bit image has been supplied. > > According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... Yes, but then the supplied ELF-image should say it's a 32bit one and switch to 64bit mode itself. That's at least how we do load a 64bit kernel. Adam
On 19.08.2010, at 13:36, Adam Lackorzynski wrote: > > On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: >> >> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: >> >>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. >>> Detect and exit if a 64bit image has been supplied. >> >> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... > > Yes, but then the supplied ELF-image should say it's a 32bit one and > switch to 64bit mode itself. That's at least how we do load a 64bit > kernel. Hrm - maybe you're right: busu:~ # readelf -a /boot/xen ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 What does the spec say here? What does grub do? Alex
On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote: > > On 19.08.2010, at 13:36, Adam Lackorzynski wrote: > > > > > On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: > >> > >> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: > >> > >>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. > >>> Detect and exit if a 64bit image has been supplied. > >> > >> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... > > > > Yes, but then the supplied ELF-image should say it's a 32bit one and > > switch to 64bit mode itself. That's at least how we do load a 64bit > > kernel. > > Hrm - maybe you're right: > > busu:~ # readelf -a /boot/xen > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 > > What does the spec say here? What does grub do? Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit mode would require to setup page-tables etc. which is not done. The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are fine ("An OS image may be an ordinary 32-bit executable file in the standard format for that particular operating system, except that it may be linked at a non-default load address to avoid loading on top of the ..."); Adam
On 19.08.2010, at 14:32, Adam Lackorzynski wrote: > > On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote: >> >> On 19.08.2010, at 13:36, Adam Lackorzynski wrote: >> >>> >>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: >>>> >>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: >>>> >>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. >>>>> Detect and exit if a 64bit image has been supplied. >>>> >>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... >>> >>> Yes, but then the supplied ELF-image should say it's a 32bit one and >>> switch to 64bit mode itself. That's at least how we do load a 64bit >>> kernel. >> >> Hrm - maybe you're right: >> >> busu:~ # readelf -a /boot/xen >> ELF Header: >> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >> Class: ELF32 >> >> What does the spec say here? What does grub do? > > Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit > mode would require to setup page-tables etc. which is not done. > The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are > fine ("An OS image may be an ordinary 32-bit executable file in the > standard format for that particular operating system, except that it may > be linked at a non-default load address to avoid loading on top of the > ..."); I think we should do the same grub does here. If grub loads 64-bit elf binaries and runs them in 32-bit mode, we should too. If it refuses to load them, we should too. Alex
On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote: > > On 19.08.2010, at 14:32, Adam Lackorzynski wrote: > > > > > On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote: > >> > >> On 19.08.2010, at 13:36, Adam Lackorzynski wrote: > >> > >>> > >>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: > >>>> > >>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: > >>>> > >>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. > >>>>> Detect and exit if a 64bit image has been supplied. > >>>> > >>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... > >>> > >>> Yes, but then the supplied ELF-image should say it's a 32bit one and > >>> switch to 64bit mode itself. That's at least how we do load a 64bit > >>> kernel. > >> > >> Hrm - maybe you're right: > >> > >> busu:~ # readelf -a /boot/xen > >> ELF Header: > >> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > >> Class: ELF32 > >> > >> What does the spec say here? What does grub do? > > > > Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit > > mode would require to setup page-tables etc. which is not done. > > The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are > > fine ("An OS image may be an ordinary 32-bit executable file in the > > standard format for that particular operating system, except that it may > > be linked at a non-default load address to avoid loading on top of the > > ..."); > > I think we should do the same grub does here. If grub loads 64-bit elf > binaries and runs them in 32-bit mode, we should too. If it refuses to > load them, we should too. grub1: grub> kernel (nd)/tftpboot/adam/bootstrap.elf Error 13: Invalid or unsupported executable format grub> grub2 loads it but then it crashes and reboots. Looks like a bug to me. Adam
On 19.08.2010, at 14:49, Adam Lackorzynski wrote: > > On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote: >> >> On 19.08.2010, at 14:32, Adam Lackorzynski wrote: >> >>> >>> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote: >>>> >>>> On 19.08.2010, at 13:36, Adam Lackorzynski wrote: >>>> >>>>> >>>>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: >>>>>> >>>>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: >>>>>> >>>>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. >>>>>>> Detect and exit if a 64bit image has been supplied. >>>>>> >>>>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... >>>>> >>>>> Yes, but then the supplied ELF-image should say it's a 32bit one and >>>>> switch to 64bit mode itself. That's at least how we do load a 64bit >>>>> kernel. >>>> >>>> Hrm - maybe you're right: >>>> >>>> busu:~ # readelf -a /boot/xen >>>> ELF Header: >>>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>>> Class: ELF32 >>>> >>>> What does the spec say here? What does grub do? >>> >>> Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit >>> mode would require to setup page-tables etc. which is not done. >>> The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are >>> fine ("An OS image may be an ordinary 32-bit executable file in the >>> standard format for that particular operating system, except that it may >>> be linked at a non-default load address to avoid loading on top of the >>> ..."); >> >> I think we should do the same grub does here. If grub loads 64-bit elf >> binaries and runs them in 32-bit mode, we should too. If it refuses to >> load them, we should too. > > grub1: > > grub> kernel (nd)/tftpboot/adam/bootstrap.elf > > Error 13: Invalid or unsupported executable format Alright. Acked-by: Alexander Graf <agraf@suse.de> Alex
On 08/19/2010 02:24 PM, Adam Lackorzynski wrote: > A via -kernel supplied x86_64 ELF image is being started in 32bit mode. > Detect and exit if a 64bit image has been supplied. > > > > diff --git a/hw/multiboot.c b/hw/multiboot.c > index dc980e6..e9dcbc9 100644 > --- a/hw/multiboot.c > +++ b/hw/multiboot.c > @@ -171,6 +171,12 @@ int load_multiboot(void *fw_cfg, > uint64_t elf_low, elf_high; > int kernel_size; > fclose(f); > + > + if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { > + fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); > + exit(1); > + } > + > kernel_size = load_elf(kernel_filename, NULL, NULL,&elf_entry, > &elf_low,&elf_high, 0, ELF_MACHINE, 0); > if (kernel_size< 0) { We rely on the existing behaviour in kvm-unit-tests.git. Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit. We can easily wrap them in a 32-bit elf, but that's a needless complication.
On 19.08.2010, at 15:02, Avi Kivity wrote: > On 08/19/2010 02:24 PM, Adam Lackorzynski wrote: >> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. >> Detect and exit if a 64bit image has been supplied. >> >> >> >> diff --git a/hw/multiboot.c b/hw/multiboot.c >> index dc980e6..e9dcbc9 100644 >> --- a/hw/multiboot.c >> +++ b/hw/multiboot.c >> @@ -171,6 +171,12 @@ int load_multiboot(void *fw_cfg, >> uint64_t elf_low, elf_high; >> int kernel_size; >> fclose(f); >> + >> + if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { >> + fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); >> + exit(1); >> + } >> + >> kernel_size = load_elf(kernel_filename, NULL, NULL,&elf_entry, >> &elf_low,&elf_high, 0, ELF_MACHINE, 0); >> if (kernel_size< 0) { > > We rely on the existing behaviour in kvm-unit-tests.git. Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit. > > We can easily wrap them in a 32-bit elf, but that's a needless complication. Well, but if they wouldn't work in grub that doesn't help too much, right? I'm in full sympathy to stick to whatever grub does, as that's the reference implementation. Alex
On 08/19/2010 04:57 PM, Alexander Graf wrote: > >> We rely on the existing behaviour in kvm-unit-tests.git. Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit. >> >> We can easily wrap them in a 32-bit elf, but that's a needless complication. > Well, but if they wouldn't work in grub that doesn't help too much, right? Since the processor vendors don't use kvm-unit-tests.git to test their silicon, most people use qemu -kernel to run the unit tests, not grub. > I'm in full sympathy to stick to whatever grub does, as that's the reference implementation. Copying reference implementations blindly is a bad idea as you just copy their bugs. In this case, however, the spec does agree with the implementation, so I'm fine with the change. I'm not so hot about the elf32 wrapper, but I accept it's the right thing.
On 19.08.2010, at 16:05, Avi Kivity wrote: > On 08/19/2010 04:57 PM, Alexander Graf wrote: >> >>> We rely on the existing behaviour in kvm-unit-tests.git. Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit. >>> >>> We can easily wrap them in a 32-bit elf, but that's a needless complication. >> Well, but if they wouldn't work in grub that doesn't help too much, right? > > Since the processor vendors don't use kvm-unit-tests.git to test their silicon, most people use qemu -kernel to run the unit tests, not grub. It would potentially also help the unit tests, as running them in grub would allow for easy verification on real hardware too. > >> I'm in full sympathy to stick to whatever grub does, as that's the reference implementation. > > Copying reference implementations blindly is a bad idea as you just copy their bugs. In this case, however, the spec does agree with the implementation, so I'm fine with the change. I'm not so hot about the elf32 wrapper, but I accept it's the right thing. :) Alex
On 08/19/2010 05:10 PM, Alexander Graf wrote: >>> >>>> We rely on the existing behaviour in kvm-unit-tests.git. Tests (.flat files) are 64-bit elf binaries that are loaded in 32-bit more and switch immediately to 64-bit. >>>> >>>> We can easily wrap them in a 32-bit elf, but that's a needless complication. >>> Well, but if they wouldn't work in grub that doesn't help too much, right? >> Since the processor vendors don't use kvm-unit-tests.git to test their silicon, most people use qemu -kernel to run the unit tests, not grub. > It would potentially also help the unit tests, as running them in grub would allow for easy verification on real hardware too. True. We need to write an INT 10 driver and a serial driver for this to work.
Hi, On Aug 19, 2010, at 2:49 PM, Adam Lackorzynski wrote: > > On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote: >> >> On 19.08.2010, at 14:32, Adam Lackorzynski wrote: >> >>> >>> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote: >>>> >>>> On 19.08.2010, at 13:36, Adam Lackorzynski wrote: >>>> >>>>> >>>>> On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote: >>>>>> >>>>>> On 19.08.2010, at 13:24, Adam Lackorzynski wrote: >>>>>> >>>>>>> A via -kernel supplied x86_64 ELF image is being started in 32bit mode. >>>>>>> Detect and exit if a 64bit image has been supplied. >>>>>> >>>>>> According to the multiboot spec, this is the expected behavior, no? At least Xen does it that way... >>>>> >>>>> Yes, but then the supplied ELF-image should say it's a 32bit one and >>>>> switch to 64bit mode itself. That's at least how we do load a 64bit >>>>> kernel. >>>> >>>> Hrm - maybe you're right: >>>> >>>> busu:~ # readelf -a /boot/xen >>>> ELF Header: >>>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>>> Class: ELF32 >>>> >>>> What does the spec say here? What does grub do? >>> >>> Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit >>> mode would require to setup page-tables etc. which is not done. >>> The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are >>> fine ("An OS image may be an ordinary 32-bit executable file in the >>> standard format for that particular operating system, except that it may >>> be linked at a non-default load address to avoid loading on top of the >>> ..."); >> >> I think we should do the same grub does here. If grub loads 64-bit elf >> binaries and runs them in 32-bit mode, we should too. If it refuses to >> load them, we should too. > > grub1: > > grub> kernel (nd)/tftpboot/adam/bootstrap.elf > > Error 13: Invalid or unsupported executable format > > grub> > > > grub2 loads it but then it crashes and reboots. Looks like a bug to me. I once added some x86_64 patch to our grub at T2. I forgot for what, L4, Luvally? At that time it worked, ... http://svn.exactcode.de/t2/trunk/package/x86/grub/grub-0.97-x86_64.patch René
diff --git a/hw/multiboot.c b/hw/multiboot.c index dc980e6..e9dcbc9 100644 --- a/hw/multiboot.c +++ b/hw/multiboot.c @@ -171,6 +171,12 @@ int load_multiboot(void *fw_cfg, uint64_t elf_low, elf_high; int kernel_size; fclose(f); + + if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { + fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); + exit(1); + } + kernel_size = load_elf(kernel_filename, NULL, NULL, &elf_entry, &elf_low, &elf_high, 0, ELF_MACHINE, 0); if (kernel_size < 0) {
A via -kernel supplied x86_64 ELF image is being started in 32bit mode. Detect and exit if a 64bit image has been supplied. Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de> --- hw/multiboot.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)