From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWVw4-00027T-BD for qemu-devel@nongnu.org; Wed, 16 Oct 2013 14:35:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWVvy-0004hk-Bu for qemu-devel@nongnu.org; Wed, 16 Oct 2013 14:35:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWVvy-0004eD-4G for qemu-devel@nongnu.org; Wed, 16 Oct 2013 14:35:02 -0400 Date: Wed, 16 Oct 2013 21:37:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20131016183732.GA8157@redhat.com> References: <1381762577-12526-1-git-send-email-mst@redhat.com> <1381762577-12526-43-git-send-email-mst@redhat.com> <525D51C3.2050201@redhat.com> <20131015143530.GA7763@redhat.com> <525D5630.1030801@redhat.com> <87txgimrd6.fsf@codemonkey.ws> <20131015201706.GB9579@redhat.com> <20131016181800.GB7100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , gleb@redhat.com, marcel.a@redhat.com, qemu-devel , Gerd Hoffmann , Igor Mammedov , Paolo Bonzini On Wed, Oct 16, 2013 at 11:18:42AM -0700, Anthony Liguori wrote: > On Wed, Oct 16, 2013 at 11:18 AM, Michael S. Tsirkin wrote: > > On Wed, Oct 16, 2013 at 09:38:29AM -0700, Anthony Liguori wrote: > >> On Tue, Oct 15, 2013 at 1:17 PM, Michael S. Tsirkin wrote: > >> > On Tue, Oct 15, 2013 at 09:27:33AM -0700, Anthony Liguori wrote: > >> >> Paolo Bonzini writes: > >> >> > >> >> > Il 15/10/2013 16:35, Michael S. Tsirkin ha scritto: > >> >> >> On Tue, Oct 15, 2013 at 04:31:31PM +0200, Paolo Bonzini wrote: > >> >> >>> Il 14/10/2013 17:01, Michael S. Tsirkin ha scritto: > >> >> >>>> - VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, vmstate_pci_status, > >> >> >>>> - struct pci_status), > >> >> >>>> + VMSTATE_STRUCT_TEST(pci0_status, PIIX4PMState, > >> >> >>>> + vmstate_test_no_use_acpi_pci_hotplug, > >> >> >>>> + 2, vmstate_pci_status, > >> >> >>>> + struct pci_status), > >> >> >>> > >> >> >>> There's no reason to remove this from the stream when a new machine type > >> >> >>> is in use. You'll just send out zeroes. > >> >> >> > >> >> >> Seemed cleaner not to. > >> >> > > >> >> > It certainly would be if we had a self-descriptive migration stream > >> >> > format. > >> >> > >> >> Yes, removing tests is always a good thing. > >> >> > >> >> But I think subsections should always be used when they can. We should > >> >> not break compatibility (even if we technical don't guarantee it) unless > >> >> we absolutely have to. > >> >> > >> >> Regards, > >> >> > >> >> Anthony Liguori > >> > > >> > OK so I can interpret this in 2 ways wrt bridge hotplug: > >> > - it's in shape for 1.7 except the migration which should use > >> > subsections (and needs cross-version testing) > >> > - it's not in shape for 1.7 > >> > > >> > Can you tell me which it is please? > >> > >> The code is not in shape. Forget about the existence of 1.7. Focus > >> on getting the code right and it will make whatever release it is > >> ready for. If that's 1.7, great, but the fact that 1.7 is around the > >> corner does not mean we're going to merge something that isn't ready > >> just so it makes the release. > > > > OK. Apropos 1.7, how about moving soft freeze and the release out > > by a couple of weeks? > > No. > > There is always some reason to delay releases. We have a release > every quarter. It's not a big deal to just wait for a feature for the > next release. That's the whole point of doing frequent releases. > > > What with you moving over and the kvm forum, people > > didn't have time to focus on it properly IMO. > > In particular it's harder than usual to get reviews. > > > >> Migration is one issue. > > > > Right but what's special about this feature? > > Almost anything we do affects migration in some way. > > There is nothing special and the feedback you are getting is no > different than any other series. > > > > >> As I said before, testing is another. There > >> really should be some test automation for this. > >> > >> Regards, > >> > >> Anthony Liguori > > > > I'm not sure I understand what you are saying here. > > > > If you just want testing hotplug, automation is there. > > Unit level testing. IOW, something that gets run during 'make check' > to verify that we're generating proper ACPI tables. > > Regards, > > Anthony Liguori In particular I do *not* want to write a consumer for the guest interfaces in qemu. bios has one, duplicating it in qemu is not a good idea. By far the best way to test this is to boot some guest, download tables, then run iasl -d on them. I used linux guest but that's not necessary, we could do this by integrating kvm unit test code. But if we do integrate it, I think it's better to merge than fork. Gleb, Paolo, what do you think? OK to merge kvm unit test into qemu? It depends on qemu anyway, in-tree will make it easier. Maybe someone's looking at this already? If people agree I'll try to make sure this happens but I hope it's not a precondition, it's a lot of work (and it won't help if I'm distracted rebasing patches :) ) > > Automated testing for cross-version migration? that's not easy since you > > need two versions around. I'll talk to autotest guys but don't hold your > > breath. But a bigger issue is that migration and hotplug don't work > > well together in qemu ATM. > > > > -- > > MST