Comment 26 for bug 1847806

> I added TCG support for mffsl, mffscrn, mffscrni, mffsce to QEMU, and I
> think they will appear in QEMU 4.2, which is not yet released.

Yeah I have found these.

> I found that the support for these instructions were missing because of
> my efforts to test work I did for GLibC to use those instructions in
> GLibC 2.30 and GLibC 2.31. It appears that eoan has GLibC 2.30 and has
> hit these instructions.

Yep that is how we hit it.

> Everything I can find says that these instructions exist in DD1 and
> later versions of POWER9.

I'm glad to hear this, having it to work in TCG is nice but not important.
If there would have been HW failing on this glibc would have needed to
be changed.
Thanks for that info.

> > a) do you want us to switch the default emulated CPU to from
> power9_v2.0 to power8_v2.0 (If so we need the answer asap)?
>
> I'm not sure what the decision criteria is here, but I'll try to offer
> some information below.

We are too late anyway, since release is so close and TCG being not
too important won't trigger an ISO respin.

> > b) are there known missing/bad instructions in P9-TCG that we should
> fix by backporting changes?
>
> Making some presumptions...you are looking for how to make QEMU work out
> of the box for a ppc64el TCG guest. I would hazard that there is some
> risk to backporting the instructions to QEMU 4.0, but I can't quantify
> that easily. I think it would be low, but I'm really not that familiar
> with the QEMU code base.
>
> The other consideration is that if you switch the default, you've
> perhaps solved the problem in the default case, but POWER9 support would
> still be broken if somebody tries to use it.

You are right P9 would still be broken, and as I said above for
switching the types it also is too late now.

> It would seem like the most comprehensive solution is to backport.
>
> BUT, I can't speak to whether there are other instructions missing
> between QEMU 4.0 and 4.2. :-/ Maybe Leonardo can better speak to a
> preferred path forward.

Yeah if we can make the backport work without too much
crazyness/effert and potential regression risk then I'd do that.
Looking forward Ubuntu 20.04 will have qemu 4.2 so there it will be good.

@Leonardo - let me know what you think about backporting the mff*
instructions to qemu 4.0.
If it seems easy enough let's do it, otherwise les mark this won't fix
for Eoan and close it with 4.2 for the next Ubuntu release.