xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Kevin <kevin.tian@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"Wang, Yong Y" <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: Requesting for freeze exception for RMRR
Date: Fri, 17 Jul 2015 09:16:08 +0800	[thread overview]
Message-ID: <55A85758.2010702@intel.com> (raw)
In-Reply-To: <20150714092915.GC4152@zion.uk.xensource.com>

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
>
>

  reply	other threads:[~2015-07-17  1:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13  6:31 Requesting for freeze exception for RMRR Chen, Tiejun
2015-07-13  8:11 ` Jan Beulich
2015-07-13 11:41 ` Wei Liu
2015-07-14  1:27   ` Chen, Tiejun
2015-07-14  9:29     ` Wei Liu
2015-07-17  1:16       ` Chen, Tiejun [this message]
2015-07-17  9:17         ` Wei Liu
2015-07-17  9:24           ` Chen, Tiejun
2015-07-17  9:30             ` Wei Liu
2015-07-17 13:21               ` Wei Liu
2015-07-17 13:43                 ` Jan Beulich
2015-07-17 14:01                   ` Wei Liu
2015-07-17 14:33                     ` Chen, Tiejun
2015-07-17 15:11                     ` Andrew Cooper
2015-07-17 15:26                       ` Chen, Tiejun
2015-07-17 15:32                         ` Wei Liu
2015-07-17 15:37                           ` Chen, Tiejun
2015-07-20  1:14                       ` Tian, Kevin
2015-07-13 13:38 ` Jan Beulich
2015-07-14  0:26   ` Chen, Tiejun
2015-07-14  9:18     ` Jan Beulich
2015-07-14  9:25       ` Ian Campbell
2015-07-14  9:36         ` Jan Beulich
2015-07-14  9:27       ` Chen, Tiejun
2015-07-14  9:38         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A85758.2010702@intel.com \
    --to=tiejun.chen@intel.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=kevin.tian@intel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yong.y.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).