> Am 27.05.2015 um 17:57 schrieb Aurelien Jarno <aurel...@aurel32.net>: > >> On 2015-05-27 07:31, Richard Henderson wrote: >>> On 05/26/2015 03:03 PM, Aurelien Jarno wrote: >>> Ok, I understand now. That said I don't see how implementing STFLE will >>> break that. I think it will actually improve things by enabling more >>> facilities and thus making the kernel happier (but maybe not enough). >> >> Somewhat amusingly, by not implementing STFLE we bypass this check. > > Oh, I see the whole picture now. > >>>> #elif defined(CONFIG_MARCH_Z990) >>>> .long 1, 0xc0002000 >>> >>> For this one we only miss one instruction in the LD facility. I have it >>> on my TODO list, though it might take a few weeks until it goes to the >>> top. >> >> Which one? > > CVBY, but anyway we don't implement CVB and CVBG either... > > >>>> #elif defined(CONFIG_MARCH_Z900) >>>> .long 1, 0xc0000000 >>> >>> This corresponds to the current value we provide. CONFIG_MARCH_Z900 also >>> correspond to the configuration of the Debian kernel, that's why I am >>> able to boot kernels. >> >> Ah, well that's something. Fedora defaults to z9-109, and I think SuSE does >> the same. > > One strategy would be to enable the bit in STFLE whether the feature is > fully implemented by TCG or not, using the values provided by the CPU > model (IBM patches).
So how about we add a "force" parameter to the -cpu command line option to suppress masking of the facility bits with what tcg implements? > After all we have plenty of non-implemented basic > instructions (e.g. all the HFP ones). The risk is that the userland > starts to use some optimized libraries due to that. On the other hand > if the kernel is compiled with this option, chances are that the > userland is built with the same instruction set. > > Having a quick look at big sets of missing instructions, it looks like > we are mostly missing HFP (most are in the basic instructions), DFP, > high-word, extended translations, and message-security-assist. high-word > facility should be relatively easy to add, extended translation a bit > more complex. We might want to use libdecnumber like on PPC fro DFP. It > looks like the most problematic are therefore HFP (but that's already > the case anyway) and message-security-assist. > > Then there are plenty of facilities with only a few instructions > missing. They might be tricky to implement though (i.e. transactional > memory). On ppc we just fail every transaction which seems to do the trick. Can we do the same for s390? > > One other strategy would be to create a "any" CPU for linux-user and > also offer it to the softmmu mode. I think for softmmu we should stick with real world models, either masked with tcg's implemented facilities or not. In fact, how about instead of masking, we just make -cpu fail on creation if it wants a facility that tcg doesn't implement yet? Then we can hint the user to -cpu ec12,force to make it work nevertheless Alex > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net
