On Tue, Dec 11, 2012 at 09:33:21AM +0100, Alexander Graf wrote:
(1) as suggested add a special detection register to our applesmc emulation.
This means we are different than real hw.
(2) find a spare bit in q35, next to the present bits for serial/parallel/floppy
Which means we differ from real hw -> bad.
(osx wouldn't boot on piix4 anyway, so we don't have to care, right?)
It could, but you need to manually add an lpc device. I don't think we really care about the piix4 case though :).
(3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
Why if accessing fw_cfg harder than accessing the applesmc? Poking fw_cfg pios rather than applesmc pios shouldn't be an issue, right? After all, fw_cfg's purpose in life is to tell us details about the device model we can't easily find out otherwise.
Normally, hardware either comes with an SMC or it doesn't. Therefore "real" SMC._STA() methods can get away with hardcoding a "return 0xB", or else they wouldn't be there to begin with :)
From this conversation it's becomming more and more clear to me that
inserting a SMC node into the SeaBIOS DSDT at VM creation time would be a lot more hacky and difficult than compiling it in permanently.
If we agree on this much, then a SeaBIOS SMC._STA() method would necessarily have to do some detection (since on QEMU '-device applesmc' is optional, and unlike on real hardware, we don't know if it's there until after the VM has started).
If I'm still on the right track so far, then it boils down to fw_cfg vs. a QemuSMC-specific "magic port".
The latter is dead simple to pull off :) but I see Alex's point about how that potentially exposes functionality that no OS would expect of a real AppleSMC (not that any real OS has any business poking any other ports besides 0x300 or 0x304). And we're talking read-only detection, definitely NOT writing anything to any I/O port(s) :)
I'll have another look at fw_cfg, and try to get a better idea of how much additional work that'd be...
What do you guys think ?
--Gabriel