[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.