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@lists.xen.org
http://lists.xen.org/xen-devel
