From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xu, Quan" Subject: Re: [PATCH v3 0/2] VT-d flush issue Date: Tue, 22 Dec 2015 08:43:22 +0000 Message-ID: <945CA011AD5F084CBEA3E851C0AB28894B7FD003@SHSMSX101.ccr.corp.intel.com> References: <945CA011AD5F084CBEA3E851C0AB28894B7FBC68@SHSMSX101.ccr.corp.intel.com> <5677F4B502000078000C1D51@prv-mh.provo.novell.com> <945CA011AD5F084CBEA3E851C0AB28894B7FC2D8@SHSMSX101.ccr.corp.intel.com> <5678039102000078000C1DEA@prv-mh.provo.novell.com> <945CA011AD5F084CBEA3E851C0AB28894B7FC546@SHSMSX101.ccr.corp.intel.com> <56780B3D02000078000C1E47@prv-mh.provo.novell.com> <5679114D02000078000C219D@prv-mh.provo.novell.com> <945CA011AD5F084CBEA3E851C0AB28894B7FCEAF@SHSMSX101.ccr.corp.intel.com> <5679177202000078000C21ED@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5679177202000078000C21ED@prv-mh.provo.novell.com> Content-Language: en-US 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 , "Wu, Feng" Cc: "Tian, Kevin" , "'keir@xen.org'" , "'george.dunlap@eu.citrix.com'" , "'andrew.cooper3@citrix.com'" , "'tim@xen.org'" , "'xen-devel@lists.xen.org'" , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org > On December 22, 2015 4:27pm, wrote: > >>> On 22.12.15 at 09:10, wrote: > > For Device-TLB flush error, I think we need to propagated error code. > > For IEC/iotlb/context flush error, if panic is acceptable, we can > > ignore the propagated error code. BTW, it is very challenge / tricky > > to handle all Of error, and some error is unrecoverable. As mentioned, > > it looks like rewriting Xen hypervisor. > > We're moving in circles. In particular I don't believe this last sentence. > Re-writing many parts of the hypervisor would be required is you were to return > the error to the guest (which technically isn't possible in many case afaict). > Having crashed the guest, you don't need to be concerned about unrolling > previous (partially completed) operations, so I don't think it's this much of a > rewrite. > > And just to be clear - I hope you recall that the current approach taken to the > flush issue is already a compromise far away from where we initially meant the > code to move, and it was always clear that the bad error handling state the > code is in is going to get in the way of this being a simple fix. It's sad that the > people originally having introduced that code can't be held responsible for fixing > this up, but that's a situation we find ourselves in all the time. > > Jan Jan, Let's finish our discussion. I accept your idea. But I need to separate it into 3 patch set (It is complicated for me, sometime it makes me crash.): Patch set 1: Device-TLB/iotlb flush error. (send out this week) Patch set 2: context flush error. (need 2 ~ 3 weeks) Patch set 3: iec flush error. (need 3 ~ 4 weeks) If it is acceptable, we can discuss in detail one by one.. Thanks -Quan