public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Thomas Preisner" <preisner@cs.fau.de>
To: devel@edk2.groups.io
Subject: [edk2-devel] Questions regarding NVDIMM and OVMF
Date: Mon, 8 Jul 2024 23:55:11 +0200	[thread overview]
Message-ID: <108b8e09-7d9f-411a-8384-1a8c0e0fcd07@cs.fau.de> (raw)

Hello,

I'm currently working on a research project with the goal to (mostly) 
replace
DRAM with NVRAM on the OS-side. In order to speed things up, I'm currenlty
trying to switch over to QEMU+OVMF instead of developing directly on 
hardware
(server boot times are a massive pain). However, I've noticed that QEMU 
only
announces the existence of nvdimm devices via ACPI's NFIT. As a result,
virtualized nvdimm devices neither appear in the E820 table nor in UEFI's
GetMemoryMap() and, e.g., Linux doesn't find it during its boot.

Hence, I've been trying to add support for QEMU's nvdimm devices to 
OVMF. For
this purpose, I identified `OvmfPkg/Library/PlatformInitLib/MemDetect.c` 
as the
most fitting location to query NFIT in order to create HOBs for the 
detected
nvdimms. However, ACPI, and therefore, NFIT is only available beginning 
with
the DXE phase while the PlatformInitLib  is executed during the PEI phase
according to my understanding.

Is there any other way to access the ACPI table during PEI phase? I would
assume it isn't (as it is loaded via QEMU's fw_cfg "table-loader" as 
part of
the DxeAcpiPlatformLib), but maybe I'm wrong and there is some way. Or 
is it
also sufficient to create respective HOBs during DXE phase? If so, 
where/when
would be the most fitting location for this addition?

In either case, are the HOBs at some point fed back into the E820 table 
(which
is still crucial for the Linux kernel)? Or are they strictly used by 
OVMF and
not passed on to the remaining system in one way or another? So far, 
I've only
found `OvmfPkg/Library/LoadLinuxLib/Linux.c:SetupLinuxMemmap()` to 
rewrite the
E820 table, but apparently this is only used by QemuLoadImageLib which 
is not
executed during a 'normal' boot. At least it wasn't for my case (tested by
simply adding an infinite loop). So either there is another location 
that I've
overlooked (any pointer is welcome!) or the E820 table is not updated
accordingly? Currently, I'm still trying to get a (proper) grasp of the 
entire
architecture/structure of the edk2 project.

Do you have any pointers for implementing the support of nvdimm in 
edk2/OVMF?
Or is it not feasible and I need to also look at adding it directly into 
QEMU
(I was hoping to avoid having to modify QEMU so far)?

Best regards,
Thomas Preisner



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119845): https://edk2.groups.io/g/devel/message/119845
Mute This Topic: https://groups.io/mt/107122508/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



             reply	other threads:[~2024-07-09 13:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-08 21:55 Thomas Preisner [this message]
2024-07-09 14:48 ` [edk2-devel] Questions regarding NVDIMM and OVMF Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=108b8e09-7d9f-411a-8384-1a8c0e0fcd07@cs.fau.de \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox