qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH 4/4] spapr: Add support for time base offset migration
Date: Sat, 12 Apr 2014 09:25:37 +0200


> Am 12.04.2014 um 05:44 schrieb Alexey Kardashevskiy <address@hidden>:
> 
>> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]