On 12/16/13 22:59, Igor Mammedov wrote: > On Mon, 16 Dec 2013 22:44:46 +0100 > Laszlo Ersek <ler...@redhat.com> wrote: > >> On 12/16/13 21:38, Igor Mammedov wrote: >>> On Mon, 16 Dec 2013 21:30:14 +0200 >>> "Michael S. Tsirkin" <m...@redhat.com> wrote: >>> >>>> On Fri, Dec 13, 2013 at 05:22:14PM +0100, Igor Mammedov wrote: >>>>> .. and report range used by it to OSPM via _CRS. >>>>> PRST is needed in SSDT since its base will depend on >>>>> chipset and will be dynamically set by QEMU. >>>>> Also move PRSC() method along with PRST since cross >>>>> table reference to PRST doesn't work. >>>> >>>> Could you clarify this last sentence? >>>> I don't mind where it is but I'd like to know >>>> where does the limitation come from. >>> It's empiric deduction so far I haven't found such limitation in spec yet. >>> iasl builds tables just fine but neither linux nor windows were able to find >>> Operation region from SSDT when loading DSDT, failing whole table loading >>> process. Decompiling DSDT/SSDT tables in guest shows that region is in >>> expected scope but OSPM refuses to see it when referenced outside SSDT. >>> Maybe there is some AML magic to make it work, I'm not aware of. >>> The same thing I had to do for memory hotplug as well. So I've tried to play >>> nicely 2 times and I have ended up with this solution both times. >> >> Would this work? >> >> diff --git a/hw/i386/acpi-dsdt-cpu-hotplug.dsl >> b/hw/i386/acpi-dsdt-cpu-hotplug.dsl >> index 995b415..34fad66 100644 >> --- a/hw/i386/acpi-dsdt-cpu-hotplug.dsl >> +++ b/hw/i386/acpi-dsdt-cpu-hotplug.dsl >> @@ -52,8 +52,8 @@ Scope(\_SB) { >> Sleep(200) >> } >> >> - OperationRegion(PRST, SystemIO, 0xaf00, 32) >> - Field(PRST, ByteAcc, NoLock, Preserve) { >> + External(\_SB.CPHD.PRST, OpRegionObj) >> + Field(\_SB.CPHD.PRST, ByteAcc, NoLock, Preserve) { > that was my first patch attempt :) > You have to be careful and touch [q35-]acpi-dsdt.dsl since make doesn't > handle deps to acpi-dsdt-cpu-hotplug.dsl correctly.
Yeah I think I noticed from the "make" output :) I grepped it for this file's name. > After that RHEL6 guest fails to load ACPI tables. Could even be an ACPICA problem... Thanks! Laszlo