From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [PATCH 2/3] xen/vt-d: mask interrupt message generation Date: Mon, 04 May 2015 19:21:14 +0800 Message-ID: <5547562A.1040101@intel.com> References: <1430705771-6744-1-git-send-email-tiejun.chen@intel.com> <1430705771-6744-2-git-send-email-tiejun.chen@intel.com> <5546FEC7.1090104@intel.com> <554750860200007800076341@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <554750860200007800076341@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Kevin Tian , "keir@xen.org" , "jinsong.liu@alibaba-inc.com" , "xen-devel@lists.xen.org" , "andrew.cooper3@citrix.com" , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org On 2015/5/4 16:57, Jan Beulich wrote: >>>> On 04.05.15 at 07:08, wrote: >> At first I doubted this is issued by some improper cache behaviors. >> Because as you see, "root_entry[0] = 80f5001" indicates we already set >> that present bit. But Caching Mode bit is zero in BDW so this means >> remapping hardware doesn't own contest cache. And I also check xen >> always calls clflush to write back memory on CPU side. (Even I also >> tried to use wbinvd to replace clflush). And plus, you can see this >> guest fault address is a weird zero, so I turned to concern if this is >> just an unexpected fault which is pending because of some BIOS cleanup, >> or undefined hardware behaviors. Here I mean clear_fault_bits() is >> already not enough to clear this kind of pending interrupt before we >> complete all VT-D initializations. > > This last aspect in particular needs more explanation, but I'm > wary of the change in general (see Yang's response). > Sure. As we discussed offline, Yang though at most this is a way to workaround our problem. So I would ping BIOS team to double check if this is an issue specific to some given BIOSs or platforms since this doesn't meet the current specification Thanks Tiejun