From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
Subject: Re: Deadlocks by p2m_lock and event_lock
Date: Wed, 14 Mar 2012 07:18:23 -0700
Message-ID: <1be627507cd2ac35967f3149e8f8a387.squirrel@webmail.lagarcavilla.org>
References: <403610A45A2B5242BD291EDAE8B37D300FCE3236@SHSMSX102.ccr.corp.intel.com>
	<20120309112010.GB83422@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FCE32B2@SHSMSX102.ccr.corp.intel.com>
	<763b511f59616a274ff142d62f55f7bf.squirrel@webmail.lagarcavilla.org>
	<20120309165544.GE83422@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FCE7398@SHSMSX102.ccr.corp.intel.com>
	<109443395be5f3e323fa7d0d1977f8b6.squirrel@webmail.lagarcavilla.org>
	<4F6071050200007800078384@nat28.tlf.novell.com>
Reply-To: andres@lagarcavilla.org
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: <4F6071050200007800078384@nat28.tlf.novell.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: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Xudong Hao <xudong.hao@intel.com>, Xiantao Zhang <xiantao.zhang@intel.com>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

>>>> On 13.03.12 at 19:26, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>  Hi, Tim and Andres
>>> The patch fix part of this issue. In handle_mmio, function
>>> hvmemul_do_io()
>>> is called and p2m lock was held again by calling get_gfn_unshare(),
>>> still
>>> trigger a deadlocks.
>>
>> I have a question before I dive into lock untangling
>>
>> msix_capability_init ->
>> p2m_change_entry_type_global(dev->domain, p2m_mmio_direct,
>> p2m_mmio_direct);
>>
>> Huh? This achieves ... nothing. Almost. It flushes a bunch of TLBs, but
>> that can be done with significantly less effort. Am I missing something?
>
> Yes - the purpose of this isn't to flush any TLBs, but to enforce the
> immediately preceding addition to the mmio_ro_ranges range set.

Because p2m entries of type mmio_direct have their permissions
(re)computed as a function of rangesets. Got it. Thanks.

Andres
>
> Jan
>
>