On 07/26/2009 02:55 PM, Alexander Graf wrote:
I will need some acks from ppc people. Obviously for the non-kvm
bits, but also for the kvm bits as I am not qualified to review ppc
code.
Right, FWIW Ben would actually even prefer to take the whole thing in
his tree.
That's likely to cause conflicts if some kvm API changes and needs
modifications to this code. Perhaps the best option is for the non-kvm
changes to go through the ppc tree, and for me to duplicate (but not
push) them.
- use MMU Notifiers
What's the plan here?
Implement MMU Notifiers as soon as I fully understand them? :-)
I'm aware of the basic concept, but the callbacks still seem somewhat
magical to me.
Ask and I'll do my best to answer.
- use u64* for dirty log
Is this a userspace interface issue? if so it will need to be
addressed before merging.
Yes, on big endian having a 64-bit kernel and 32-bit userspace breaks
when dirty log is ulong*. Nobody saw this until now, because it's not
a big deal on little endian.
I sent a patch doing the qemu side of things already, but haven't went
through the kvm bits yet. Basically we can't use set_bit and test_bit
for the dirty log, because they require us to have the bitmap as ulong*.
Yuck. What do we do? Implement set_bit_u64() and friends?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
