Re: [Qemu-devel] [PATCH v3 for-2.3 10/24] hw/apci: add _PRT method for extra PCI root busses

[Marcel Apfelbaum]

On 03/08/2015 05:27 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 08, 2015 at 05:22:43PM +0200, Marcel Apfelbaum wrote:
> > On 03/08/2015 04:47 PM, Michael S. Tsirkin wrote:
> > > On Sun, Mar 08, 2015 at 01:04:07PM +0200, Marcel Apfelbaum wrote:
> > > > On 03/08/2015 12:46 PM, Michael S. Tsirkin wrote:
> > > > > On Thu, Mar 05, 2015 at 04:55:08PM +0200, Marcel Apfelbaum wrote:
> > > > > > Signed-off-by: Marcel Apfelbaum <address@hidden>
> > > > >
> > > > > some ideas for cleaning this up.
> > > > > there's more here btw.
> > > > >
> > > > > > ---
> > > > > >   hw/i386/acpi-build.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > > >   1 file changed, 78 insertions(+)
> > > > > >
> > > > > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > > > > > index e5709e8..f0401d2 100644
> > > > > > --- a/hw/i386/acpi-build.c
> > > > > > +++ b/hw/i386/acpi-build.c
> > > > > > @@ -664,6 +664,83 @@ static void build_append_pci_bus_devices(Aml 
> > > > > > *parent_scope, PCIBus *bus,
> > > > > >       aml_append(parent_scope, method);
> > > > > >   }
> > > > > >
> > > > > > +static Aml *build_prt(void)
> > > > > > +{
> > > > > > +    Aml *method, *pkg, *if_ctx, *while_ctx;
> > > > > > +
> > > > > > +    method = aml_method("_PRT", 0);
> > > > > > +
> > > > > > +    aml_append(method, aml_store(aml_package(128), aml_local(0)));
> > > > > > +    aml_append(method, aml_store(aml_int(0), aml_local(1)));
> > > > > > +    while_ctx = aml_while(aml_lless(aml_local(1), aml_int(128)));
> > > > > > +    {
> > > > > > +        aml_append(while_ctx,
> > > > > > +            aml_store(aml_shiftright(aml_local(1), aml_int(2)), aml_local(2)));
> > > > > > +        aml_append(while_ctx,
> > > > > > +            aml_store(aml_and(aml_add(aml_local(1), aml_local(2)), aml_int(3)),
> > > > > > +                      aml_local(3)));
> > > > >
> > > > >
> > > > > As an example, you can have
> > > > >
> > > > > Aml *i = aml_local(1);
> > > > > Aml *mask = aml_local(2);
> > > > Hi Michael,
> > > >
> > > > Thank you for the tip, the implementation is ready
> > > > and I'll submit it right away.
> > >
> > > So, one thing that's problematic here is that
> > > expected files need to be examined manually.
> > Only if pxb-device is added, otherwise they remain the same.
> > So by default, make check remains unchanged.
> > > How about a three-stage approach:
> > >
> > > 1. move _PRT out from DSDT - e.g. to a separate ssdt,
> > >     update expected files.
> > >     One way to do this is to first revert
> > >         commit 4ec8d2b3f54dd1dcd9e2a80e529feff4e2603288
> > >         Author: Igor Mammedov <address@hidden>
> > >             pc: acpi-build: drop remaining ssdt_misc template
> > > 2. rewrite  the new SSDT in C,
> > >     produce an otherwise identical code.
> > >     make check will catch errors
> > > 3. reuse code from (2) for extra roots.
> >
> > I am aware of this and I was planning to do that on top of this series.
> > Four reasons for this:
> >   1. As stated before, it does not affect make check because this code
> >      affects the ACPI table only if pxb-device is present.
> >   2. The _PRT is not *exactly* the same, bus 0's _PRT has an extra "if" for
> >      the power-management device than needs needs SCI
> >   3. The series is already big, I prefer attacking this as a new enhancement:
> >      "Dynamically create bus 0 _PRT"
> >   4. QEMU 2.3 is approaching, I don't want o diverge now
> >
> >
> > Thanks,
> > Marcel
>
> Meanwhile 2.3 will have two almost identical copies of _PRT?
> I don't think that's a good idea.
The are 2 *different*  _PRTs for 2 different hw components.
The look the same only because I *preferred* them to look almost the same,
I could implement it differently.
There is actually nothing common about
1. PIIX host bridge _PRT implemented statically
2. pcb-device _PRT implemented in code.

What is true is the series makes easier to implement dynamic _PRT
for any device, including PIIX host bridge. It doesn't mean we have two.

Actually we need to think about using the same code, because changing it
would influence both devices.

I really don't think they are related.
Thanks,
Marcel


> > >
[...]