On 01/11/2011 09:37 AM, Avi Kivity wrote:
Why not? Whatever state the kernel keeps, we expose to userspace
and allow sending it over the wire.
What exactly is the scenario you're concerned about?
Migration between userspace HPET and in-kernel HPET?
Yes. To a lesser extent, a client doing 'info hpet' or similar and
failing for kernel hpet.
That's pretty easy to address.
One thing I've been considering is essentially migration filters. It
would be a set of rules that essentially were "hpet-kvm.* = hpet.*"
which would allow migration from hpet to hpet-kvm given a translation
of state. I think this sort of higher level ruleset would make it
easier to support migration between versions of the device model.
Of course, that only gives you a forward path. It doesn't give you a
backwards path.
It would be easier to have them use the same device id in the first
place.
If it looks like an i8254, quacks like an i8254, and live migrates
like an i8254, it's probably an i8254.
And that's fine. I'm not suggesting you call it i8253. But it's two
separate implementations. We should make that visible, not try to hide
it. It's an important detail.
Imagine getting a sosreport that includes a dump of the device tree.
You really want to see something in there that tells you it's an
in-kernel PIT and not the userspace one.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
