Re: xentrace buffer size, maxcpus and online cpus

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/06/2023 4:37 pm, Olaf Hering wrote:
> Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap <george.dunlap@xxxxxxxxx>:
>
>> I agree; the clear implication is that with smt=0, you might have
>> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
>> need the trace buffer array to be of size 8.
> I see. Apparently some remapping is required to map a cpuid to an index
> into the trace buffer metadata.

The xentrace mapping interface is horrible, and makes a lot of
assumptions which date from the early PV-only days.

If you want to improve things, we've got all the building blocks now for
a much more sane interface.

XENMEM_acquire_resource is a new mapping interface with far more sane
semantics which, amongst other things, will work in PVH guests too.

If we specify a new mapping space of type xentrace, using cpu id's as
the sub-index space (see vmtrace as an example), then you'll remove that
entire opencoded mechanism of passing mfns around, as well as reducing
the number of unstable hypercalls that the xentrace infrastructure uses.

I can talk you through it further if you feel up to tackling this.

~Andrew