From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy Date: Mon, 06 Jul 2015 22:21:43 +0800 Message-ID: <559A8EF7.2000904@intel.com> References: <1435053450-25131-1-git-send-email-tiejun.chen@intel.com> <1435053450-25131-12-git-send-email-tiejun.chen@intel.com> <55933F7C.2050607@intel.com> <5593BBC8.1010402@eu.citrix.com> <5593C063.7000705@intel.com> <5593C7AC.8030901@eu.citrix.com> <5593CC19.9020200@intel.com> <5593EB53.5000601@eu.citrix.com> <559A83E3.7040401@intel.com> <559AA41E020000780008CC14@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559AA41E020000780008CC14@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell , Wei Liu , Ian Jackson , Stefano Stabellini Cc: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> This way of doing things is different than the way we do it with most >>> other options relating to pci devices (e.g., pci_permissive, >>> pci_msitranslate, pci_sieze, &c). All of those options use a "default" >>> semantic: the domain-wide setting takes effect only if it's not set >>> locally. If the syntax looks the same but the semantics is different, >>> many people will be confused. If we're going to have the domain-wide >>> policy override the per-device policy, then the naming should make that >>> clear; for instance, "override=(strict|relaxed|none)", or >>> "strict_override=(1|0)". >> >> Jan, >> >> What about this? >> >> This is involving our policy so please take a look at this as well. > > I don't think the way things get expressed in the domain config > directly relates to what the policy is. How to best express things > in the config I'd really like to leave to the tools maintainers. Did you remember current definitions are from our previous discussion? From froce/try to strict/relaxed ... You're always getting involved so much so we'd better listen what you would say at this point. > >> George, >> >> Actually we don't mean the domain-wide policy always override the >> per-device policy, or the per-device policy always override the >> per-device policy. Here we just take "strict" as the highest priority >> when it conflicts in two cases. As I said previously myself may not >> answer this very correctly but now I can recall or understand that one >> reason is that different devices can share one RMRR entry, so its >> possible that these two or more per-device policies are not same. So we >> need this particular rule which is not same as before. So I still prefer >> to keep our original implementation. >> >> If I'm missing something or wrong, please Jan correct me. > > I don't think I fully understand what you try to describe above; > instead I think the global vs per-device settings should very much > behave just like others (i.e. fallback to global if there is no per- If there's no any explicit per-device setting from .cfg, per-device always has its own default setting, right? > device setting). Furthermore, didn't we settle on not allowing Let's make this clear. Our current implementation is something like what I described in the patch head description, Default per-device RDM policy is 'strict', while default global RDM policy is 'relaxed'. When both policies are specified on a given region, 'strict' is always preferred. Any concern to this? Or still let per-device policy override per-domain policy like others? > pass-through of devices sharing RMRRs unless specifically told > to by the admin (in which case part of what you write above Yes we can ignore this case in current phase. > would seem irrelevant to me)? > I just think when we're arguing current policy, you may have a good suggestion. Thanks Tiejun