On Sun, May 20, 2012 at 05:34:56PM +0300, Avi Kivity wrote:
On 05/20/2012 04:57 PM, Gleb Natapov wrote:
On Sun, May 20, 2012 at 04:39:01PM +0300, Avi Kivity wrote:
On 05/20/2012 03:59 PM, Gleb Natapov wrote:
> > > > > > Do we actually have to patch the DSDT? Or can _S3 etc be made into > > > functions instead? (and talk to the bios, or even to fwcfg directly?) > > > > > We better not talk to fwcfg after OSPM is started since this is firmware > > confing interface. > > Why not? The OS isn't going to talk to it, so we can have a driver in ACPI. > The OS is going to talk to it since the OS is the one who interprets AML.
I meant, not directly. So the driver in ACPI has exclusive access.
What's the difference?
ACPI is firmware, not OS.
AML is a data provided by firmware. AML's runtime is different from firmware's.
It's still firmware.
We have to agree to disagree here :) It's just a data for OS to use as far as I am concern.
It's an alternative to patching AML. Sure it takes some effort to write the driver, but afterwards we can modify the guest behaviour more easily. One possible client is -M old, so you can revert to previous behaviour depending on fwcfg data.
-M old is easy to support with the current patch. You just set new properties to compatibility values. The code is written with this in mind. And this is not an alternative to patching AML as I am trying to explain to you below. You can eliminate patching of s4 value, but that's it, you still need to patch out _S3/_S4 names.
What about
If (Fcfg(...)) { Method()... }
?
syntax error, unexpected PARSEOP_IF
Unfortunately the ACPI spec forbids this construct, so either patching or double complication is necessary.
It's not double if we will take all possible combinations into account.
(i.e.. define the method conditionally at runtime)
(we don't need a driver in AML to avoid patching, we can have AML talk to the bios and the bios drive fwcfg; but I think we'll find uses for a driver).
I am not sure what you mean. AML can't talk to the bios. It can read values that bios put somewhere.
That's what I meant - communicate through memory.
What's the benefit? The patching is still needed. You need to pass address of OperationRegion() to AML. You can do it either by patching or by creating OperationRegion() code dynamically.
Or it can be a fixed address in low memory, or a scratch register in hardware.
Both will work (fixed addresses are better be avoided and who needs another PV device), but I do not see how either of them is better then patching. What is your concern?
I do not see advantage of this method and it requires patching still.
For the existence of the names? Yes, if we can't avoid it it's a problem. But if we can avoid patching, we should.
If we can, we should, but we can't as far as I see. The patching was here long before this patch.
I agree we probably can't.
-- error compiling committee.c: too many arguments to function
-- Gleb.