Investigate exposing coreboot tables through sysfs for x86 (so kexec to xen can expose them to dom0 for cbmem)
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 1.6k
- Forks
- 211
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 6
Description
From https://matrix.to/#/!WtRrlYUTHOQjqGcSnn:invisiblethingslab.com/$zJFI4O_26wjlsNvQ-DybW3vpTsoJet5m8j7Y4ffqXuQ?via=invisiblethingslab.com&via=matrix.org&via=nitro.chat
@krystian-hebel said:
> I've added exposing CBMEM (i.e. memory region) as sysfs files for PPC64 in https://github.com/linuxboot/heads/blob/master/patches/linux-5.5-openpower/0011-drivers-firmware-google-expose-CBMEM-as-sysfs-file.patch, it may work on x86 after CBMEM is added as a resource to ACPI table on coreboot side. IIUC Xen passes ACPI to dom0, and the full coreboot tables are mapped there, so in theory this should work
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with patches/linux-5.5-openpower/0011-drivers-firmware-google-expose-CBMEM-as-sysfs-file.patch and trace how CBMEM is exposed through sysfs. Investigate the x86 coreboot tables, ACPI resource, and Xen dom0 path described in the issue. Done means documenting a concrete implementation path or a blocker for exposing the tables to dom0 for cbmem.
Written by the indexing model from the issue text.
Assessment
- Domain
- operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100