On 22/01/2020 10:14, Julien Grall wrote: > > > On 22/01/2020 10:01, Sergey Dyasli wrote: >> On 20/01/2020 10:01, Jan Beulich wrote: >>> On 17.01.2020 17:44, Sergey Dyasli wrote: >>>> v2 --> v3: >>>> - Remove hvmloader filtering >>> >>> Why? Seeing the prior discussion, how about adding XENVER_denied to >>> return the "denied" string, allowing components which want to filter >>> to know exactly what to look for? And then re-add the filtering you >>> had? (The help text of the config option should then perhaps be >>> extended to make very clear that the chosen string should not match >>> anything that could potentially be returned by any of the XENVER_ >>> sub-ops.) >> >> I had the following reasoning: >> >> 1. Most real-world users would set CONFIG_XSM_DENIED_STRING="" anyway. >> >> 2. Filtering in DMI tables is not a complete solution, since denied >> string leaks elsewhere through the hypercall (PV guests, sysfs, driver >> logs) as Andrew has pointed out in the previous discussion. >> >> On the other hand, SMBios filtering slightly improves the situation for >> HVM domains, so I can return it if maintainers find it worthy. > > While I am not a maintainer of this code, my concern is you impose the > conversion from "denied" to "" to all the users (include those who wants to > keep "denied").
This is not what's happening here: the default is still "<denied>" (as per patch 1); but patch 2 makes XENVER_extraversion, XENVER_compile_info and XENVER_changeset to return "<denied>" instead of the real values which causes the UI / logs issues. > > If you were doing any filtering in hvmloader, then it would be best if this > is configurable. But this is a bit pointless if you already allow the user to > configure the string at the hypervisor level :). -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
