From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>,
Einar Lueck <elelueck@linux.vnet.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Andreas Faerber <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 1/4] s390: sclp base support
Date: Wed, 26 Sep 2012 18:06:33 +0200 [thread overview]
Message-ID: <50632809.7030607@de.ibm.com> (raw)
In-Reply-To: <8040B9CD-C9FA-4FE6-B9A6-7B076B9D80CA@suse.de>
On 26/09/12 17:00, Alexander Graf wrote:
>> +/* Provide information about the configuration, CPUs and storage */
>> +static void read_SCP_info(SCCB *sccb)
>> +{
>> + ReadInfo *read_info = (ReadInfo *) sccb;
>> + int shift = 0;
>> +
>> + while ((ram_size >> (20 + shift)) > 65535) {
>> + shift++;
>> + }
>> + read_info->rnmax = cpu_to_be16(ram_size >> (20 + shift));
>> + read_info->rnsize = 1 << shift;
>
> Any reason we can't just always expose rnmax2 and rnsize2 instead? This way we're quite limited on the amount of RAM we can support, right?
Well, we have 65535 * 256 * 1MB == 16TB which is ok for the next 2 or 3 years I guess.
There are actually some rules that decide about rnmax vs rnmax2 etc, and here
the non-2 are appropriate. This might change for systems > 16TB or systems with memory hotplug,
but I would prefer to use those for now. We will add the full logic in case we add memory
hotplug.
[...]
>> + if (be16_to_cpu(work_sccb.h.length) < 8 ||
>
> sizeof(SCCBHeader)
ok
>
>> + be16_to_cpu(work_sccb.h.length) > 4096) {
>
> SCCB_SIZE
ok
>> */
>> -int sclp_service_call(CPUS390XState *env, uint32_t sccb, uint64_t code)
>> +int sclp_service_call(uint32_t sccb, uint64_t code)
>
> Why not move the whole thing into sclp.c? The only thing remaining here are a few sanity checks that would just as well work in generic sclp handling code, right?
The idea was two-fold:
- to have one single place were we cross between target-s390x and hw (review feedback from the first series, originally we had all everything in sclp.c)
- to have the checks that the CPU can do over there and the complex things that look into the sccb in sclp.c
But we could certainly move that, your take
Christian
next prev parent reply other threads:[~2012-09-26 16:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-20 14:28 [Qemu-devel] [PATCH 0/4 v4] s390: sclp patch set Jens Freimann
2012-08-20 14:28 ` [Qemu-devel] [PATCH 1/4] s390: sclp base support Jens Freimann
2012-09-26 15:00 ` Alexander Graf
2012-09-26 16:06 ` Christian Borntraeger [this message]
2012-09-26 19:01 ` Alexander Graf
2012-09-26 19:25 ` Christian Borntraeger
2012-09-26 19:27 ` Alexander Graf
2012-08-20 14:28 ` [Qemu-devel] [PATCH 2/4] s390: sclp event support Jens Freimann
2012-08-20 14:28 ` [Qemu-devel] [PATCH 3/4] s390: sclp signal quiesce support Jens Freimann
2012-08-20 14:28 ` [Qemu-devel] [PATCH 4/4] s390: sclp ascii console support Jens Freimann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50632809.7030607@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=cornelia.huck@de.ibm.com \
--cc=elelueck@linux.vnet.ibm.com \
--cc=graalfs@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).