Re: KVM swapping with mmu notifiers

Avi Kivity
2008-01-22T16:17:38Z

Andrea Arcangeli wrote:
> 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.
>

There can be more than one rmapp per hva. Real world example:

memslot 1: gfn range 0xe000000 - 0xe0800000 @ hva 0x10000000 (8MB
framebuffer)
memslot 2: gfn range 0xa0000 - 0xa8000 @ hva 0x10000000 (32KB VGA window)

If the guest accesses gfn 0xa0000 through one gva, and gfn 0xe0000000
through a second gva, then you will have two rmap chains for hva 0x10000000.

This doesn't happen today because we use the alias mechanism in qemu,
but we don't forbid it either.

--
error compiling committee.c: too many arguments to function