From: Marcelo Tosatti <mtosatti@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, blauwirbel@gmail.com,
yamahata@valinux.co.jp,
Alex Williamson <alex.williamson@redhat.com>,
Amos Kong <akong@redhat.com>
Subject: Re: [Qemu-devel] About hotplug multifunction
Date: Mon, 12 Sep 2011 07:21:48 -0300 [thread overview]
Message-ID: <20110912102148.GA12332@amt.cnet> (raw)
In-Reply-To: <20110911185106.GA4740@redhat.com>
On Sun, Sep 11, 2011 at 09:51:06PM +0300, Michael S. Tsirkin wrote:
> 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.
I suppose the guest will remove all functions of a device once you
attempt to hot-unplug a function.
What is the problem with adding more PCI buses, instead of multifunction
?
next prev parent reply other threads:[~2011-09-12 10:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1749303074.590739.1315551830460.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2011-09-09 7:08 ` [Qemu-devel] About hotplug multifunction Amos Kong
2011-09-09 7:32 ` Michael S. Tsirkin
2011-09-09 17:05 ` Alex Williamson
2011-09-09 18:34 ` Marcelo Tosatti
2011-09-11 9:23 ` Michael S. Tsirkin
2011-09-11 15:01 ` Marcelo Tosatti
2011-09-11 18:51 ` Michael S. Tsirkin
2011-09-12 10:21 ` Marcelo Tosatti [this message]
2011-09-12 10:56 ` Marcelo Tosatti
2011-09-12 12:24 ` Michael S. Tsirkin
2011-09-13 12:23 ` Amos Kong
2011-09-13 14:24 ` Amos Kong
2011-09-09 17:43 ` Isaku Yamahata
2011-09-11 9:05 ` Michael S. Tsirkin
2011-09-13 5:57 ` Isaku Yamahata
2011-09-13 6:52 ` Gleb Natapov
2011-09-13 7:00 ` Isaku Yamahata
2011-09-13 10:00 ` Michael S. Tsirkin
2011-09-13 10:05 ` Michael S. Tsirkin
2011-09-13 10:05 ` Gleb Natapov
2011-11-23 9:06 ` Amos Kong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110912102148.GA12332@amt.cnet \
--to=mtosatti@redhat.com \
--cc=akong@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).