re: proposed cpuctl modification

[matthew green <mrg%eterna.com.au@localhost>]

> we just did that).    I guess we could look and skip the update on
> the hyperthread companion cores (pseudo-cores) but that's not what I am
> proposing, partly because I'd have to work out how to do that, but also
> because that by itself would only solve half the problem.

we should do this as well, it should fairly simple.  we already
display the relevant info in "cpuctl identify 0" eg:

hmm, someone seems to have broken this recently?  on my system
i'm seeing cpu0 and cpu16 both reporting:

   cpu0: SMT ID 0
   cpu16: SMT ID 0

via cpuctl, though dmesg has them as:

   cpu0: node 0, package 0, core 0, smt 0
   cpu16: node 0, package 0, core 0, smt 1

> My processor also has 8 cores, with no hyperthreading, where it looks as
> if internally, there's just 2 sets of ucode, one for the first 4, and one
> for the second 4.   Updates of the other 3 of each group find the ucode
> version already installed, and error out.

that's odd, but we should handle it saner.

> So, what I am proposing is to have cpuctl simply ignore EEXIST errors from
> the update the microcode" ioctl. unless the -v option (which already exists)
> is given.

i like this idea.

> --- cpuctl.c	1 Feb 2022 10:45:02 -0000	1.32
> +++ cpuctl.c	2 Mar 2023 21:36:06 -0000
> @@ -247,7 +247,7 @@
>  		cpuset_destroy(cpuset);
>  	}
>  	error = ioctl(fd, IOC_CPU_UCODE_APPLY, &uc);
> -	if (error < 0) {
> +	if (error < 0 && (verbose || errno != EEXIST)) {
>  		if (uc.fwname[0])
>  			err(EXIT_FAILURE, "%s", uc.fwname);
>  		else

this seems odd to me.  verbose should print additional info
but it shouldn't change the actual behaviour here.

eg, if i were to use this with -v on your CPU, i'd want to
have it show it working on cpu0 and cpu4, and EEXIST for
the rest, and this appears that it will exit after cpu1.

feel free to ignore the SMT issue, it's orthogonal to this.

thanks!


.mrg.