On Tue, Jan 22, 2008 at 03:37:59PM +0200, Avi Kivity wrote:
> Andrea Arcangeli wrote:
>> On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
>>
>>> Yes, it's supposed to work (we can't prevent userspace from doing it).
>>>
>>
>> Hmm, I think we already prevent it, so I don't think I need to update
>> my swap code until the below is removed.
>>
>> /* Check for overlaps */
>> r = -EEXIST;
>> for (i = 0; i < KVM_MEMORY_SLOTS; ++i) {
>> struct kvm_memory_slot *s = &kvm->memslots[i];
>>
>> if (s == memslot)
>> continue;
>> if (!((base_gfn + npages <= s->base_gfn) ||
>> (base_gfn >= s->base_gfn + s->npages)))
>> goto out_free;
>> }
>>
>>
>
> Actually, this checks against slots with the overlapping gfns. Aliases
> have different gfns but same hvas.
Hmm not sure to follow, do you mean I need to change something?
Aliases live in a different dimension, and I can't see how my code
could ever notice or care about aliases (that have to be translated to
a real hva-memslot-backed gfn before calling get_user_pages). All I
care about are to find the right rmap structures for each hva. The
above snippet should be enough to guarantee that there can only be 1
rmap structure for each hva, so when I checked yesterday that looked
enough to prove my kvm_hva_to_rmapp implementation already correct.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
