From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 7/7] xen/arm: phys_timer fixes
Date: Mon, 18 Feb 2013 16:23:58 +0000
Message-ID: <1361204638.1051.36.camel@zakaz.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
	<1361202864.1051.22.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.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: <alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	(Xen.org)" <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, 2013-02-18 at 16:14 +0000, Stefano Stabellini wrote:
> I think they mean "latch" in electronic sense: they use an SR latch to
> keep the pending bit high even if the guest EOIs the interrupt, as long
> as the mask bit is 1.

> In other words the pending bit cannot be reset if the mask bit is 1.

"latching high" is a plausible interpretation of the docs given the
observed behaviour on the A15.

We shouldn't assume that just because it appears to behave on way on the
A15, for all we know the state of the PENDING bit while mask==0 is
explicitly implementation defined and just happens to follow the state
of the interrupt in this particular implementation (yes, this would make
Linux and Xen both buggy in their handling). After all we don't have any
alternative implementations to compare with...

So I'd still prefer to check with ARM, rather than potentially bake a
buggy "hardware" implementation into our interface.

> So I should prevent the guest from resetting this bit directly in all
> cases and also I should not reset the bit on EOI if the mask bit is 1.

You also need to do the right thing when the guest clears the mask bit,
which is going to require you to track if the interrupt has been EOId
separately from the pending bit.

> I agree that is confusing though.

Very!