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

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

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.


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.


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.


Xen-devel mailing list



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