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 05:24:53 +0800 Message-ID: <55A82125.5060801@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> <55A7D701.90801@intel.com> <55A7DE6D.2010505@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A7DE6D.2010505@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 Jan and George, That implementation to this problem in v7 is really not accepted? Yes, that isn't a best solution to make our original mechanism very well, but in high level I just think that should be a correct solution fixing this problem. According to recent discussion seems we have not a efficient way which can be put into 4.6. So instead, could your guys help me make that better gradually to reach our current requirement as possible? Thanks Tiejun On 2015/7/17 0:40, George Dunlap wrote: > 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 > >