From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50401 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PS4KB-0005Bq-Ub for qemu-devel@nongnu.org; Mon, 13 Dec 2010 04:04:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PS4KA-0005C0-Jt for qemu-devel@nongnu.org; Mon, 13 Dec 2010 04:04:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PS4KA-0005Bu-BP for qemu-devel@nongnu.org; Mon, 13 Dec 2010 04:04:02 -0500 Date: Mon, 13 Dec 2010 11:03:59 +0200 From: Gleb Natapov Message-ID: <20101213090359.GA15610@redhat.com> References: <20101208170858.GA10056@amt.cnet> <4D032AB2.6080201@redhat.com> <20101213000017.GA8265@amt.cnet> <4D05DC35.8030009@redhat.com> <20101213084932.GZ15610@redhat.com> <4D05DEF3.60608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D05DEF3.60608@redhat.com> Subject: [Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Marcelo Tosatti , seabios@seabios.org, qemu-devel@nongnu.org On Mon, Dec 13, 2010 at 10:53:07AM +0200, Avi Kivity wrote: > On 12/13/2010 10:49 AM, Gleb Natapov wrote: > >On Mon, Dec 13, 2010 at 10:41:25AM +0200, Avi Kivity wrote: > >> On 12/13/2010 02:00 AM, Marcelo Tosatti wrote: > >> >On Sat, Dec 11, 2010 at 09:39:30AM +0200, Avi Kivity wrote: > >> >> On 12/08/2010 07:08 PM, Marcelo Tosatti wrote: > >> >> >Use _RMV method to indicate whether device can be removed. > >> >> > > >> >> >Data is retrieved from QEMU via I/O port 0xae0c. > >> >> > > >> >> > >> >> Where did this port come from? > >> > > >> >Its the next available address after "PCI EJ base", used > >> >for QEMU<->ACPI hotplug communication. > >> > > >> >> What's the protocol? > >> > > >> >ACPI reads the 32-bit field indicating the return value of the _RMV > >> >method (which is used by Windows to decide removability). 1-bit per > >> >slot. > >> > > >> >More ports have to be registered if more buses are added. > >> > > >> >> Maybe we should do this via fw_cfg. > >> > > >> >I don't see a need for it? (yes, it might be possible, but i'm not > >> >familiar enough with AML). > >> > >> To avoid adding tons of undocumented I/O ports, and to allow > >> discoverability (what happens with a new seabios on old qemu)? > >> > >We already have out own mini pci hot-plug controller at io port 0xae00. > >The patch just extends its functionality a bit. Logically this > >functionality belongs there. > > Well, at least it should be documented. > Agree. > We could also deprecate the old port and use fwcfg for everything > (try fwcfg, fall back to ae00). > fwcfg designed to be simple for easy use by firmware. It has two port one for index another for value, so its use is racy in multi-threaded SMP environment. DSDT code is executed in such environment. There is lock facility in AML, but why complicate things. > >> We could do this in two ways: by adding a fwcfg client to the DSDT, > >> or by copying the information to system memory, and referencing > >> system memory from the DSDT. > >> > >This is even worse. It requires some fixed address to be shared between > >DSDT and Seabios (or alternatively Seabios will have to generate this > >part of DSDT dynamically). > > > > Could easily be something in the F segment. > Yes, but then we will have two magic values (fwcfg index + address in F segment) instead of one (address of pci hot-plug controller). -- Gleb.