Re: [RFC PATCH 00/19] GICv4 Support for Xen

[Mykola Kvach <xakep.amatop@xxxxxxxxx>]

Hi Julien,

On Fri, Feb 13, 2026 at 1:48 PM Julien Grall <julien@xxxxxxx> wrote:
>
> Hi Mykola,
>
> On 13/02/2026 11:36, Mykola Kvach wrote:
> > For this reason it may be worth conditionally recommending (or even
> > auto-selecting) `vwfi=native` when direct injection is enabled for a
> > vCPU, so measurements reflect the actual delivery fast-path rather than
> > exit/scheduling overhead.
>
> I don't think this is a straightforward answer. "vwfi=native" is
> beneficial when you have a single vCPU scheduled per pCPU. But if you
> have multiple vCPUs running, then you may impair the overall performance
> of the system as the scheduler will not be able to run another vCPU even
> if the current vCPU is doing nothing (it is waiting for an interrupt).
>
> As a data point, Xen didn't initially trapped WFI/WFE. But we noticed a
> lot of slow down during boot if all the vCPUs for a guest were running
> on the same pCPU. The difference was quite noticeable.
>
> So instead of recommending to always set "vwfi=native", I would consider
> an approach where Xen decides whether WFI/WFE is trapped based on the
> number of vCPUs that can be scheduled on a given pCPU. This could be
> adjusted on demand.

Thanks for the clarification. I agree: recommending vwfi=native
unconditionally is not correct.

What I meant was specifically for benchmarking direct injection in a
1:1 vCPU:pCPU setup (or with vCPUs pinned), where trapping WFI/WFE adds
extra exits and can hide the fast-path benefit.

For general setups with oversubscription, vwfi=trap is the right
default, because it lets Xen schedule another runnable vCPU instead of
leaving a pCPU effectively idle while the guest sits in WFI.

I like your suggestion: make WFI/WFE trapping adaptive based on whether
the current pCPU has other runnable vCPUs.


Best regards,
Mykola