On 22/05/2023 8:31 am, Jan Beulich wrote: > On 19.05.2023 17:52, Andrew Cooper wrote: >> On 17/05/2023 10:20 am, Jan Beulich wrote: >>> On 16.05.2023 21:31, Andrew Cooper wrote: >>>> On 16/05/2023 3:53 pm, Jan Beulich wrote: >>>>> I guess that's no >>>>> different from other max-only features with dependents, but I wonder >>>>> whether that's good behavior. >>>> It's not really something you get a choice over. >>>> >>>> Default is always less than max, so however you choose to express these >>>> concepts, when you're opting-in you're always having to put information >>>> back in which was previously stripped out. >>> But my point is towards the amount of data you need to specify manually. >>> I would find it quite helpful if default-on sub-features became available >>> automatically once the top-level feature was turned on. I guess so far >>> we don't have many such cases, but here you add a whole bunch. >> I'm not suggesting specifying it manually. That would be a dumb UX move. >> >> But you absolutely cannot have "user turns on EIBRS" meaning "turn on >> ARCH_CAPS too", because a) that requires creating the reverse feature >> map which is massively larger than the forward feature map, and b) it >> creates a vulnerability in the guest, and c) it's ambiguous - e.g. what >> does turning on a sub-mode of AVX-512 mean for sibling sub-modes? > Feels like a misunderstanding at this point, because what you're describing > above is not what I was referring to. Instead I was specifically referring > to "cpuid=...,arch-caps" not having any effect beyond the turning on of the > MSR itself (with all-zero content). This is even worse with libxl not even > having a way right now to express something like "arch-caps=..." to enable > some of the sub-features for guests.
We discussed this on the x86 call. In summary: Right now, arch-caps is off-by-default because it doesn't work safely or nicely. I'm working on safely first, and nicely will come second. The end result of my work is going to have arch-caps active by default and supported. End users aren't going to in a position of needing to specify cpuid="...,arch-caps" in their config files. Fixing libxl's ability to specify the contents is something needing to be done before we can say arch-caps is fully supported, because right now it's the only way users of xl/libxl have for levelling a VM for migrate. > To explicitly answer the AVX512 part of your reply: Turning on a sub-mode > alone could be useful as well (with the effect of also turning on the > main feature, and with or without [policy question] also turning on other > default-on subfeatures of AVX512). But again - that direction of possible > "implications" isn't what my earlier reply was about. As you say, reverse > maps would then also be needed, whereas for what I'm suggesting only the > deep-deps we already have are necessary: We'd grab the main feature's > dependencies and AND that with the default mask before ORing into the > domain's policy. Having discussed this, I agree and specifically have an idea for how to use it for AVX512. But it is also going to take a fair amount of rearranging in libxl/libxc to make work. I.e., yes, but not immediately right now. ~Andrew
