> Am 12.04.2014 um 12:31 schrieb Benjamin Herrenschmidt > <b...@kernel.crashing.org>: > >> 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).
I agree and it's what I'm advocating for a while. Quick hacky band-aids don't help anyone achieve that goal though. > > 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 :) Exactly :). Better limit ourselves consciously than get eaten up by the sheer amount of work to make things work nobody cares about ;) > >>> 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". I call things we can't configure HW constraints. The fact that you can't fake PVR with HV KVM is a hardware constraint. The fact that you can't scale the TB is a hardware constraint. Anything we emulate is not a hardware constraint, since we have full control of it. So if we don't like what we have we can change it :). > 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). Don't we generate PHBs on the fly? How exactly is this going to help with the problem at hand? Alex > >> 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. >
