On Mon, 27 Jul 2015 21:40:59 -0400 "Kevin O'Connor" email@example.com wrote:
On Mon, Jul 27, 2015 at 05:13:52PM +0200, Marc Marí wrote:
Another way to speed up boot times we are looking at is using Intel's new PMEM, based on NVDIMMs (non-volatile DIMMs). These are discoverable through ACPI tables and mapped in the address space (they can also be used as a block device). Intel already implemented the emulation for QEMU , and we think it might be even faster than QEMU's pflash.
This generates a new problem: this new device is mapped above 4G. This means, the zone cannot be accessed directly by 32 bits SeaBIOS. There are some solutions to this problem. The ones I've read about are:
- Do some magic with paging
- Enable 64 bit long mode
Which do you think is the best way to proceed, at least for the sake of testing this PMEM?
From a wider point of view: do you think it's worth to move (all or some part) of SeaBIOS to 64 bits?
I don't think it would make sense to convert all of SeaBIOS to 64bit as SeaBIOS still needs to be able to run in 16bit and 32bit mode. So, it would be an extra mode.
I suspect to add something like this it would be easiest to just have a kernel booting shim that used 64bit mode or setup paging.
Yes, that seems the most sensible option. A link about implementation: http://wiki.osdev.org/Setting_Up_Long_Mode
If there are no more ideas, I'll be working on it for the next weeks. Any suggestions/tips/other about x86 or how to do it are appreciated.
Note that if it's defined in the ACPI DSDT, then it could be a real pain to parse. The DSDT is it's own interpreted language.
It is not defined in the ACPI DSDT. It is a new ACPI table (ACPI version 6, NFIT table). I've already been able to read and parse that table from SeaBIOS.
Also, if the kernel has to be copied to a memory location, then I would be surprised that DMA fw_cfg would be slower than a PMEM solution. Ultimately, I would think that QEMU could copy the kernel to ram as fast or faster than the guest could.
Another thing that I have in my bucket of things to try is booting Linux directly in 32 bit or 64 bit mode. If the kernel is boot in 64 bit mode directly, the image can be mapped anywhere, including above 4G. This avoids copying, and some 16 bit mode things. But that's not the intention at this precise moment. It might be the next step.
At the end of: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen...
It would be great if we could go on-list with this discussion.
Added the NVDIMM link again and CC'd list.