qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 13/28] accel/tcg: Pass down max_cpus to tcg_init


From: Alex Bennée
Subject: Re: [PATCH v3 13/28] accel/tcg: Pass down max_cpus to tcg_init
Date: Tue, 08 Jun 2021 16:44:11 +0100
User-agent: mu4e 1.5.13; emacs 28.0.50

Richard Henderson <richard.henderson@linaro.org> writes:

> Start removing the include of hw/boards.h from tcg/.
> Pass down the max_cpus value from tcg_init_machine,
> where we have the MachineState already.
>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
<snip>
> -static size_t tcg_n_regions(void)
> -{
> +    /*
> +     * It is likely that some vCPUs will translate more code than others,
> +     * so we first try to set more regions than max_cpus, with those regions
> +     * being of reasonable size. If that's not possible we make do by evenly
> +     * dividing the code_gen_buffer among the vCPUs.
> +     */
>      size_t i;
>

heh TIL. That said currently this "fancy" allocation method does nothing
for user-mode code generation which just gets to share one big code gen
buffer.

Thinking aloud I do recall an alternative approach is to have regions
more closely aligned with the guest memory map with a region lock which
any thread can acquire when it needs generate code for the guest region.

In user-mode for example that would be a region per DSO. In system mode
it may be simpler to have the current per-vCPU layout but consider if
all kernel mode code is generated in one buffer and can patch jumps
within that region? Of course any TLB flush that hits code in that
region would force regeneration of all that code but it shouldn't happen
for kernel mode code.

Anyway random musings aside:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>


-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]