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 <m...@redhat.com> 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 <m...@redhat.com> > >> wrote: > >> > On Tue, Oct 15, 2013 at 09:27:33AM -0700, Anthony Liguori wrote: > >> >> Paolo Bonzini <pbonz...@redhat.com> 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
