[SeaBIOS] NVDIMM and SeaBIOS

[Marc Marí]

On Mon, 27 Jul 2015 21:40:59 -0400
"Kevin O'Connor" <kevin at 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/Documentation/x86/boot.txt

> It would be great if we could go on-list with this discussion.
> 

Added the NVDIMM link again and CC'd list.

Thanks
Marc