Re: About hotplug multifunction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
?

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux