From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] VMX: wbinvd when vmentry under UC Date: Fri, 29 Nov 2013 14:50:13 +0000 Message-ID: <5298A9A5.3090204@citrix.com> References: <52937D2C.2050900@citrix.com> <52938D0C0200007800106D24@nat28.tlf.novell.com> <96EC5A4F3149B74492D2D9B9B1602C2734838CF7@ORSMSX105.amr.corp.intel.com> <5297520202000078000A7FF5@nat28.tlf.novell.com> <5298A3A8.6030409@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Liu, Jinsong" Cc: "keir@xen.org" , Jan Beulich , "Nakajima, Jun" , "tim@xen.org" , "Dong, Eddie" , "zhenzhong.duan@oracle.com" , "Dugger, Donald D" , "xen-devel@lists.xen.org" , "Auld, Will" , "suravee.suthikulpanit@amd.com" , "sherry.hurwitz@amd.com" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On 29/11/13 14:31, Liu, Jinsong wrote: > Andrew Cooper wrote: >> On 29/11/13 14:15, Liu, Jinsong wrote: >>> Jan Beulich wrote: >>>>>>> "Liu, Jinsong" 11/28/13 8:17 AM >>> >>>>> Liu, Jinsong wrote: >>>>>> Yes. reprogram_timer here just delay timer a little slot, say, >>>>>> 1~2ms. I think it's OK, i.e. at any point of wbinvd() operation at >>>>>> hypervisor, or any irq disabled area, timer interrupt in fact also >>>>>> has good chance to be delayed some time -- however at >>>>>> TIMER_SOFTIRQ, all expired thing would be executed, and >>>>>> re-calculated and set next time point via reprogram_timer -- >>>>>> that's OK. >>>>> Comments/thoughts about this option? >>>> Apart from continuing to be very uncertain that this won't have any >>>> bad side effects, I'm also rather concerned that you deal with one >>>> special case interrupt here, ignoring other potentially high rate >>>> ones (like such coming from NICs). >>>> >>>> Jan >>> Considering this, seems adding flag is the only work around way >>> since high freq interrupt would result in dead-like-loop. My concern >>> of adding flag is it's not easy to clean every possible path, >>> especially future extension. >>> >>> Or, do not support vt-d w/o snoop. >>> >>> Thanks, >>> Jinsong >> Do you know how many systems have vt-d without snoop ? >> >> ~Andrew > Yes, that's what I need check inside Intel. Maybe not feasible idea I agree. > > Thanks, > Jinsong Given that PCIPassthrough realistically involves requiring trusting the guest administrator, it might be feasible to have another iommu= option of "allow passthough even without snoop". ~Andrew