On Fri, 4 Dec 2020 09:46:31 +0100 Cédric Le Goater <c...@kaod.org> wrote:
> >> I don't think we need much more than patch 1 which clarifies the > >> nature of the values being manipulated, quantities vs. numbering. > >> > >> The last 2 patches are adding complexity to try to optimize the > >> XIVE VP space in a case scenario which is not very common (vSMT). > >> May be it's not worth it. > >> > > > > Well, the motivation isn't about optimization really since > > a non-default vSMT setting already wastes VP space because > > of the vCPU spacing. > > I don't see any VPs being wasted when not using vSMT. What's > your command line ? > I think there's confusion here. VSMT is always being used. When you don't specify it on the command line, the machine code sets it internally for you to be equal to the number of threads/core of the guest. Thanks to that, you get consecutive vCPU ids and no VP waste. Of course, you get the same result if you do: -M pseries,vsmt=N -smp threads=N If you pass different values to vsmt and threads, though, you get the spacing and the VP waste. > > This is more about not using values > > with wrong semantics in the code to avoid confusion in > > future changes. > > yes. > > > I agree though that the extra complexity, especially the > > compat crust, might be excessive. > > It's nice and correct but it seems a bit like extra noise > if the default case is not wasting VPs. Let's check that > first. > > > So maybe I should just > > add comments in the code to clarify when we're using the > > wrong semantics ? > > yes. I think this is enough. > I'll do this in v3 then. > Thanks, > > C.