From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: heavy P2M lock contention on guest HPET counter reads Date: Fri, 01 Aug 2014 07:38:02 +0100 Message-ID: <53DB51EA020000780002843D@mail.emea.novell.com> References: <53D8E0540200007800027966@mail.emea.novell.com> <53D91BD30200007800027B61@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XD6Ta-000793-NB for xen-devel@lists.xenproject.org; Fri, 01 Aug 2014 06:38:02 +0000 In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andres Lagar Cavilla Cc: xen-devel , Tim Deegan List-Id: xen-devel@lists.xenproject.org >>> On 30.07.14 at 20:15, wrote: > Having said that, I don't know off the top of my head that is obviously > correct to shortcut the p2m lookup for msix table and iommu. I think so, > but... All internal MMIO ranges are what you'd call "positively decoded" on real hardware, i.e. they ought to supersede any other address decoding rules anyway. Since they're also not associated with possibly varying MFNs, the P2M lookup on them is simply pointless, and short-circuiting them is imo at once making better guarantees towards consistent behavior. Jan