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: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 08/10] target-s390x: implement STFLE instruction
Date: Wed, 27 May 2015 17:57:48 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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). 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).

One other strategy would be to create a "any" CPU for linux-user and
also offer it to the softmmu mode.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net



reply via email to

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