From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW54U-0002mu-1i for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:54:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VW54N-0004Nm-Fq for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:54:01 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:56487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW54N-0004Ni-Bs for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:53:55 -0400 Received: by mail-qa0-f44.google.com with SMTP id cm18so3397810qab.17 for ; Tue, 15 Oct 2013 06:53:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1381844633.12118.33.camel@nilsson.home.kraxel.org> References: <1381762577-12526-1-git-send-email-mst@redhat.com> <87r4bnlbj6.fsf@codemonkey.ws> <1381844633.12118.33.camel@nilsson.home.kraxel.org> Date: Tue, 15 Oct 2013 06:53:54 -0700 Message-ID: From: Anthony Liguori Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PULL 00/43] pci, pc, acpi fixes, enhancements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Peter Maydell , Igor Mammedov , marcel.a@redhat.com, qemu-devel , "Michael S. Tsirkin" On Tue, Oct 15, 2013 at 6:43 AM, Gerd Hoffmann wrote: > On Mo, 2013-10-14 at 15:42 -0700, Anthony Liguori wrote: >> "Michael S. Tsirkin" writes: >> >> > Anthony, I know you wanted to review some of the patches, >> > since you didn't respond either all's well or you >> > could not find the time. >> > I think we are better off merging them for 1.7 and then - worst case, >> > if major issues surface - disabling the functionality at the last minute >> > than delaying the merge even more. >> >> There is no way I'll pull this for 1.7. Changes like this aren't going >> to get merged at the last minute. > > Hmm? Patches are discussed and tested for months, with the core not > having seen no big changes since weeks. Recent revisions of the series > are only fixing the bugs which showed up in testing and some finishing > touches. It certainly isn't something new poping out of the blue the > last minute. > > Why do you ignore the patches and discussions until things are settled > and the pull request comes in? Sorry, I shouldn't mix in general complaining with why I am not happy with this pull request. I already said I would take this change given a clear use-case and I would have merged it if the series was in a better state. I am sympathetic to not wanting to maintain this stuff in SeaBIOS. But I am not happy with the state of the pull request for reasons I explained in another note. Regards, Anthony Liguori > >> A good chunk of the series lacks >> any Reviewed-bys including the actual hotplug behind a pci bridge bits >> which is the whole point of the series. > > pci bridge hotplug is only a part of the whole picture. > > It is about using an existing standard (ACPI) to communicate hardware > config information between qemu and the guest OS. Without requiring the > middle man (seabios or other firmware) knowing details it doesn't need > to know for its own job. And avoid creating one paravirtual interface > after the other to give the firmware the information it needs to > generate the acpi tables. > > It is also about having *one* instance (qemu) generates the acpi tables > instead of expecting each firmware duplicate that functionality. It > makes live a lot easier for alternative firmwares such as ovmf and > coreboot. For coreboot the patch series (with the complementary > coreboot patches to load the tables from qemu) is a big step forward to > feature parity with seabios. > > And, yes, implementing features like pci bridge hotplug and memory > hotplug (oh, and lets not forget pvpanic) on top of the acpi generation > series is alot easier: > > * You implement it in qemu, and you are done. > >> This is a huge series and I still am not convinced this is the right >> path forward. The alternative to this series is a small set of changes >> to SeaBIOS to support PCI bridge hotplug, no? > > No. The alternative is: > > * You create a paravirt interface to communicate the > config information for $newfeature. > * You implement that in qemu. > * You implement that in seabios. > * You implement that in OVMF. > * You implement that in coreboot. > >> Or 10k SLOC of code into QEMU that includes breaking migration >> compatibility. > > On the plus side we can stop maintaining those 10k SLOC in seabios. > > The bits will stay there for a while for compatibility with older qemu > versions, but don't need much care any more as all new stuff will go > into qemu instead. > > cheers, > Gerd > > >