On Thu, Sep 17, 2015 at 11:30:59PM +0300, Michael S. Tsirkin wrote: > On Thu, Sep 17, 2015 at 10:56:29AM -0400, Gabriel L. Somlo wrote: > > New since v2: > > > > - pc/i386 node in ssdt only on machine types *newer* than 2.4 > > (as suggested by Eduardo) > > > > I appreciate any further comments and reviews. Hopefully we can make > > this palatable for upstream, modulo the lingering concerns about whether > > "QEMU0002" is ok to use as the value of _HID, which I'll hopefully get > > sorted out with the kernel crew... > > What I'm still missing is the motivation for the change. > > Went through old threads, still can't find it.
I've been working on a sysfs driver to allow viewing fw_cfg file metadata (size, name, etc) and content (e.g. 'raw') in something like /sys/firmware/qemu-fw-cfg/by_key/... (similar to how e.g. smbios tables can be accessed via /sys/firmware/dmi/entries/...). Motivation is that since we can insert user-defined blobs via the qemu command line, wouldn't it be nice to be able to easily retrieve them from the guest, and what's easier than "cp /sys/firmware/.../raw ..." ? One of the main requirements I got there was to avoid probing fw_cfg registers during initialization of the sysfs driver, and instead use device tree on arm (and acpi on i386) to first figure out whether fw_cfg is even expected to be there. There's a DT entry for fw_cfg on arm, but no acpi entry for fw_cfg on x86, so I decided why not add one ? It's a device, it occupies a mmio or port-io region, why not tell the guest about it via ACPI ? That's about it, in a nutshell. Thanks for any further thoughts! --Gabriel > > > >New since v1: > > > > > > - expose control register size (suggested by Marc Marí) > > > > > > - leaving out _UID and _STA fields (thanks Shannon & Igor) > > > > > > - using "QEMU0002" as the value of _HID (thanks Michael) > > > > > > - added documentation blurb to docs/specs/fw_cfg.txt > > > (mainly to record usage of the "QEMU0002" string with fw_cfg). > > > > > >> This series adds a fw_cfg device node to the SSDT (on pc), or to the > > >> DSDT (on arm). > > >> > > >> - Patch 1/3 moves (and renames) the BIOS_CFG_IOPORT (0x510) > > >> define from pc.c to pc.h, so that it could be used from > > >> acpi-build.c in patch 2/3. > > >> > > >> - Patch 2/3 adds a fw_cfg node to the pc SSDT. > > >> > > >> - Patch 3/3 adds a fw_cfg node to the arm DSDT. > > >> > > >> I made up some names - "FWCF" for the node name, and "FWCF0001" > > >> for _HID; no idea whether that's appropriate, or how else I should > > >> figure out what to use instead... > > >> > > >> Also, using scope "\\_SB", based on where fw_cfg shows up in the > > >> output of "info qtree". Again, if that's wrong, please point me in > > >> the right direction. > > >> > > >> Re. 3/3 (also mentioned after the commit blurb in the patch itself), > > >> I noticed none of the other DSDT entries contain a _STA field, wondering > > >> why it would (not) make sense to include that, same as on the PC. > > > > Gabriel L. Somlo (5): > > fw_cfg: expose control register size in fw_cfg.h > > pc: fw_cfg: move ioport base constant to pc.h > > acpi: pc: add fw_cfg device node to ssdt > > acpi: arm: add fw_cfg device node to dsdt > > fw_cfg: document ACPI device node information > > > > docs/specs/fw_cfg.txt | 9 +++++++++ > > hw/arm/virt-acpi-build.c | 13 +++++++++++++ > > hw/i386/acpi-build.c | 21 +++++++++++++++++++++ > > hw/i386/pc.c | 5 ++--- > > hw/i386/pc_piix.c | 1 + > > hw/i386/pc_q35.c | 1 + > > hw/nvram/fw_cfg.c | 8 +++++--- > > include/hw/i386/pc.h | 3 +++ > > include/hw/nvram/fw_cfg.h | 3 +++ > > 9 files changed, 58 insertions(+), 6 deletions(-) > > > > -- > > 2.4.3
