Glauber Costa wrote:
On Tue, Oct 28, 2008 at 7:51 PM, Anthony Liguori <[EMAIL PROTECTED]> wrote:
This is part of the reason for this exercise. I'd rather introduce KVM
support first and then look at abstracting things, than vice versa. A
number of the hooks in the current QEMUAccel tree are there for the wrong
reason (to support the out-of-tree IO thread, for instance).
If you just introduce something with various hooks and say, these are hooks
we'll need, it's not possible to really evaluate whether the hooks are
needed because nothing in the tree makes use of them.
We talked extensively on monday about it, and I'm in agreement with it.
Something I was thinking about this morning, and I think the first place
where we'll definitely need a hook, is how to deal with
kvm_load_registers(). I think there's overlap between KVM and the IO
thread here.
There are two reasons (I can think of) that most of the device model
code can't run in conjunction with TCG. The first is that TCG may
modify CPUState in a non-atomic way. The device model may need to
access CPUState although there are very few places that it does. The
other reason is accessing guest memory. TCG does not preserve atomicity
when a guest accesses device memory. There are probably only a few
places in the device model (like virtio) that depend on atomicity.
If we implemented an API that implemented a lock/unlock for CPUState and
for portions of memory, then I think this could be used both as a hook
for kvm_load_registers and as a way to introduce an IO thread with TCG.
The CPUState lock/unlock is pretty straight forward. For the memory
implementation to be efficient, I think you would have to acquire the
lock when TCG brings a physical address into the TLB (preferrably, at a
page granularity), or whenever someone tries to access memory (via
cpu_physical_memory_rw). I think in the vast majority of the cases,
there wouldn't be any contention and both could TCG could run along side
the IO thread.
Another place "hook" is updating a slot's dirty bitmap. Right now, with
my patchset we don't have live migration or the VGA RAM optimization.
There's nothing about the VGA RAM optimization that wouldn't work for
QEMU. I'm not sure that it really is an optimization in the context of
TCG, but I certainly don't think it's any worse. The only thing you
really need is to query the KVM dirty bitmap when it comes time to
enable start over querying the VGA dirty bits.
The same is needed for live migration, so I think what we really need is
to change the memory dirty bit tracking API to have a concept of refresh
that we can use to hook for KVM.
FWIW, I included a TODO in my patch if people are interesting in
tackling any of these things.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Regards,
Anthony Liguori
surprised,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html