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

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



On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> On 20.03.2024 14:57, 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.
> 
> While I'd agree if you started with "There's no real need to force ...", I
> still think there is a reason: If one wants to use paravirt interfaces (i.e.
> hypercalls), they would better do so consistently. After all there's also
> no need to use VCPUOP_initialise, yet you're not disabling its use.
> 
> As said in reply to Andrew's reply, besides acting as a sentinel that
> structure instance also acts as a sink for Xen accesses to a vCPU's
> vcpu_info. By removing the check, you switch that from being a safeguard to
> being something that actually has to be expected to be accessed. Unless
> you've audited all uses to prove that no such access exists.

I'm kind of lost in this last paragraph, how is that different than
what currently happens when an HVM vCPU >= 32 is brought up using the
lapic and has no vpcu_info mapped?

Also, from a quick look it seems like sites do check whether vcpu_info
== dummy_vcpu_info, otherwise we would already be in trouble.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.