From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [v8][PATCH 06/16] hvmloader/pci: disable all pci devices conflicting with rdm Date: Thu, 16 Jul 2015 17:40:13 +0100 Message-ID: <55A7DE6D.2010505@citrix.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> <55A7D701.90801@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A7D701.90801@intel.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: "Chen, Tiejun" , 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 07/16/2015 05:08 PM, Chen, Tiejun wrote: > 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. A better way to communicate between xl and hvmloader is to use xenstore, as we do for allow_memory_reallocate. But I have very little hope we can hash out a suitable design for that by tomorrow. -George