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

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

> [Later:]
> > As I discussed with Campbell we'd like not to expose "none" in xl level
> > since this is equivalent to that case we don't set anything.
> I think this observation of mine applies to the libxl API level too.
Sorry I don't know what I should do at this point.

> > > > Default per-device RDM policy is 'strict', while default global
> > > > RDM policy is 'relaxed'. And the per-device policy would override
> > > > the global policy like others.
> > > I don't think these two sentences can both be true.  If the per-device
> > > policy overrides the global policy, then the per-device policy must
> > > have at least three values: `strict', `relaxed', and `not set'
> > > (implicitly using global policy).
> > Yeah. The per-device policy is first set as the global policy. This
> > behavior is same as other pci option. Please see the last patch,
> OK, then can you please amend the commit message to be true :-).
Sure.

> > > This suggests that the default is "do the dangerous thing".  That
> > > doesn't seem right.
> > As I discussed with Campbell we'd like not to expose "none" in xl level
> > since this is equivalent to that case we don't set anything.
> That's not really an answer to what I have said, I think.
>
> Why is the default the option that the documentation recommends to
> avoid ?
I mean not all devices really needs this option and actually these 
devices are very rare. Currently just IGD GFX needs this consideration 
so we'd like to make "none" as a default value.
> > "none" means we have a chance to work as before since not all devices
> > own RDM. But as I said above this is same as !rdm.
> Are we expecting many existing devices, and existing setups, to break
> if we don't make the default be to ignore the problem ?
If we don't set anything we don't hope you can ignore this existing problem.

Thanks
Tiejun

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