qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only s


From: Ross Philipson
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching
Date: Fri, 9 May 2014 11:48:09 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0

On 05/09/2014 10:46 AM, Ian Campbell wrote:
On Fri, 2014-05-09 at 10:38 -0400, Ross Philipson wrote:
Can it be used to patch the DSDT? Or were you (Ian) thinking that the bulk
of the ACPI PCI stuff can be moved there ?

I think it can "shadow" or extend existing DSDT stuff, I don't think it
can patch as sych. But here we want to dynamically add an entire method
I think? (or hide, but I don't think that is possible).

Yea the SSDTs extend the DSDT. The DSDT is loaded to create the name
space and then SSDTs are loaded and added to the name space. If you need
to make runtime modifications like this, it is much easier to do it in
an SSDT as you suggest. What I don't know is whether you could extend
say a device, as in this case, with with a single method in a separate
SSDT. I have never really seen something like that before.

So it could be used by having two template SSDTs (one for ejectable, one
for not) and outputting the correct ones as necessary?

Yea you can have any combination of SSDTs. You could select the ones you want at build time or can also make decisions at runtime on which get loaded in a guest. I don't know if you can extend an existing device described in the DSDT with additional methods in an SSDT. If you can, this would be a pretty clean way to do it IMO. If you can't, this might mean moving much more of the ASL that describes the PCI devices out of the DSDT and into SSDTs.


WRT to hide vs. remove, I believe the intent is to effectively remove
the eject method from a given device by renaming it. It could simply be
removed making the device not eject-able but I think they are trying to
avoid having to recalculate and update the checksum on the DSDT.

How does one make the device be not eject-able? I thought it was via the
presence or absence of _EJ0 (hence the renaming hack).

By not have any _EJx methods. In this case, removing _EJ0 says the device does not support hot removal. Renaming it is effectively removing it since the OSPM would have no idea what the renamed method is. I am guessing but it seems reasonable they went for the rename option because a. they would have to strip out the whole method which would be hard and b. they would then need to rerun a checksum on the DSDT and update it.


As to whether this has to be done at runtime, I don't know. If it does,
I wrote a lib that can generate basically any (rev2) AML on the fly. We
used it e.g. to generate WMI functionality in an SSDT at runtime. I
would be happy to share if it is useful.

Thanks. hvmloader seems to generate various bits on the fly based on
basic templates already, although perhaps those cases are simpler than
this one.

Ian.


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14



--
Ross Philipson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]