I tested the memdisk-acpi branch with following results: - Bochs The BIOS provides a RSDT. Available tables are RSDT, FACP, DSDT, FACS, APIC, SSDT. memdisk-acpi is able to hook the SSDT. - VMware The BIOS provides a RSDT and XSDT. Available tables are RSDT, FACP, DSDT(*), FACS(*), BOOT(*), APIC(*) and XSDT, FACP, DSDT(*), FACS(*), BOOT(*), APIC(*). Tables marked with an asterisk (*) are identical; FACP tables from RSDT and XSDT are different. memdisk-acpi is not able to hook. acpi_bytes_needed() from acpi.c tries to find a DSDT or SSDT. It fails to find a DSDT because RSDT doesn't point to DSDT; RSDT points to FACP which points to DSDT. After fixing this problem memdisk-acpi is able to hook the DSDT on VMware. Unfortunately it's unclear to me what we gain by hooking the DSDT/SSDT. How can we access the mBFT? Sebastian
On 11/7/2012 14:46, Sebastian Herbszt wrote:> > Unfortunately it's unclear to me what we gain by hooking the DSDT/SSDT. > How can we access the mBFT?Well under Windows, the ACPI pieces are enumerated as device nodes in the PnP device tree. Each node has a device ID provided by whoever populated the ACPI pieces. Windows then checks a couple of different areas to find out how to drive the "device." hpa obtained an ACPI vendor ID from Microsoft. Ideally, a MEMDISK could be enumerated as a device using this strategy, then a driver like WinVBlock could be registered to drive devices with those IDs. Currently, WinVBlock has create its own device, rather than more simply being requested to drive a device that was enumerated by the ACPI driver. In either case, the mBFT is accessed by reading memory. With an ACPI table, I believe the mBFT position is known. Without, it needs to be scanned-for, just like the iBFT and aBFT of iSCSI and AoE, respectively. I don't know if Linux has a similar ACPI device enumeration strategy. - Shao Miller