qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 21/21] q35: add acpi-based pci hotplug.


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 21/21] q35: add acpi-based pci hotplug.
Date: Sun, 14 Oct 2012 01:03:50 +0200

On Fri, Oct 12, 2012 at 11:27:21AM -0400, Jason Baron wrote:
> On Thu, Oct 11, 2012 at 10:40:04PM +0200, Michael S. Tsirkin wrote:
> > > Windows and Linux guests seem fine with either layout. Slots 1-2 are
> > > specific to my setup. So this is a pretty minimal set.
> > 
> > I guess we can remove the PCI bridge too?
> > 
> 
> maybe. Perhaps, we can have a very basic set of devices, and have easy
> ways to specify various default setups, as I've suggested in a separate
> mail.
> 
> > One interesting side effect here is that there are less free pci slots
> > on root bus now.  I guess at minimum management needs to be taught about
> > this, and I'm not sure how.
> > 
> > > I think that providing the minimal set of devices is good, since it
> > > allows the user to configure things as much as possible. So I am in
> > > favor of this more minimal set. My only hesitation is that we pull out,
> > > or that I have not included some important piece h/w at a specific slot
> > > that a guest might need. Thus potentially breaking existing setups.
> > > Perhaps, that might mean a new machine type in the future, if we've
> > > messed up?
> > 
> > Yes, that's one solution.
> > 
> > > These devices and slots are pulled from the Intel docs on ICH9 and Q35
> > > specs. See:
> > > 
> > > http://www.intel.com/content/www/us/en/io/io-controller-hub-9-datasheet.html
> > > 
> > > Perhaps, Yamahata can comment further on the specific set of bridges?
> > > 
> > > > It would also be nice to add comments explaining why
> > > > specific slots were selected e.g. /* BSD XYZ fails to boot unless ahci 
> > > > is at alow 2 */
> > > > etc.
> > > 
> > > Right, its basically just pulled from the Intel spec as mentioned above.
> > > 
> > > > 
> > > > Also - will adding this code now mean that when adding bridges
> > > > we'll need to add compatibility code in bios/qemu in the future?
> > > > 
> > > 
> > > I don't think so, but maybe you can elaborate this concern more
> > > specifically?
> > > 
> > > Thanks,
> > > 
> > > -Jason
> > 
> > Just this: can same bios work on this interface and the one
> > you intend for hotplug behind bridge? Or will we need to version
> > interface?
> > 
> 
> hmm...I wasn't aware of this contraint. Since we control the version of
> SeaBIOS in qemu, is this really a problem? And it was suggested that
> qemu is the only consumer of the acpi tables.

Yes. But cross version live migration is what creates issues.

> The current hotplug code doesn't seem to be versioned. Has this caused
> problems?

Yes but in the end we found a way to be compatible.

> In terms of the interface itself, yes, I think ideally it would be
> changed.
> 
> Thanks,
> 
> -Jason

K good to know.
I think we can merge even with this knowledge as an interim step
assuming that we address this before we release qemu.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]