Re: [Xen-devel] [v5][PATCH 10/16] tools: introduce some new parameters to set rdm policy

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

> > +"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.
> > +
> One issue didn't come to conclusion during last round of review. Ian was
> asking what's the difference with type=none vs not specifying rdm option
> at all.
>
> You need to either convince Ian or remove "type=none" in *xl* level.
> I.e. don't touch the libxl IDL. It still needs a none type.
I'll update this next revision. And also rephrase this doc to address 
your comments below.
Thanks
Tiejun

> > +For example, you're trying to set "memory = 2800" to allocate memory to one
> > +given VM but the platform owns two RDM regions like,
> > +
> > +RMRR region: base_addr ac6d3000 end_address ac6e6fff
> > +RMRR region: base_addr ad800000 end_address afffffff
> > +
> > +In this conflict case,
> > +
> > +#1. If the type options is set with "none",
> > +
> If B<type> is set to "none", for example,
>
> > +rdm = "type=none,reserve=strict" or rdm = "type=none,reserve=relaxed"
> > +
> > +mean we don't handle any conflict just to make VM keep running as before.
> > +Note this is our default behavior.
> > +
> It means we don't handle any conflict to make VM run as before. This is
> the default behavior.
>
> > +#2. If the type options is set with "host",
> > +
> If B<type> is set to "host", for example,
>
> > +rdm = "type=host,reserve=strict" or rdm = "type=host,reserve=relaxed"
> > +
> > +mean all conflict would be handled according to our policies which is
> > +introduced by the reserve option as described below.
> > +
> It means all conflicts will be handled according to the policy
> introduced by B<reserve> as described below.
>
> > +=item B<reserve="STRING">
> > +
> > +Specifies how to deal with conflicts discovered when reserving reserved device
> > +memory in the guest address space.
> > +
> Specifies how to deal with conflicts when reserving reserved device
> memory in 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;
> > +
> "strict" means VM can't be created, 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.
> > +
> "relaxed" allows VM to be created but may cause VM to crash if
> pass-through device accesses RDM. For exampl,e Windows IGD GFX driver
> always accessed RDM regions so it leads to VM crash.
>
> Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel