From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v8][PATCH 06/16] hvmloader/pci: disable all pci devices conflicting with rdm Date: Fri, 17 Jul 2015 00:08:33 +0800 Message-ID: <55A7D701.90801@intel.com> References: <1437029582-19564-1-git-send-email-tiejun.chen@intel.com> <1437029582-19564-7-git-send-email-tiejun.chen@intel.com> <55A79AFA.3040500@intel.com> <55A7AFF4.1040909@intel.com> <55A7CE890200007800091EC8@mail.emea.novell.com> <55A7B647.8080808@intel.com> <55A7E1C30200007800091F48@mail.emea.novell.com> <55A7CBBA.90606@intel.com> <55A7D040.809@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A7D040.809@citrix.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: George Dunlap , Jan Beulich Cc: Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Andrew Cooper , Ian Jackson , "xen-devel@lists.xen.org" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 2015/7/16 23:39, George Dunlap wrote: > On 07/16/2015 04:20 PM, Chen, Tiejun wrote: >>>> What about this? >>> >>> Looks reasonable (but don't forget that I continue to be unconvinced >>> that the patch as a whole makes sense). >> >> Yes, I always keep this in my mind as I mentioned in patch #00. Any risk >> you're still concerning? Is it that case if guest OS force enabling >> these devices again? IMO, at this point there are two cases: >> >> #1. Without passing through a RMRR device >> >> Those emulated devices don't create 1:1 mapping so its safe, right? >> >> #2. With passing through a RMRR device >> >> This just probably cause these associated devices not to work well, but >> still don't bring any impact to other Domains, right? I mean this isn't >> going to worsen the preexisting situation. >> >> If I'm wrong please correct me. > > But I think the issue is, without doing *something* about MMIO > collisions, the feature as a whole is sort of pointless. You can > carefully specify rdm="strategy=host,reserved=strict", but you might I got what your mean. But there's no a good approach to bridge between xl and hvmloader to follow this policy. Right now, maybe just one thing could be tried like this, Under hvmloader circumstance, "strict" -> Still set RDM as E820_RESERVED "relaxed" -> Set RDM as a new internal E820 flag like E820_HAZARDOUS Then in the case of MMIO collisions E820_RESERVED -> BUG() -> Stop VM E820_HAZARDOUS -> our warning messages + disable devices I think this can make sure we always take consistent policy in each involved cycle. Thanks Tiejun > still get devices whose MMIO regions conflict with RMMRs, and there's > nothing you can really do about it. > > And although I personally think it might be possible / reasonable to > check in a newly-written, partial MMIO collision avoidance patch, not > everyone might agree. Even if I were to rewrite and post a patch > myself, they may argue that doing such a complicated re-design after the > feature freeze shouldn't be allowed. > > -George >