From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 0/2] VT-d flush issue Date: Tue, 22 Dec 2015 01:27:14 -0700 Message-ID: <5679177202000078000C21ED@prv-mh.provo.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28894B7FCEAF@SHSMSX101.ccr.corp.intel.com> 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: Feng Wu , Quan Xu Cc: Kevin Tian , "'keir@xen.org'" , "'george.dunlap@eu.citrix.com'" , "'andrew.cooper3@citrix.com'" , "'tim@xen.org'" , "'xen-devel@lists.xen.org'" , Jun Nakajima List-Id: xen-devel@lists.xenproject.org >>> 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