From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: Requesting for freeze exception for RMRR Date: Fri, 17 Jul 2015 09:16:08 +0800 Message-ID: <55A85758.2010702@intel.com> References: <55A35B5E.3000805@intel.com> <20150713114145.GF4108@zion.uk.xensource.com> <55A46575.5020607@intel.com> <20150714092915.GC4152@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150714092915.GC4152@zion.uk.xensource.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: Wei Liu Cc: Kevin , "ian.campbell@citrix.com" , George Dunlap , Andrew Cooper , "ian.jackson@eu.citrix.com" , "Wang, Yong Y" , "xen-devel@lists.xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 2015/7/14 17:29, Wei Liu wrote: > On Tue, Jul 14, 2015 at 09:27:17AM +0800, Chen, Tiejun wrote: >>> Please work with maintainers to get those hvmloader patches acked or >>> reviewed. >> >> I will do. Maybe I need to update current status today. I just send out v8: * All tools comments raised by Jackson and Campbell are addressed and I don't see further feedback. * On hv side, last one is reviewed by George. And looks Jan have no obvious objection to that. (Jan: If I'm wrong let me take it back. ) * On hvmloader side, there three patches now: patch #5 is reviewed by George and Acked by Jan; patch #6 is reviewed just for code implementation but that solution can't convince all maintainers. Honestly, this is a rare possibility of collision in real world and the original pci allocation is not good so its hard to reshape the original mechanism in one week. But actually we also have some other solutions but we need a little time to figure out how to step forward but I just think any solution wouldn't bring any change to other stuffs. patch #7 is pretty close to be Acked. So what's your final determination? Thanks Tiejun >> >>> >>>> >>>> Note Jackson and Campbell also raised some comments to improve current >>>> codes. >>>> >>>> 2. explain why it needs to be in this release (benefits). >>>> >>>> RMRR mechanism was broken for a long time and this makes VM always face >>>> security issues. In addition, those associated devices can't be passed >>>> through to VM and even result in VM crashes. >>>> >>>> 3. explain why it doesn't break things (risks). >>>> >>>> Our policy makes sure that system will work in the original way by default >>>> as without the RMRR patches. And especially, this series just impacts those >>>> platforms which have RMRR. >>>> >>> >>> Your patches touch crucial path in hvmloader to build memory map. There >>> is risk that it may break hvmloader even if it is turned off. >>> >>> I would need at least some positive test results from you to confirm if >>> this feature is turned off everything works as before. >>> >> >> Could you show what sort of test you need here? I just did boot a VM without >> any RDM parameters. I just think maybe someone had this good experience to >> check this. >> > > Yes, this is the basic test I need -- at least booting a VM with RDM > off. > > Feel free to do more tests and report back if you have time. > > Wei. > >> Thanks >> Tiejun > >