From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDI1V-0002Jh-3T for qemu-devel@nongnu.org; Mon, 19 Jan 2015 14:30:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDI1R-0005Qo-Se for qemu-devel@nongnu.org; Mon, 19 Jan 2015 14:30:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDI1R-0005P0-Ke for qemu-devel@nongnu.org; Mon, 19 Jan 2015 14:30:01 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0JJU02V012328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 19 Jan 2015 14:30:00 -0500 Date: Mon, 19 Jan 2015 21:29:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150119192957.GA8544@redhat.com> References: <1419437261-21113-1-git-send-email-pbonzini@redhat.com> <1419437261-21113-2-git-send-email-pbonzini@redhat.com> <20150119161549.0a4162f3@nial.brq.redhat.com> <54BD25A6.9010502@redhat.com> <20150119181427.30cc7736@nial.brq.redhat.com> <54BD3E5F.4050509@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BD3E5F.4050509@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 1/4] pc: append ssdt-misc.dsl to the DSDT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Igor Mammedov , qemu-devel@nongnu.org, dgilbert@redhat.com On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote: > > > 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), Yes - for new machine types I'll send a patch to put it in memory. For old ones - there's a race, and it's painful to fix. If we do want to try fixing it, one solution is to fail migration if attempted before rsdp is shadowed. Useful? > 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). I don't have a strong opinion here. you guys arrive at a rough consensus.:w > > 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