qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 08/10] target-s390x: implement STFLE instruction


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 08/10] target-s390x: implement STFLE instruction
Date: Thu, 28 May 2015 03:55:46 +0200


> Am 27.05.2015 um 17:57 schrieb Aurelien Jarno <address@hidden>:
> 
>> 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
> address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]