> 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. ** Also affects: debian-installer (Ubuntu Eoan) Importance: Undecided Status: Invalid ** Also affects: glibc (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Eoan) Importance: Low Status: Confirmed ** Also affects: debian-installer (Ubuntu Ff-series) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Ff-series) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Ff-series) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu Ff-series) Importance: Undecided => Medium ** Changed in: qemu (Ubuntu Ff-series) Status: New => Triaged ** Changed in: qemu (Ubuntu Ff-series) Assignee: (unassigned) => Christian Ehrhardt (paelzer) ** Tags added: qemu-20.04 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847806 Title: eoan: ppc64el install on pseries-eoan VM fails to install To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1847806/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs