[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acikf/lGN9IWJxBzEd2NMQAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] x86: remove use of per-domain lock frompage table entry handling

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.