From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 0/4] acpi: fix up EJ0 in DSDT Date: Thu, 22 Sep 2011 09:09:49 +0300 Message-ID: <20110922060948.GA29819@redhat.com> References: <20110922043513.GA488@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Amos Kong , seabios@seabios.org, Gleb Natapov , kvm@vger.kernel.org, jasowang@redhat.com, alex williamson , Marcelo Tosatti To: "Kevin O'Connor" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10898 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390Ab1IVGI6 (ORCPT ); Thu, 22 Sep 2011 02:08:58 -0400 Content-Disposition: inline In-Reply-To: <20110922043513.GA488@morn.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote: > On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote: > > The reason is that our acpi tables declare both _RMV with value 0, > > and _EJ0 method for these slots. What happens in this case > > is undocumented by ACPI spec, so linux ignores _RMV, > > and windows seems to ignore _EJ0. > > Could the DSDT just not define _EJ0 for device 1 & 2 instead of > dynamically patching them? (Would there ever be a case where we > wouldn't know at compile time which devices need _EJ0?) Yes. in qemu we can make any slot non hotpluggable on command line by requesting a non hotpluggable device be put there. > > The correct way to suppress hotplug is not to have _EJ0, > > so this is what this patch does: it probes PIIX and > > modifies DSDT to match. > > The code to generate basic SSDT code isn't that difficult (see > build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to > patch the DSDT versus just generating the necessary blocks in an SSDT? > > -Kevin I don't really care whether the code is in DSDT or SSDT, IMO there isn't much difference between build_ssdt and patching: main reason is build_ssdt uses offsets hardcoded to a specific binary (ssdt_proc and SD_OFFSET_* ) while I used a script to extract offsets. I think we should avoid relying on copy-pasted binary because I see the related ASL code changing in the near future (with multifunction and bridge support among others). I can generalize the approach though, so that it can work for finding arbitrary names without writing more scripts, hopefully with the potential to address the hard-coded offsets in acpi.c as well. Does that sound interesting? -- MST