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

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

On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
> On 21.03.2024 10:10, Roger Pau Monné wrote:
> > On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 17:29, Roger Pau Monné wrote:
> >>> 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?
> >>
> >> I think this aspect was simply missed back at the time. And I think it
> >> wants mentioning explicitly to justify the change.
> > 
> > OK, I can add to the commit message:
> > 
> > "Note an HVM vCPU can operate normally without making use of
> > vcpu_info, and in fact does so when brought up from the local APIC."
> 
> I'd be fine adding this (or having this added) while committing.
> 
> >> As said in reply to Andrew, I don't think the dummy structure can be got
> >> rid of. Nor can the checks here be (easily) removed altogether, i.e. your
> >> change cannot (easily) be extended to PV as well. Even conditional removal
> >> of the structure in !PV builds would first require all vcpu_info accesses
> >> to gain a suitable conditional. Which may be undesirable, as some of these
> >> may be deemed fast paths.
> > 
> > I didn't intended to do this here, as replied to Andrew.  If we want
> > to get rid of the check for PV also it needs to be done in a different
> > patch, and with a different justification and analysis.
> > 
> >>> Also, from a quick look it seems like sites do check whether vcpu_info
> >>> == dummy_vcpu_info, otherwise we would already be in trouble.
> >>
> >> Such checks exist in code managing vcpu_info, but not - afaics - in places
> >> actually accessing it.

Is there anything else that needs adjusting then, or are you happy to
pick this up and adjust the commit message?

> > Quite possibly, I didn't look that close TBH, since my intention was
> > not to remove dummy_vcpu_info.  I've noticed however that
> > __update_vcpu_system_time() checks for v->vcpu_info_area.map == NULL,
> > which is fine, but shouldn't it also check for v->vcpu_info_area.map
> > == &dummy_vcpu_info, as it's pointless to update the vcpu system time
> > if pointing to the dummy_vcpu_info?
> 
> The check is there to guard against NULL deref. As said, the aspect of a
> vCPU being brought up the "native" way yet then still using its vCPU info
> was, by mistake, neglected earlier on. So yes, such a check could be
> added here, but it isn't strictly necessary as long as we don't avoid
> accessing the dummy structure uniformly everywhere (which, as said, I'm
> not sure we want to do).

I could add such a check in a separate patch, my main concern with
this is not correctness, it's just that we waste cycles updating the
contents of dummy_vcpu_info which is useless.

Thanks, Roger.