Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

[Alexander Graf]

> Am 12.04.2014 um 12:31 schrieb Benjamin Herrenschmidt <address@hidden>:
> 
>> 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.
>