[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 04/11] s390/qemu: cpu model cpu facilitiy su
From: |
Michael Mueller |
Subject: |
Re: [Qemu-devel] [PATCH RFC 04/11] s390/qemu: cpu model cpu facilitiy support |
Date: |
Mon, 7 Oct 2013 17:35:17 +0200 |
On Mon, 7 Oct 2013 12:47:53 +0200
Michael Mueller <address@hidden> wrote:
> On Thu, 03 Oct 2013 07:53:02 -0700
> Richard Henderson <address@hidden> wrote:
>
> > On 10/02/2013 04:33 AM, Michael Mueller wrote:
> > > +/* set a specific bit in facility set */
> > > +static void set_facility(unsigned int nr, void *facilities)
> > > +{
> > > + unsigned char *ptr;
> > > +
> > > + if (nr >= MAX_S390_FACILITY_BIT) {
> > > + return;
> > > + }
> > > + ptr = (unsigned char *) facilities + (nr >> 3);
> > > + *ptr |= (0x80 >> (nr & 7));
> > > +}
> >
> > I'd like to see this done in a host endian independent way.
>
> valid point, I will address that.
>
> >
> > See my recent patch set to add facility support to the tcg side
> > of target-s390, with which this patch set is going to conflict.
>
> I saw it, that's why I've pushed this patch set out for RFC.
>
> >
> > Is there a good reason not to compute these facility masks at
> > compile-time? See
> >
> > http://patchwork.ozlabs.org/patch/279534/
> >
> > where I have pre-computed (possibly incomplete) facilities lists
> > for the major cpu revisions.
>
> Your facilities lists have been derived from constants introduced in head.S.
> They represent
> model specific "required" facilities. That does not necessarily mean for all
> of them that they
> have been introduced with the respective model. Some have been introduced
> already with model:
> N-1, GA>1
>
> >
> > It just seems like your facility_availability array is the wrong
> > way to go about things, taking up more memory and startup time
> > than necessary.
> >
>
> The reason why I represent them in the data segment is that they are are not
> considered as
> constants in the s390 system perspective. I plan to be able to simulate
> firmware migration that
> introduce new facility bits without the need of restarting the guest OS.
>
> A second reason for using 2k of memory here is to fully represent the
> facilities as defined
> in the s390x architecture. The SIE state needs it and I want to represent it
> identically in user
> space and KVM. Otherwise I would need a specific interface just for the
> facilities.
>
> I will consider to alternatively use your way of FAC definition, but still
> that would include a
> copy.
>
> In regard to the startup time, I will figure out what the overhead is.
A measurement on a z12EC shows the overhead time to be between 500-800 ns per
model. Currently
28 models are defined that means the whole calculation time takes well below 30
us.
>
> Thanks a lot!
> Michael
> >
> > r~
> >
>
>
[Qemu-devel] [PATCH RFC 05/11] s390/qemu: cpu model alias support, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 02/11] s390/qemu: cpu model extend config device, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 11/11] s390/qemu: cpu model enablement, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 01/11] s390/qemu: cpu modle disable list cpus, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 08/11] s390/qemu: cpu model command line option help, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 09/11] s390/qemu: cpu model QMP query-cpu-definitions, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 07/11] s390/qemu: cpu model class initialization, Michael Mueller, 2013/10/02
[Qemu-devel] [PATCH RFC 10/11] s390/qemu: cpu model QMP query-cpu-model, Michael Mueller, 2013/10/02