On 19/06/2023 11:16 am, Olaf Hering wrote:
> Fri, 16 Jun 2023 17:08:25 +0100 Andrew Cooper :
>
>> XENMEM_acquire_resource is a new mapping interface with far more sane
>> semantics which, amongst other things, will work in PVH guests too.
> Does that indicate xentrace will not work in a PVH dom0?
On 19.06.2023 12:13, Olaf Hering wrote:
> Regarding coding style: can this_cpu and per_cpu be used as array index,
> or is a temporary variable required? This would affect the number of
> lines changed in next_record.
I see no reason why it shouldn't be possible to be used. At least as
long as ove
Fri, 16 Jun 2023 17:08:25 +0100 Andrew Cooper :
> XENMEM_acquire_resource is a new mapping interface with far more sane
> semantics which, amongst other things, will work in PVH guests too.
Does that indicate xentrace will not work in a PVH dom0?
I will have a look how XENMEM_acquire_resource is
Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
> 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 have tested the patch below with this cmdline:
conring_
On 16/06/2023 4:37 pm, Olaf Hering wrote:
> Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
>
>> 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. A
Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
> 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 cpu
On Fri, Jun 16, 2023 at 12:52 PM Jan Beulich wrote:
> On 16.06.2023 13:47, Olaf Hering wrote:
> > Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> >
> >> As said before, num_online_cpus() will under-report for the purpose
> >> here, as CPUs may have been brought offline, and may be brought online
On 16.06.2023 13:47, Olaf Hering wrote:
> Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
>
>> As said before, num_online_cpus() will under-report for the purpose
>> here, as CPUs may have been brought offline, and may be brought online
>> again later (independent of the use of "maxcpus=").
>
> It
Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> As said before, num_online_cpus() will under-report for the purpose
> here, as CPUs may have been brought offline, and may be brought online
> again later (independent of the use of "maxcpus=").
It turned out, commit 74584a367051bc0d6f4b96fd360fa7bc
On 30.05.2023 22:06, Olaf Hering wrote:
> Tue, 30 May 2023 10:41:07 +0200 Jan Beulich :
>
>> Using this N would be correct afaict, but that N isn't num_online_cpus().
>> CPUs may have been offlined by the time trace buffers are initialized, so
>> without looking too closely I think it would be num
Tue, 30 May 2023 10:41:07 +0200 Jan Beulich :
> Using this N would be correct afaict, but that N isn't num_online_cpus().
> CPUs may have been offlined by the time trace buffers are initialized, so
> without looking too closely I think it would be num_present_cpus() that
> you're after.
In my tes
On 30.05.2023 09:58, Olaf Hering wrote:
> While looking again through calculate_tbuf_size after a very long time,
> I was wondering why the code uses nr_cpu_ids instead of num_online_cpus.
> In case Xen was booted with maxcpus=N, would it be safe to use N as
> upper limit? I think this would increa
While looking again through calculate_tbuf_size after a very long time,
I was wondering why the code uses nr_cpu_ids instead of num_online_cpus.
In case Xen was booted with maxcpus=N, would it be safe to use N as
upper limit? I think this would increase the per-cpu buffer size for
each active pcpu,
13 matches
Mail list logo
