From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
Collin Walling <walling@linux.ibm.com>,
cornelia.huck@de.ibm.com, cotte@de.ibm.com, mimu@linux.ibm.com,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org, thuth@redhat.com
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v1] s390: guest support for diagnose 318 and limit max VCPUs to 247
Date: Wed, 5 Dec 2018 12:54:29 +0100 [thread overview]
Message-ID: <20181205125429.5134adfd.cohuck@redhat.com> (raw)
In-Reply-To: <c5130ab3-a539-fa1b-37cc-3db3904b3053@de.ibm.com>
On Wed, 5 Dec 2018 09:27:44 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> On 05.12.2018 09:26, David Hildenbrand wrote:
> > On 04.12.18 23:18, Collin Walling wrote:
> >> Add migration and reset support for diagnose 318. This is a new z14 GA2
> >> hardware feature, but we can provide guest support starting with the
> >> zEC12-full CPU model.
> >>
> >> Because new hardware introduces a new facility-availability byte in
> >> the Read SCP Info block, we lose one byte in the CPU entries list
> >> and must limit the maximum VCPUs to 247 (down from 248).
> >
> > This could break setups that upgrade/migrate. At least forward migration
> > can be broken. Do we care about that?
>
> Can we maybe bind this feature and the cpu limit to the 4.0 machine?
I think that would make sense.
> >
> > Can you split off
> >
> > 1. linux-header changes
> > 2. CPU model changes? (introduction and definition of new feature, but
> > not when it is used?)
> >
> >>
> >> Signed-off-by: Collin Walling <walling@linux.ibm.com>
> >> ---
next prev parent reply other threads:[~2018-12-05 11:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 22:18 [Qemu-devel] [PATCH v1] s390: guest support for diagnose 318 and limit max VCPUs to 247 Collin Walling
2018-12-04 22:26 ` Collin Walling
2018-12-05 11:07 ` Cornelia Huck
2018-12-05 14:52 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2018-12-04 23:50 ` [Qemu-devel] " no-reply
2018-12-05 8:26 ` David Hildenbrand
2018-12-05 8:27 ` Christian Borntraeger
2018-12-05 11:54 ` Cornelia Huck [this message]
2018-12-05 11:57 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-12-05 14:58 ` Collin Walling
2018-12-05 8:29 ` [Qemu-devel] " Christian Borntraeger
2018-12-05 14:59 ` Collin Walling
2018-12-05 15:22 ` Cornelia Huck
2018-12-05 15:27 ` [Qemu-devel] [qemu-s390x] " Collin Walling
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=20181205125429.5134adfd.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=cotte@de.ibm.com \
--cc=david@redhat.com \
--cc=mimu@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=thuth@redhat.com \
--cc=walling@linux.ibm.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.