On 22/01/2020 11:25, Julien Grall wrote: > > > On 22/01/2020 11:19, Sergey Dyasli wrote: >> 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. > > I was referring the SMBios filtering... I don't think doing a blank filtering > is the right thing to do in the hvmloader for the reason explained above.
Apologies for misunderstanding the context. But I disagree about hvmloader. Returning "denied" from xen_version hypercall to guests is one thing, but hvmloader and SMBios tables are parts of the hypervisor and putting "denied" there is simply a terrible user experience. > > Regarding CONFIG_XSM_DENIED_STRING, I think this is a good step as it allows > the vendor to configure it. -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel