[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150220164944.4eb4eeb3@bee>
Date: Fri, 20 Feb 2015 16:49:44 +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 16:22:20 +0100
Alexander Graf <agraf@...e.de> 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 but I will change it.
>
> Why? Do we actually need that many? This is a qemu internal struct.
How do you know that 2 is a good size?
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...
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