Re: [PATCH v2 3/3] tools/xen-ucode: print information about currently loaded ucode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.03.2023 19:01, Sergey Dyasli wrote:
> On Wed, Mar 1, 2023 at 11:31 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 28.02.2023 18:39, Sergey Dyasli wrote:
>>> Add an option to xen-ucode tool to print the currently loaded ucode
>>> version and also print it during usage info.  Print CPU signature and
>>> processor flags as well.  The raw data comes from cpuinfo directory in
>>> xenhypfs and from XENPF_get_cpu_version platform op.
>>
>> While I don't mind the use of the platform-op, I'm little puzzled by the
>> mix. If CPU information is to be exposed in hypfs, can't we expose there
>> everything that's needed here?
>>
>> Then again, perhaps in a different context, Andrew pointed out that hypfs
>> is an optional component, so relying on its presence in the underlying
>> hypervisor will need weighing against the alternative of adding a new
>> platform-op for the ucode-related data (as you had it in v1). Since I'm
>> unaware of a request to switch, are there specific reasons you did?
> 
> Ideal situation would be microcode information in Dom0's /proc/cpuinfo
> updated after late load, since that file already has most of the
> information about the cpu. And the closest thing to /proc is xenhypfs.
> It allows the user to query information directly, e.g.
> 
>     # xenhypfs cat /cpuinfo/microcode-revision
>     33554509
> 
> Which could be used manually or in scripts, instead of relying on
> xen-ucode utility. Though printing the value in hex would be nicer.
> That was my motivation to go hypfs route. In general it feels like cpu
> information is a good fit for hypfs, but agreement on its format and
> exposed values is needed.
> I can always switch back to a platform op if that would be the preference.

I've confirmed with Andrew that I was remembering correctly and he would
not want to see a dependency on hypfs in such a tool. Since it's optional
in the hypervisor, you'd need an alternative source of the same info
anyway, and hence you can as well go just that non-hypfs route.

FTAOD: This isn't to say that some CPU info wouldn't be useful to expose
in hypfs. But that's then an independent task.

Jan