From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: About hotplug multifunction Date: Sun, 11 Sep 2011 21:51:06 +0300 Message-ID: <20110911185106.GA4740@redhat.com> References: <1749303074.590739.1315551830460.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <1466280941.590770.1315552101666.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <20110909073226.GB5593@redhat.com> <1315587902.2662.19.camel@x201.home> <20110909183426.GD22662@amt.cnet> <20110911092357.GC27096@redhat.com> <20110911150149.GA28477@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, Alex Williamson , Amos Kong To: Marcelo Tosatti Return-path: Content-Disposition: inline In-Reply-To: <20110911150149.GA28477@amt.cnet> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Sun, Sep 11, 2011 at 12:01:49PM -0300, Marcelo Tosatti wrote: > On Sun, Sep 11, 2011 at 12:23:57PM +0300, Michael S. Tsirkin wrote: > > On Fri, Sep 09, 2011 at 03:34:26PM -0300, Marcelo Tosatti wrote: > > > > > something I noted when readin our acpi code: > > > > > we currently pass eject request for function 0 only: > > > > > Name (_ADR, nr##0000) > > > > > We either need a device per function there (acpi 1.0), > > > > > send eject request for them all, or use ffff > > > > > as function number (newer acpi, not sure which version). > > > > > Need to see which guests (windows,linux) can handle which form. > > > > > > > > I'd guess we need to change that to ffff. > > > > > > No need, only make sure function 0 is there and all other functions > > > should be removed automatically by the guest on eject notification. > > > > Hmm, the ACPI spec explicitly says: > > > > High word = Device #, Low word = Function #. > > (e.g., device 3, function 2 is 0x00030002). To refer > > to all the functions on a device #, use a function > > number of FFFF). > > Right, but this is the _ADR of the device instance in ACPI. > The communication between QEMU and the ACPI DSL code is all > based in slots. It's easy to extend that if we like though. > > > ACPI PCI hotplug is based on slots, not on functions. It does not > > > support addition/removal of individual functions. > > > > Interesting. Is this just based on general logic, > > reading of the linux driver or the ACPI spec? > > Its based on Seabios ACPI DST implementation and its relationship with > the QEMU implementation in acpi_piix4.c. > > > The ACPI spec itself seems pretty vague. All tables > > list devices, where each device has an _ADR entry, > > which is built up of PCI device # and function #. > > Yes, it is vague. Given the mandate from the PCI spec a device _must > contain_ function 0, usage (including hotplug/unplug) of individual > functions other than 0 as separate devices is a no-go. It doesn't seem to be a big issue. We could, for example, keep a stub function 0 around. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2p6T-0002A8-VY for qemu-devel@nongnu.org; Sun, 11 Sep 2011 14:50:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2p6S-0007VV-RK for qemu-devel@nongnu.org; Sun, 11 Sep 2011 14:50:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2p6S-0007V8-HB for qemu-devel@nongnu.org; Sun, 11 Sep 2011 14:50:04 -0400 Date: Sun, 11 Sep 2011 21:51:06 +0300 From: "Michael S. Tsirkin" Message-ID: <20110911185106.GA4740@redhat.com> References: <1749303074.590739.1315551830460.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <1466280941.590770.1315552101666.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <20110909073226.GB5593@redhat.com> <1315587902.2662.19.camel@x201.home> <20110909183426.GD22662@amt.cnet> <20110911092357.GC27096@redhat.com> <20110911150149.GA28477@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110911150149.GA28477@amt.cnet> Subject: Re: [Qemu-devel] About hotplug multifunction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, Alex Williamson , Amos Kong On Sun, Sep 11, 2011 at 12:01:49PM -0300, Marcelo Tosatti wrote: > On Sun, Sep 11, 2011 at 12:23:57PM +0300, Michael S. Tsirkin wrote: > > On Fri, Sep 09, 2011 at 03:34:26PM -0300, Marcelo Tosatti wrote: > > > > > something I noted when readin our acpi code: > > > > > we currently pass eject request for function 0 only: > > > > > Name (_ADR, nr##0000) > > > > > We either need a device per function there (acpi 1.0), > > > > > send eject request for them all, or use ffff > > > > > as function number (newer acpi, not sure which version). > > > > > Need to see which guests (windows,linux) can handle which form. > > > > > > > > I'd guess we need to change that to ffff. > > > > > > No need, only make sure function 0 is there and all other functions > > > should be removed automatically by the guest on eject notification. > > > > Hmm, the ACPI spec explicitly says: > > > > High word = Device #, Low word = Function #. > > (e.g., device 3, function 2 is 0x00030002). To refer > > to all the functions on a device #, use a function > > number of FFFF). > > Right, but this is the _ADR of the device instance in ACPI. > The communication between QEMU and the ACPI DSL code is all > based in slots. It's easy to extend that if we like though. > > > ACPI PCI hotplug is based on slots, not on functions. It does not > > > support addition/removal of individual functions. > > > > Interesting. Is this just based on general logic, > > reading of the linux driver or the ACPI spec? > > Its based on Seabios ACPI DST implementation and its relationship with > the QEMU implementation in acpi_piix4.c. > > > The ACPI spec itself seems pretty vague. All tables > > list devices, where each device has an _ADR entry, > > which is built up of PCI device # and function #. > > Yes, it is vague. Given the mandate from the PCI spec a device _must > contain_ function 0, usage (including hotplug/unplug) of individual > functions other than 0 as separate devices is a no-go. It doesn't seem to be a big issue. We could, for example, keep a stub function 0 around. -- MST