On Sat, 2014-04-12 at 09:25 +0200, Alexander Graf wrote: > Exactly. We should try to migrate only state that the user doesn't > specify on the command line.
>From a design standpoint I find that totally retarded btw :-) The sensible thing to do would have been for the configuration to migrate along the state (the difference between the two can be fairly blurry at times). But people seem to love moving all the responsibility to libvirt's trainwreck ... it's funny, it as if you guys were fundamentally allergic to making something simple that works well :-) > > > > So with timebase frequency, it should be a command line switch > (-machine > > option?) which would take frequency and fail if it is POWER7/8 and > not > > 500MHz. And then libvirt should take care of it (always pass it or > have XML > > tag for it). > > We can also declare everything before p7 non-migratable. That would > also solve the issue. I suppose there is little point in migrating a g5 :) > > Same story as with migrating IRQs (which I do now in a hacky > > way but I am going to changed it to work via the command line). > > It's slightly different, but similar. The tb frequency is a hardware > constraint, IRQ numbering isn't. Depends what you call "HW contraints". IRQ numbering *is* fully HW constrained for some platforms such as macs and fairly flexible on others like pseries because the HW itself is more configurable. PAPR paravirt somewhat makes it even less constrained which makes it really tricky to decide whether IRQ numbers are state or configuration. Practically however, we can consider them HW constraints as long as we assign fixed ranges per PHB for MSIs (which is more or less what the HW does, except that the actual ranges are configured at boot time by FW but generally in a fairly fixed way). > But either way works for me really. I would be happy to make pre-p7 > cpus non-migratable. It'd definitely reduce the test matrix. Ben.
