[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



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?

I meant an example or two of actual concrete uses (ideally the most
common ones) of the rdm parameter and what they mean in practical terms.

What about this?

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

rdm = "type=none,reserve=strict"
or rdm = "type=none,reserve=relaxed"

we don't handle any conflict just to make VM keep running as before. Note this is our default behavior.

#2. If the type options is set with "host",

rdm = "type=host,reserve=strict"
or rdm = "type=host,reserve=relaxed"

All conflict would be handled according to our policies which is introduced by the reserve option as described below.
...


[...]
"none" is the default value and it means we don't check any reserved
regions and then all rdm policies would be ignored.


I'm afraid I still don't understand what the difference between
"rdm=none" and simply not providing an rdm argument at all are.


Currently they're the same case at this point.

As I said previously, this default option is used to communicate inside xl but its still possible to introduce more options in the future, or think about if one day we'd like to set "host" as a default option internally, we still need this explicit option to help user ignore rdm, right? So based on your question I just think at most we can remove this option description in doc file right now, so any concern to this?

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