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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

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.

~Andrew