qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/4] pc: append ssdt-misc.dsl to the DSDT


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v2 1/4] pc: append ssdt-misc.dsl to the DSDT
Date: Mon, 19 Jan 2015 18:14:27 +0100

On Mon, 19 Jan 2015 16:41:26 +0100
Paolo Bonzini <address@hidden> wrote:

> 
> 
> On 19/01/2015 16:15, Igor Mammedov wrote:
> > On Wed, 24 Dec 2014 17:07:35 +0100
> > Paolo Bonzini <address@hidden> wrote:
> > 
> >> This part of the ACPI tables can vary in size across machine types, but
> > s/machine types/QEMU versions/ since it doesn't change its size on machine
> > type.
> 
> Right.
> 
> >> does not depend on the command-line.  It is an SSDT just because it is
> > s/does not/its size does not/
> 
> Right.
> 
> >> the same for i440fx and Q35, and making it an SSDT made the code a bit
> > it's in SSDT because we are patching its values and DSDT were supposed
> > to stay static (not only size but contents also).
> > I'd prefer to keep dynamic part in SSDT to maintain the same separation
> > for now.
> 
> The DSDT is being patched anyway for the SMC.  So "the DSDT is dynamic,
> the SSDT is static" is not something that happens anyway.  The truth is
> "the SSDT (apart from ssdt-misc) defines Devices each of which comes
> from a template".  This patch removes the "apart from ssdt-misc" part,
> and also moves the patching of the SMC out of the per-machine-type AML,
> since it is shared anyway.
I'm fine with moving "SMC out of the per-machine-type AML", should be
a separate patch anyway. But patch-able SMC being in DSDT is our mistake
that we allowed it to slip there and should be better moved to SSDT rather
than staying in DSDT and making thing more complex.
It's also candidate for trimming, i.e. dropping it from tables altogether
if device is not present in QEMU, same applies to _S[34] Packages when
respective features are disabled and to PEVT device template.

> 
> >> simpler.  However, it also complicates backwards compatibility, so
> >> merge it with the DSDT.
> > What are these complications?
> 
> The complication arises if we want to make the SSDT exactly the same for
> all QEMU versions, given a (machine type, command line) pair.  Then you
> either cannot do any change to ssdt-misc, or you have to keep different
> copies for each machine type.
With resizable ROM blobs in master, there shouldn't be an issue with
migration in new QEMU versions if size of SSDT changes.
So question is if we still need SSDT version-ing and per machine type
SSDT compatibility? /it's better not to do version-ing at all if it could
be avoided, due to maintenance headache it brings along/


PS:
could you split binary/hex blobs update in separate patch(s), to simplify
review/testing of series.

> 
> Paolo




reply via email to

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