From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN9mT-0002Xe-IX for qemu-devel@nongnu.org; Sat, 13 Oct 2012 18:02:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TN9mS-0006In-9f for qemu-devel@nongnu.org; Sat, 13 Oct 2012 18:02:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN9mS-0006Ih-0v for qemu-devel@nongnu.org; Sat, 13 Oct 2012 18:02:00 -0400 Date: Sun, 14 Oct 2012 01:03:50 +0200 From: "Michael S. Tsirkin" Message-ID: <20121013230350.GB7425@redhat.com> References: <20121011105705.GE5552@redhat.com> <20121011142122.GH3592@redhat.com> <20121011144656.GF8983@redhat.com> <20121011153408.GI3592@redhat.com> <20121011204004.GA14600@redhat.com> <20121012152721.GM3592@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121012152721.GM3592@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 21/21] q35: add acpi-based pci hotplug. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: agraf@suse.de, aliguori@us.ibm.com, juzhang@redhat.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org, armbru@redhat.com, blauwirbel@gmail.com, yamahata@valinux.co.jp, alex.williamson@redhat.com, kevin@koconnor.net, avi@redhat.com, mkletzan@redhat.com, pbonzini@redhat.com, lcapitulino@redhat.com, afaerber@suse.de, kraxel@redhat.com 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