From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir@xen.org>
Subject: Re: lock in vhpet
Date: Wed, 18 Apr 2012 09:29:07 +0100
Message-ID: <CBB439E3.3E625%keir@xen.org>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0DA169@SHSMSX101.ccr.corp.intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:

>> If the HPET accesses are atomic on bare metal, we have to maintain that, even
>> if some guests have extra locking themselves. Also, in some cases Xen needs
>> locking to correctly maintain its own internal state regardless of what an
>> (untrusted) guest might do. So we cannot just get rid of the vhpet lock
>> everywhere. It's definitely not correct to do so. Optimising the hpet read
>> path
>> however, sounds okay. I agree the lock may not be needed on that specific
>> path.
> 
> You are right.
> For this case, since the main access of hpet is to read the main counter, so I
> think the rwlock is a better choice.

I'll see if I can make a patch...

 -- Keir