Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Jul 06, 2015 at 10:46:06PM +0800, Chen, Tiejun wrote:
> On 2015/7/6 22:34, Jan Beulich wrote:
> >>>>On 06.07.15 at 16:29, <george.dunlap@xxxxxxxxxxxxx> wrote:
> >>It sounds like part of the problem here is a matter of domains.
> >>
> >>Jan cares mostly about what happens in the hypervisor.  At the
> >>hypervisor level, there is only the per-device configurations, and he is
> >>keen that rmrrs be "strict" by default, unless there is an explicit flag
> >>to relax it.  (I agree with this, FWIW.)
> 
> I can't understand this point.
> 
> There's no any default flag/policy in the hypervisor level, and the
> hypervisor doesn't do anything to RMRR by itself.
> 
> All actions just take place when xl/xc issue our needed requirements
> according to the rdm setting in .cfg.
> 
> >>
> >>What we've been arguing about is the xl layer -- what settings should
> >>xl/libxl give to the hypervisor, based on what's in the domain config?
> >>
> >>It sounds like Jan doesn't care a great deal about it, and in any case
> >>would defer to the tools maintainers, but that if asked for his advice
> >>he would say that the configuration in xl.cfg should act like all the
> >>other pci device configurations: that you have a domain-wide default
> >>that can be overridden in the per-device setting.
> >>
> >>I.e.:
> >>---
> >>rdm='reserve=strict'
> >>pci=[ '02:0.0', '01:1.1,rdm_reserve=relaxed' ]
> >>---
> >>Would pass "strict" for the first device, and "relaxed" for the second.
> >>
> >>Do I understand you both properly, Jan / Tiejun?
> >
> >Yes for me.
> >
> 
> Looks all guys would like to walk into this way in the case of RMRR, so I
> can follow up this way. ( Maybe the confusion above doesn't matter now? )
> 

FWIW this works for me too. Do remember to update code comment / commit
message when you update your code.

Wei.

> Thanks
> Tiejun

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