All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH] kvm memslot read-locking with mmu_lock
Date: Tue, 22 Jan 2008 15:50:43 +0100	[thread overview]
Message-ID: <20080122145043.GF7331@v2.random> (raw)
In-Reply-To: <4795FFF9.8010400-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

On Tue, Jan 22, 2008 at 04:38:49PM +0200, Avi Kivity wrote:
> Andrea Arcangeli wrote:
>>
>>> This is arch independent code, I'm surprised mmu_lock is visible here?
>>>     
>>
>> The mmu_lock is arch independent as far as I can tell. Pretty much
>> like the mm->page_table_lock is also independent. All archs will have
>> some form of shadow pagetables in software or hardware, and mmu_lock
>> is the lock to take to serialize the pagetable updates and it also
>> allows to walk the memslots in readonly mode.
>>
>>   
>
> Well, s390 has everything in hardware, but I suppose they can just ignore 
> the lock.

If they don't take it in their lowlevel it's enough I think. It'll
still be useful to lookup memslots like in every other arch.

> But we lookup memslots in parallel in the guest walker and similar places, 
> relying on mmap_sem being taken for read.

That's ok. The vmas could also be looked up either with mmap_sam in
read mode or with only the page_table_lock taken (these days it
doesn't work anymore with ptlocks). The mmu_lock is only taken in the
modifications of the memslots, the lookups don't require it. The
modifications have to take both mmap_sem in write mode and the
mmu_lock. Lookups requires either mmap_sem in read mode or the
mmu_lock. The lookups with mmap_sem in read mode won't ever see a
userspace_addr =0, the mmu_lock have to skip over the userspace_addr=0 instead.

> Maybe we need a rwlock instead, and drop this overloaded usage of mmap_sem.

Adding another lock just for the memslots should be feasible. However
it can't be a semaphore or it won't work for the
mmu-notifiers. A rwlock would be ok, but then all memslots lookups
will have to be updated to check for userspace_addr != 0 like the
kvm_hva_to_rmapp does.

> Nothing guarantees a 1:1 mapping between memslots and vma.  You can have a 
> vma backing multiple memslots, or a memslot spanning multiple vmas.

Yes, that's why it would add complications to have it in the vma, one
would need to add a vma split to guarantee the 1:1 mapping, and then
it'd be a bit faster too (though the memslots can easily be rbtree-indexed).

-------------------------------------------------------------------------
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/

  parent reply	other threads:[~2008-01-22 14:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-21 12:37 [PATCH] kvm memslot read-locking with mmu_lock Andrea Arcangeli
     [not found] ` <20080121123710.GF6970-lysg2Xt5kKMAvxtiuMwx3w@public.gmane.org>
2008-01-22 13:47   ` Avi Kivity
     [not found]     ` <4795F3F0.90403-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-22 14:32       ` Andrea Arcangeli
     [not found]         ` <20080122143210.GC7331-lysg2Xt5kKMAvxtiuMwx3w@public.gmane.org>
2008-01-22 14:38           ` Avi Kivity
     [not found]             ` <4795FFF9.8010400-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-22 14:50               ` Andrea Arcangeli [this message]
     [not found]                 ` <20080122145043.GF7331-lysg2Xt5kKMAvxtiuMwx3w@public.gmane.org>
2008-01-23  8:15                   ` Carsten Otte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080122145043.GF7331@v2.random \
    --to=andrea-atkuwr5tajbwk0htik3j/w@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.