Having read all these docs I now know what all the options are, but I
still don't really know what I should write. I think an example or two
of real world usage would be helpful.
Here I picked some code fragments to help you understand this,
I meant an example or two in the documentation.
The code fragment didn't answer my question either, but that's not
really the point.
Do you mean I should write two example, respectively?
#1. What is one actual conflict?
#2. After we're trying to fix this conflict,
#2.1 How will "strict" fail a VM?
#2.2 How will "relaxed" impact on a VM?
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.
Thanks
Tiejun
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
