From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyIP9-0002TJ-To for qemu-devel@nongnu.org; Fri, 29 May 2015 07:24:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyIP6-0000UZ-Ne for qemu-devel@nongnu.org; Fri, 29 May 2015 07:24:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyIP6-0000UO-Is for qemu-devel@nongnu.org; Fri, 29 May 2015 07:24:44 -0400 Date: Fri, 29 May 2015 13:24:40 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150529112436.GA11629@potion.brq.redhat.com> References: <1432744157-13798-1-git-send-email-rkrcmar@redhat.com> <20150529105155.22255ce9@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150529105155.22255ce9@nial.brq.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] pc: acpi: keep pvpanic backward compatible List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: pbonzini@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, rth@twiddle.net 2015-05-29 10:51+0200, Igor Mammedov: > On Wed, 27 May 2015 18:29:17 +0200 > Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > In the old times, we always had pvpanic in ACPI and a _STA function t= old > > the guest not to use it. Now, we only include pvpanic in ACPI if it = is > > enabled, so the _STA function is useless from qemu's point of view, b= ut > > guests still want to query availability. Make them happy. > maybe also fix guest's driver not to do since absence of _STA > implies that device is present according to ACPI6.0 6.3.7 _STA Will do. > or only fix driver and drop this patch so that QEMU wouldn't carry > useless junk. I think we still want to run old guests on new versions of QEMU. We could have kept the incremented _HID otherwise, it would be better. > > (Why Linux does '& 0xb' on this result is completely beyond me.) > check _STA related comment in SMC (Time to actually open the spec ...) > > + method =3D aml_method("_STA", 0); > > + aml_append(method, aml_return(aml_int(0xf))); > > + aml_append(dev, method); > doesn't have to be method, >=20 > make it like this: > /* device present, functioning, decoding, not shown in UI */ > aml_append(dev, aml_name_decl("_STA", aml_int(0xB))); Nice, I didn't expect that much from the evaluator. Thank you for all the information. (v2 coming after I read few hundred pages.)