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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 1/4] pc: append ssdt-misc.dsl to the DSDT
Date: Mon, 19 Jan 2015 18:26:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0


On 19/01/2015 18:14, Igor Mammedov wrote:
> 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.

Yes, trimming is better than putting it in the DSDT, at least for simple
devices such as SMC and pvpanic.

>> > 
>>>> > >> 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.

There is only a very small issue that remains (the RSDP pointer is wrong
if the size changes), so we probably should apply anyway the patch of
mine that allows the DSDT size to change; and we probably should pay
attention to SSDT, and version it.

("Let's just ignore the SSDT" was exactly what I feared when I disagreed
with putting in resizable ROM blobs first.  But now that it's in, I
cannot really argue otherwise).

> 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/

I'm okay with re-evaluating that after your patches go in.

Paolo



reply via email to

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