Am 23.02.2015 um 13:56 schrieb Christian Borntraeger:
> Am 20.02.2015 um 16:22 schrieb Alexander Graf:
>>
>>
>>
>>> Am 20.02.2015 um 16:00 schrieb Michael Mueller :
>>>
>>> On Fri, 20 Feb 2015 14:54:23 +0100
>>> Alexander Graf wrote:
>>>
>
> +/* machine related properties */
> +typedef
Am 20.02.2015 um 16:22 schrieb Alexander Graf:
>
>
>
>> Am 20.02.2015 um 16:00 schrieb Michael Mueller :
>>
>> On Fri, 20 Feb 2015 14:54:23 +0100
>> Alexander Graf wrote:
>>
+/* machine related properties */
+typedef struct S390CPUMachineProps {
+uint16_t class; /*
On 20.02.15 20:43, Michael Mueller wrote:
> On Fri, 20 Feb 2015 18:50:20 +0100
> Alexander Graf wrote:
>
>>
>>
>>
>>> Am 20.02.2015 um 18:37 schrieb Michael Mueller :
>>>
>>> On Fri, 20 Feb 2015 17:57:52 +0100
>>> Alexander Graf wrote:
>>>
Because all CPUs we have in our list only expose
On Fri, 20 Feb 2015 18:50:20 +0100
Alexander Graf wrote:
>
>
>
> > Am 20.02.2015 um 18:37 schrieb Michael Mueller :
> >
> > On Fri, 20 Feb 2015 17:57:52 +0100
> > Alexander Graf wrote:
> >
> >> Because all CPUs we have in our list only expose 128 bits?
> >
> > Here a STFLE result on a EC12
> Am 20.02.2015 um 18:37 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 17:57:52 +0100
> Alexander Graf 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
On Fri, 20 Feb 2015 17:57:52 +0100
Alexander Graf 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@p57lp59 s390xfac]$ ./s390xfac -b
fac[0] = 0xfbfbfcfff840
fac[1] = 0xffde00
On 20.02.15 16:49, Michael Mueller wrote:
> On Fri, 20 Feb 2015 16:22:20 +0100
> Alexander Graf wrote:
>
Just make this uint64_t fac_list[2]. That way we don't have to track any
messy allocations.
>>>
>>> It will be something like "uint64_t
>>> fac_list[S390_CPU_FAC_LIST_SIZE_
On Fri, 20 Feb 2015 16:22:20 +0100
Alexander Graf wrote:
> >>
> >> Just make this uint64_t fac_list[2]. That way we don't have to track any
> >> messy allocations.
> >
> > It will be something like "uint64_t
> > fac_list[S390_CPU_FAC_LIST_SIZE_UINT64]" and in total 2KB
> > not just 16 bytes
> Am 20.02.2015 um 16:00 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 14:54:23 +0100
> Alexander Graf wrote:
>
>>>
>>> +/* machine related properties */
>>> +typedef struct S390CPUMachineProps {
>>> +uint16_t class; /* machine class */
>>> +uint16_t ga; /* availabil
On Fri, 20 Feb 2015 14:55:32 +0100
Alexander Graf wrote:
> > /**
> > * S390CPUClass:
> > * @parent_realize: The parent class' realize handler.
> > @@ -52,6 +69,11 @@ typedef struct S390CPUClass {
> > void (*load_normal)(CPUState *cpu);
> > void (*cpu_reset)(CPUState *cpu);
> >
On Fri, 20 Feb 2015 14:54:23 +0100
Alexander Graf wrote:
> >
> > +/* machine related properties */
> > +typedef struct S390CPUMachineProps {
> > +uint16_t class; /* machine class */
> > +uint16_t ga; /* availability number of machine */
> > +uint16_t order; /* orde
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu
This patch implements the static part of the s390 cpu class definitions.
It defines s390 cpu models by means of virtual cpu ids (enum) which contain
information on the cpu generation, the machine class, the GA number and
the machine type. The cpu id is used to instantiate a cpu class per cpu
model.
14 matches
Mail list logo
