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

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

I think we should go back here.

> I was involved in the design discussion, and from the very beginning I
> probably saw your plan but misunderstood it.  I wouldn't be surprised if
> some others didn't quite understand what they were agreeing to.
>
> 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.

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.

Thanks
Tiejun

> I don't happen to think these "override" semantics are actually going to
> turn out to be that useful; I do think a "default" semantic would be
> useful.  But I'd be content if the name of the current setting were
> switched to "override" to make the semantics more clear.  We can always
> add in "default" at some later point if we really want.
>
>   -George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel