Re: [SeaBIOS] NVDIMM and SeaBIOS

[Marc Marí]

On Mon, 27 Jul 2015 21:40:59 -0400
"Kevin O'Connor" <kevin(a)koconnor.net> wrote:

  On Mon, Jul 27, 2015 at 05:13:52PM +0200, Marc Marí
wrote:
  Hi again
 
 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 [1], 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?

 [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/137514
 
 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/Docume…

  It would be great if we could go on-list with this
discussion.
Added the NVDIMM link again and CC'd list.

Thanks
Marc