[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 12:47:53 +0200 |
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.
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