[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150220183748.45b32e11@bee>
Date: Fri, 20 Feb 2015 18:37:48 +0100
From: Michael Mueller <mimu@...ux.vnet.ibm.com>
To: Alexander Graf <agraf@...e.de>
Cc: "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Gleb Natapov <gleb@...nel.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andreas Faerber <afaerber@...e.de>,
Richard Henderson <rth@...ddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce
S390 CPU models
On Fri, 20 Feb 2015 17:57:52 +0100
Alexander Graf <agraf@...e.de> wrote:
> Because all CPUs we have in our list only expose 128 bits?
Here a STFLE result on a EC12 GA2, already more than 128 bits... Is that model on the list?
[mimu@...lp59 s390xfac]$ ./s390xfac -b
fac[0] = 0xfbfffffbfcfff840
fac[1] = 0xffde000000000000
fac[2] = 0x1800000000000000
>
> > I want to have this independent from a future machine of the z/Arch. The kernel stores the
> > full facility set, KVM does and there is no good reason for QEMU not to do. If other
> > accelerators decide to just implement 64 or 128 bits of facilities that's ok...
>
> So you want to support CPUs that are not part of the list?
The architecture at least defines more than 2 or 3. Do you want me to limit it to an arbitrary
size?. Only in QEMU or also in the KVM interface?
Thanks
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists