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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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".)

The answer I would give is that defaults should be safe.  That is, the
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 ?

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

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

So the only difference occurs when 1. a guest is configured for device
assginemnt 2. some device on the system (perhaps not the one being
assigned) has an RMRR.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel