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 09:25 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 09, 2014 at 11:26:35AM +0100, Ian Campbell wrote:
> > On Fri, 2014-05-09 at 10:15 +0000, Gonglei (Arei) wrote:
> > > Hi, 
> > > 
> > > First, please forgive me for my bad English.
> > > It's so sad.
> > > 
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > > > Sent: Friday, May 09, 2014 5:57 PM
> > > > To: Gonglei (Arei)
> > > > Cc: Jan Beulich; xen-devel@xxxxxxxxxxxxx; anthony.perard@xxxxxxxxxx;
> > > > stefano.stabellini@xxxxxxxxxxxxx; johannes.krampf@xxxxxxxxxxxxxx; Gaowei
> > > > (UVP); Hanweidong (Randy); Huangweidong (C); kevin@xxxxxxxxxxxx;
> > > > fabio.fantoni@xxxxxxx; qemu-devel@xxxxxxxxxx; mst@xxxxxxxxxx
> > > > Subject: Re: [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 
> > > > methods
> > > > for PCIslots that support hotplug by runtime patching
> > > > 
> > > > On Fri, 2014-05-09 at 09:45 +0000, Gonglei (Arei) wrote:
> > > > > > And it also seem pretty pointless to send a v4 without addressing
> > > > > > all comments you got on v3.
> > > > > >
> > > > > I don't think so. I have absorbed Ian's all suggestion on v3. And for 
> > > > > other
> > > > > questions have been answered too, in despite of is me or not.
> > > > 
> > > > Actually you haven't answered "Why is runtime patching the only
> > > > option here?" which was originally phrased as:
> > > > > > Which appears to involve an awful lot of jumping through hoops... 
> > > > > > Please
> > > > > > can you explain why it is necessary, as opposed to e.g. using a 
> > > > > > dynamic
> > > > > > set of SSDTs?
> > > > 
> > > Ian, I understand your mean now, which consider our method to address 
> > > this issue is maybe unnecessary, right? And you suggest us to use a 
> > > dynamic 
> > > set of SSDTs.
> > 
> > Really what I'm asking is what set of constraints and requirements led
> > you to this particular solution.
> > 
> > I think the method seems complicated, and I'd therefore like to know why
> > it was preferred over other alternatives, or perhaps why it is the only
> > option.
> > 
> > > TBH I don't know more about the dynamic SSDTs, if you have any details, 
> > > tell me please, thanks in advance!
> > 
> > I'm not an ACPI expert, but AIUI an SSDT is essentially a little piece
> > of DSDT which is grafted onto the main DSDT at runtime by the OSPM. They
> > make it somewhat easier for BIOS (or ACPI table) authors to include or
> > exclude functionality at runtime, perhaps on a physical system in
> > response to a user changing something in the BIOS setup screens. In Xen
> > we appear to use SSDTs for HPET, TPM and S3/S4 functionality, depending
> > on the guest configuration
> > (hvmloader/acpi/build.c:construct_secondary_tables()).
> 
> 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).
        
> How would this work with the 'secondary emulator' patches that
> do all of this PCI hotplug in the hypervisor?

It should just mean that the magic I/O port protocol becomes backed by
Xen, although now you mentioned it I suppose it will be necessary for
Xen to know the answer now ;-)

> (CC-ing the author
> of said patches).

 I thought I did earlier, perhaps I forgot or changed my mind.

Ian.


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