qemu-devel
[Top][All Lists]
Advanced

[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~
> > 
> 
> 




reply via email to

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