> Am 12.04.2014 um 05:44 schrieb Alexey Kardashevskiy <a...@ozlabs.ru>: > >> On 04/12/2014 07:55 AM, Benjamin Herrenschmidt wrote: >> On Fri, 2014-04-11 at 11:40 +0200, Alexander Graf wrote: >>>> And G5 uses 33333333. I really do not understand why it is bad to >>>> send-and-check timer frequency. Why? >>> >>> Because the guest will continue to run at a different TB frequency on >>> the new host and break. >> >> Right, which is why we should send it accross so it can be checked and >> we can barf accordingly rather than having random odd things happen :-) > > As I was explained several times already, QEMU does not transfer > configuration (yet) and we only > should implement correct transfer of > parameters (without checking) and specify in the QEMU command line the ones > which cannot be transferred.
Exactly. We should try to migrate only state that the user doesn't specify on the command line. > > 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. > 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. 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. Alex
