Re: [PATCH] x86/PV: use altcall for I/O emulation quirk hook

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.01.2024 18:31, Andrew Cooper wrote:
> On 16/01/2024 4:58 pm, Jan Beulich wrote:
>> This way we can arrange for ioemul_handle_proliant_quirk()'s ENDBR to
>> also be zapped. Utilize existing data rather than introducing another
>> otherwise unused static variable (array); eventually (if any new quirk
>> was in need of adding) we may want to use .callback and .driver_data
>> anyway.
>>
>> For the decision to be taken before the 2nd alternative patching pass,
>> the initcall needs to become a pre-SMP one.
>>
>> While touching this code, also arrange for it to not be built at all
>> when !PV - that way the respective ENDBR won't be there from the
>> beginning.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Obviously the file may want moving to pv/ then. I wasn't sure whether
>> to also fold doing so right into here.
> 
> For PVH dom0, we allow almost blanket IO port access.  We could do the
> same for PV dom0 by setting up a suitable TSS IO port bitmap.
> 
> That said, x86-S is soon to revoke the ability to do that, so maybe we
> just save ourselves the work...
> 
> 
> I'm confused about "rather than introducing another otherwise unused
> static variable (array)".  Why an array?

(Again) in anticipation of there being a need for another such quirk.
Imo that would have been only consistent with the use of a function
pointer. However, ...

> In this instance, you could use the same trick as the ctxt switch mask. 
> Whether we match DMI or not, it's safe to clobber the ENDBR.  We could
> also consider a __{read_mostly,ro_after_init}_cf_clobber sections.
> 
> 
> However, it's probably better still to have a `bool prolient_quirk` and
> a direct call.  No extra vendor hooks have been added since this was
> introduced in 2007, and I really don't foresee this changing in the near
> future.  Lets just simplify it and drop all the alternatives/clobbering
> games entirely.

... I've now done this. Will send a v2 soon.

Jan