On 1/22/20 11:44 AM, Sergey Dyasli wrote: > On 22/01/2020 10:57, George Dunlap wrote: >> On 1/22/20 10:14 AM, 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"). >>> >>> 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 :). >> >> So there are two things we're concerned about: >> - Some people don't want to scare users with a "<denied>" string >> - Some people don't want to "silently fail" with a "" string >> >> The fact is, in *both cases*, this is a UI problem. EVERY caller of >> this interface should figure out independently what a graceful way of >> handling failure is for their target UI. Any caller who does not think >> carefully about what to do in the failure case is buggy -- which >> includes every single caller today. The CONFIG_XSM_DENIED_STRING is a >> gross hack fallback for buggy UIs. >> >> Now, I don't like to tell other people to do work, and I certainly don't >> plan on fixing hvmloader at the moment, because it's low-priority for >> me. But I do think that having hvmloader detect failure and explicitly >> make a sensible decision is the right thing to do, regardless of the >> availability of CONFIG_XSM_DENIED_STRING to work around buggy callers. > > It's not entirely clear to me what you suggest to do with hvmloader. > Could you elaborate a bit?
Well, basically "think carefully about the user experience and decide what to do". Given your comment in response to Julien, I would think that would mean checking for CONFIG_XSM_DENIED_STRING in hvmloader and replacing it with nothing (or some other indication that's more user-friendly). Perhaps re-submitting your hvmloader patch as a follow-up patch. But as I said, it's just a suggestion. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
