windows boot

[Sergey Kurdakov]

Hi All,

I made a search of messages in a list concerning windows boot,

found, that it is not planned to emulate UEFI.

still, regarding launching windows ( and I think it is important because windows is quite widespread operation system

and ability to launch it from linuxboot might be useful in number of  cases)

I see  two possible approaches:

1) kexec grub4dos to launch windows with legacy bootloader ( see for example

question and explanation here

http://reboot.pro/topic/7223-how-to-boot-directly-into-windows-from-kexecgrub4dos/ )

that approach seems could readily be tested with current linuxboot.

the same possibly could be done with grub2 ( turning grub executable  into elf image

 and patching other things along the lines which were implemented in grub4dos ).

It could be possible to implemented similar things in currently used u-root bootloader

2) for GPT disks kexec some emulation layer or provide UEFI interfaces which will manage to launch both

windows boot manager bootmgfw.efi  and then windows os loader winload.efi

(something like http://ipxe.org/wimboot does but providing enough information

to boot actual windows and not only installer, like http://ipxe.org/wimboot )

3) there is still a possibility to write a windows bootloader which will directly boot ntoskrnl.exe even on GPT disks, but seems even

people at ReactOS are not even close to implementing it.

basically, due to the fact, that modern computers come with uefi - and windows by design requires uefi

to start, there seems no other way than to emulate a big chunk of uefi boot functionality to work with modern windows.

now it would be nice to know what is current state of progress.

Did anyone managed to launch windows from linuxboot by any approach?

What are even remote plans to implement needed UEFI interfaces to boot current gpt x86-64 windows

or  is it  doable at all?

Regards

Sergey

[Jean-Marie Verdun]

Hi Sergey,

I don't really know your use case (client vs server), but what we have done up to now is using KVM and run windows in VMs. As to gain near hardware performances we use intensively PCIe passthrough either at full device level (for storage/gpu) or through SR-IOV (for networking) and we got some good performances out of that.

This is a complex setup I know, but at least is a workaround which works. We try to remove as much as we can from UEFI so each time I tried to load the O/S directly some UEFI services were lacking, which was boring to me especially for an O/S I am not a big fan of.

vejmarie

--
You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To post to this group, send email to linu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/85dd285d-0bb1-40c4-a90b-e74db82992a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

[Sergey Kurdakov]

Hi Jean-Marie,

I don't really know your use case (client vs server), but what we have done up to now is using KVM and run windows in VMs. As to gain near hardware performances we use intensively PCIe passthrough either at full device level (for storage/gpu) or through SR-IOV (for networking) and we got some good performances out of that.

the use case which is interesting to me is client PCs, which are set up by user.

so, fewer additional layers, the better. But I will look into VMs, thanks.

Regards

Sergey

 

[Philipp Deppenwiese]

Hey Sergey,

we thought about interfacing u-boot efi runtime binary.
In combination with kexec PE file support.
Currently it is WIP so it can take a while until we support a
UEFI boot interface.

BR, Zaolin

--

You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To post to this group, send email to linu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/bdb4fc1e-a416-44a1-8afe-122837a84160%40googlegroups.com.

[ron minnich]

windows boot is on our list of things to do. It's just not a high priority atm. If someone wants to take it on that's fine.

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/d2a4d10e-3341-1afb-9995-d53c932966cd%40gmail.com.

[Sergey Kurdakov]

Hi All,

I had an old question on Windows boot a few years back.

in fact there was a progress along the lines,

https://2019.osfc.io/uploads/talk/paper/64/Booting_Windows_on_LinuxBoot.pdf

but the major stumbling block was that it was difficult to debug bootmgfw.efi and winload.efi

to streamline final steps to setup graphics.

While I did not look into details, I found (via phoronix) open sourced boot manager for windows

https://github.com/maharmstone/quibble

possibly that will make it easier to trace problems (as graphics setup code is now accessible and could be customized) and  finally have windows boot from linux available to wider developer base

Best regards

Sergey

[Ryan O'Leary]

I CC'ed some people who are working on this.

There are 3 approaches being implemented in parallel:

• https://2019.osfc.io/uploads/talk/paper/64/Booting_Windows_on_LinuxBoot.pdf
  
• LinuxBoot and the Windows bootloader run side-by-side up until the ExitBootServices.
• linuxboot/voodoo: https://github.com/linuxboot/voodoo
• The efi bootloader is run in ring 3 and all the services are faked via ptrace and implemented in Go. On ExitBootServices, all the allocated memory is passed to the kexec_load syscall. For AMD, there is a limitation of ring 3 which requires a proper VM.
• uefiboot: https://github.com/u-root/u-root/pull/1896
• A payload is built from edk2 and kexec'ed directly from Linux. edk2 then goes on to boot Windows. It differs from #1 because Linux shutdowns before starting the edk2 payload. The bootloaders do not run side-by-side. edk2 and Linux have their own district drivers.

- Ryan

--

You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/CAFVQEu3yE0cKKbEKLGP%3DxGbBKTVf1k1-%3D9sF4mcdursHTwCOdQ%40mail.gmail.com.