All of lore.kernel.org
 help / color / mirror / Atom feed
From: Collin Walling <walling@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: thuth@redhat.com, david@redhat.com, qemu-devel@nongnu.org,
	borntraeger@de.ibm.com, qemu-s390x@nongnu.org, rth@twiddle.net
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/3] s390: cpu feature for diagnose 318 andlimit max VCPUs to 247
Date: Tue, 11 Dec 2018 16:12:16 -0500	[thread overview]
Message-ID: <aff40d67-9fcb-43fb-beeb-1dbe7a1e22f3@linux.ibm.com> (raw)
In-Reply-To: <dbabb43d-01e7-d221-a761-ad5a53fd8f94@linux.ibm.com>

On 12/11/18 11:47 AM, Collin Walling wrote:
> On 12/7/18 7:08 AM, Cornelia Huck wrote:
>> On Thu,  6 Dec 2018 17:24:17 -0500
>> Collin Walling <walling@linux.ibm.com> wrote:
>>
>>> Diagnose 318 is a new z14.2 CPU feature. Since we are able to emulate
>>> it entirely via KVM, we can add guest support for earlier models. A
>>> new CPU feature for diagnose 318 (shortened to diag318) will be made
>>> available to guests starting with the zEC12-full CPU model.
>>>
>>> The z14.2 adds a new read SCP info byte (let's call it byte 134) to
>>> detect the availability of diag318. Because of this, we have room for
>>> one less VCPU and thus limit the max VPUs supported in a configuration
>>> to 247 (down from 248).
>>>
>>> Signed-off-by: Collin Walling <walling@linux.ibm.com>.
>>> ---
>>>  hw/s390x/sclp.c                 | 2 ++
>>>  include/hw/s390x/sclp.h         | 2 ++
>>>  target/s390x/cpu.h              | 2 +-
>>>  target/s390x/cpu_features.c     | 3 +++
>>>  target/s390x/cpu_features.h     | 1 +
>>>  target/s390x/cpu_features_def.h | 3 +++
>>>  target/s390x/gen-features.c     | 1 +
>>>  target/s390x/kvm.c              | 1 +
>>>  8 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>
>>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>>> index 8c2320e..594b4a4 100644
>>> --- a/target/s390x/cpu.h
>>> +++ b/target/s390x/cpu.h
>>> @@ -52,7 +52,7 @@
>>>  
>>>  #define MMU_USER_IDX 0
>>>  
>>> -#define S390_MAX_CPUS 248
>>> +#define S390_MAX_CPUS 247
>>
>> Isn't that already problematic if you try to migrate from an older QEMU
>> with all possible vcpus defined? IOW, don't you really need a way that
>> older machines can still run with one more vcpu?
>>
> 
> Good call. I'll run some tests on this and see what happens. I'll report
> here on those results.
> 

Migrating to a machine that supports less vCPUs will report

error: unsupported configuration: Maximum CPUs greater than specified machine type limit

I revisited the code to see if there's a way to dynamically set the max vcpu count based 
on the read scp info size, but it gets really tricky and code looks very complicated.
(Having a packed struct contain the CPU entries whose maximum is determined by hardware
limitations makes things difficult -- but who said s390 is easy? :) )

In reality, do we often have guests running with 248 or even 247 vcpus? If so, I imagine
the performance isn't too significant?

>>>  
>>>  typedef struct PSW {
>>>      uint64_t mask;
>>
> 
> 


-- 
Respectfully,
- Collin Walling

  reply	other threads:[~2018-12-11 21:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 22:24 [Qemu-devel] [PATCH v2 0/3] Guest Support for Diagnose 318 Collin Walling
2018-12-06 22:24 ` [Qemu-devel] [PATCH v2 1/3] s390: linux header sync for diagnose 318 Collin Walling
2018-12-06 22:24 ` [Qemu-devel] [PATCH v2 2/3] s390: cpu feature for diagnose 318 andlimit max VCPUs to 247 Collin Walling
2018-12-07 12:08   ` Cornelia Huck
2018-12-11 16:47     ` [Qemu-devel] [qemu-s390x] " Collin Walling
2018-12-11 21:12       ` Collin Walling [this message]
2018-12-12 11:20         ` David Hildenbrand
2018-12-12 13:41           ` Cornelia Huck
2018-12-12 15:01             ` Collin Walling
2019-01-24  8:11   ` [Qemu-devel] " Christian Borntraeger
2018-12-06 22:24 ` [Qemu-devel] [PATCH v2 3/3] s390: migration and reset support for diagnose 318 Collin Walling
2018-12-07  1:33 ` [Qemu-devel] [PATCH v2 0/3] Guest Support for Diagnose 318 no-reply

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=aff40d67-9fcb-43fb-beeb-1dbe7a1e22f3@linux.ibm.com \
    --to=walling@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.