qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU


From: Michael Mueller
Subject: Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
Date: Fri, 20 Feb 2015 20:43:03 +0100

On Fri, 20 Feb 2015 18:50:20 +0100
Alexander Graf <address@hidden> wrote:

> 
> 
> 
> > Am 20.02.2015 um 18:37 schrieb Michael Mueller <address@hidden>:
> > 
> > On Fri, 20 Feb 2015 17:57:52 +0100
> > Alexander Graf <address@hidden> 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?
> 
> If that model has 3 elements, yes, the array should span 3.
> 
> I hope it's in the list. Every model wecare about should be, no?
> 

On my list? Yes!

> > 
> > address@hidden 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?
> 
> Only internally in QEMU. The kvm interface should definitely be as big as the 
> spec allows!

Right, now we're on the same page again. That can be taken in consideration. 
... Although it's
just and optimization. :-)

Michael

> 
> Alex
> 
> > 
> > Thanks
> > Michael
> > 
> 




reply via email to

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