Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV vCPUs

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Mar 20, 2024 at 02:06:27PM +0000, Andrew Cooper wrote:
> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path there's no requirement for vcpu_info to be setup 
> > ahead
> > of the bring up.  Note an HVM vCPU can operate normally without making use 
> > of
> > vcpu_info.
> >
> > Restrict the check against dummy_vcpu_info to only apply to PV guests.
> >
> > Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up 
> > vCPUs')
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Thanks for looking into this.  But, do we actually need to force this on
> PV either?

Possibly, having now taken a look at the users it does seem they could
cope with unpopulated vcpu_info_area.

Part of my understanding was that this was some kind of courtesy to PV
guests in order to prevent starting them without a vcpu_info, which
strictly speaking is not mandatory, but otherwise the guest vCPU won't
be able to receive interrupts, not even IPIs.

> The only interesting user of dummy_vcpu_info now is vcpu_info_populate()
> which can cope with any arbitrary vCPU.
> 
> I have a suspicion that we can (now) delete these two checks, delete the
> dummy_vcpu_info object, and use a regular NULL pointer in
> vcpu_info_{populate,reset}(), and in doing so, remove one of the bigger
> pieces of PV-absurdity from Xen.

I was expecting this to be something we can backport.  OTOH removing
the check completely (or even getting rid of dummy_vcpu_info) is not
something that we would want to backport.

I would rather do the removal of dummy_vcpu_info as followup work.

> I can entirely believe that this is only safe to do with Jan's physical
> registration changes in place.

Quite possible.

Thanks, Roger.