qemu-devel
[Top][All Lists]
Advanced

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

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


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration
Date: Sat, 12 Apr 2014 20:31:01 +1000

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.




reply via email to

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