Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-05-09 at 16:56 +0200, Fabio Fantoni wrote:
> Il 09/05/2014 16:46, Ian Campbell ha scritto:
> > 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?
> >
> >> 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).
> >
> >> 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.
> >
> 
> I saw that newer qemu versions generate acpi tables in it.
> Can be a good idea add the acpi changes needed by xen in qemu instead 
> works on acpi tables also in hvmloader? (and perhaps even avoid 
> unexpected cases with new versions of qemu or similar)

I already responded to a similar suggestion on a previous iteration of
this patch.

> If this is a stupid idea sorry for the loss of time.
> 
> Thanks for any reply and sorry for my bad english.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel