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

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

On 2015/7/8 1:08, Ian Jackson wrote:
> Chen, Tiejun writes ("Re: [v5][PATCH 10/16] tools: introduce some new parameters to set rdm policy"):
>> Its always fine to me but I just think, is it a good time to start to
>> seek another *optional* approach to overturn current design and
>> implementation ? Unless you're very sure we're doing something wrong. I
>> noticed you should be CCed when we posted this associated design.
>
> I don't think I'm trying to overturn the design.  I have read the
> design documents and they don't go into this kind of detail about the
> libxl API and the xl configuration interface.

Understood.

This design just started concerning everything in high level since RMRR 
is complicated, and its hard to go into details at that moment. And in 
fact this is one reason why we posted two RFC revisions. You know, its 
better to finalize that design based on actual codes.

>
> Questions of defaults (and of exact API names) are matters of detail.
>
>    > But then I also don't understand why your comment "the hypervisor
>    > or tools can't prevent from accessing RDM by a VM" explains why
>    > "none" is a good default.
>
>    I mean if you don't set these mappings, these devices can't work at all
>    and then crash VM like IGD passthrough. But I'm also saying we don't
>    pass through any devices in most cases, and those devices which own RDM
>    are very rare. So why should we set 'none' to Xen by default?
>
> (I guess you mean "why _shouldn't we".)

Yeah, this is my typo. (I corrected this on another ensuing email :) )

>
> The answer I would give is that defaults should be safe.  That is, the

safe and efficient to most cases. As I said previously, the RDM problem 
rarely occurs in real world.

> default configuration settings should not lead to uncontrolled memory
> accesses or crashes, even in less common setups.

Yes.

>
> If the default were changed to `host', what would go wrong ?
>

Some behaviors are different.

> AFAICT nothing would change for guests which do not have devices
> assigned at build time (and which haven't had `rdm' set).

This seems not be correct partially.

More precisely, we have two conditions approaching to our policy,

#1. "host" means we always concern all RDMs resided on this host, no 
matter if either you're passing through those devices associated to 
RDMs, or you don't pass though any devices.

#2. "!host" means we just check if we're passing through some devices 
owning RDM. If yes, we would step into our policy just to each 
per-device rdm. If not, nothing is changed.

>
> And, AFACIT, if there are no devices which advertise these RMRRs,
> again, there is no difference.
>

Just see above.

> So the only difference occurs when 1. a guest is configured for device

In the case of "host",  this is not a precondition to handle RDMs. 
Instead, "host" indicates we *always" handle RDM issues.

> assginemnt 2. some device on the system (perhaps not the one being
> assigned) has an RMRR.
>

#2 is right.

Thanks
Tiejun