WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] x86: remove use of per-domain lock frompage tabl

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: remove use of per-domain lock frompage table entry handling
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 22 Apr 2008 14:51:33 +0100
Delivery-date: Tue, 22 Apr 2008 06:52:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <480E06A8.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acikf/lGN9IWJxBzEd2NMQAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] x86: remove use of per-domain lock frompage table entry handling
User-agent: Microsoft-Entourage/11.4.0.080122
On 22/4/08 14:39, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> I'm pretty sure we don't need per-page locks.
> 
> If you want to make serialization by the caller part of the ABI - yes.
> If not (and I think everything else would be wrong, as a malicious guest
> could take advantage of that), then the window between reading of
> the old entry and writing the new one must be protected against racing
> updates, as otherwise the page type and reference counters could get
> screwed up.

Ah, yes my statement assumes we return to doing cmpxchg for all PTE updates
(and retry on failure). As to whether that is better than your approach, I
suppose it depends on whether you can amortise the locking overheads across
multiple PTE updates. Right now it appears you lock/unlock on every PTE
update, which is double the number of locked cmpxchg operations compared
with just doing the cmpxchg on the pte itself.

Bear in mind that all the page reference counting was designed in the first
place to be safe, assuming the PTE update itself is done as an atomic
read-modify-write operation. It's just that we changed the latter to a
simple write some time ago because of course we observed that that's a safe
thing to do under the big lock.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>