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"):
> On 2015/7/7 21:26, Ian Jackson wrote:
> > Is "none" not "hoping the user can ignore the problem" ?
> 
> Its impossible since the hypervisor or tools can't prevent from 
> accessing RDM by a VM. So as I said early, "none" is just suitable to 
> two cases,
> 
> #1. Those devices don't own any RDM
> #2. Guest OS doesn't access RDM
> 
> Compared to other cases, these two cases are more popular in real world 
> and actual usage. So we'd like to keep "none" as a default.

I have read your 00/ description, and these two emails:
 http://lists.xen.org/archives/html/xen-devel/2015-01/msg01580.html
 http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00524.html
I have also reread the documentation you provide in this patch.

I'm afraid I still don't understand why it is safe for the default to
be `none'.  My view is that the default setting should avoid a
possibility of memory corruption or system malfunction.

Your description in the document says this:

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

So you do not recommend the use of `none', however you make it the
default.

I'm afraid also that I don't quite understand the interaction between
none-vs-host on the one hand and strict-vs-relaxed on the other.  The
documentation would suggest that the only difference between
   type=none
and
   type=host,reserve=relaxed
is that the latter may print some extra warning messages.  But the
code appears to do a lot of work to move guest memory about, when
type=none is specified.


Also I don't understand this:

> Its impossible since the hypervisor or tools can't prevent from 
> accessing RDM by a VM. So as I said early, "none" is just suitable to 
> two cases,

Perhaps I am missing something here.

The hypervisor can obviously prevent a VM from accessing RDM by not
setting up a mapping for it.  The problem is then that the VM might
try to make the access anyway, and then crash or malfunction.  But
presumably the VM can be instructed via the E820 or some such not to
access these regions.

For a VM which has been given passthrough access to a device which
does DMA things are more complicated but again I think the hypervisor
and tools should be able to deny accesses using the iommu tables.

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.


Sorry if I'm being dense.

Ian.

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