Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2015/6/25 20:31, Ian Jackson wrote:
> Tiejun Chen writes ("[v4][PATCH 11/19] tools: introduce some new parameters to set 
> rdm policy"):
> > This patch introduces user configurable parameters to specify RDM
> > resource and according policies,
> ...
> > Global RDM parameter, "type", allows user to specify reserved regions
> > explicitly, e.g. using 'host' to include all reserved regions reported
> > on this platform which is good to handle hotplug scenario. In the future
> > this parameter may be further extended to allow specifying random regions,
> > e.g. even those belonging to another platform as a preparation for live
> > migration with passthrough devices. Instead, 'none' means we have nothing
> > to do all reserved regions and ignore all policies, so guest work as before.
> I think the description in the documentation needs to have more
> user-focused information.  It's not quite clear to me what the
> tradeoffs are of the different options.
I'm trying to improve this section like this,

Currently there are only two valid types:

"host" means all reserved device memory on this platform should be 
checked to reserve regions in this VM's guest address space. This global 
RDM parameter allows user to specify reserved regions explicitly, and 
using "host" includes all reserved regions reported on this platform, 
which is useful when doing hotplug.
"none" is the default value and it means we don't check any reserved 
regions and then all rdm policies would be ignored. Guest just works as 
before and the conflict of RDM and guest address space wouldn't be 
handled, and then this may result in the associated device not being 
able to work or even crash the VM. So if you're assigning this kind of 
device, this option is not recommended unless you can make sure any 
conflict doesn't exist.
=item B<reserve="STRING">

Specifies how to deal with conflicts discovered when reserving reserved 
device memory in the guest address space.
When that conflict is unsolved,

"strict" means this VM can't be created successfully, or the associated 
device can't be attached in the case of hotplug;
"relaxed" allows a VM to be created to keep running with a warning 
message thrown out. But this may crash this VM if this device accesses 
RDM. For example, Windows IGD GFX driver always access these regions so 
this lead to a blue screen to crash VM in such a case.

> (Your use of "random" here is rather information.  You should say
> "arbitrary".)
Fixed.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel