From: Heiko Carstens <hca@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
Janosch Frank <frankja@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region
Date: Mon, 27 Jul 2020 13:15:46 +0200 [thread overview]
Message-ID: <20200727111546.GA13770@osiris> (raw)
In-Reply-To: <520ac822-df67-b33a-378f-a8f91a3bed2f@redhat.com>
On Mon, Jul 27, 2020 at 12:12:02PM +0200, David Hildenbrand wrote:
> >>>> +#define DIAG500_DEVICE_MEMORY_REGION 4
> >>>
> >>> Regardless what we end up with, this needs to be specified
> >>> somewhere(tm).
> >>
> >> Yeah, there, we should also document the existing subcodes. What would
> >> be the right place for this? The kernel feels somewhat wrong to me.
> >
> > The still supported subcode 3 is properly specified in the virtio spec.
> > That's not a good place for that new one, though.
> >
> > QEMU is probably a better place than the kernel to specify stuff,
> > although it's not really ideal, either. OTOH, do we ever expect other
> > hypervisors to implement this new subcode?
>
> cloud-hypervisor implements virtio-mem. If it were ever to support s390x
> (guess it does not yet), it would also want to implement that one. But
> then, it can just look at QEMU doc I guess :)
It must be well defined and easy to find also for kernel developers
who actually have to care about memory detection code :)
next prev parent reply other threads:[~2020-07-27 11:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 14:37 [PATCH RFCv3 0/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 1/9] s390x: move setting of maximum ram size to machine init David Hildenbrand
2020-07-27 9:13 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 2/9] s390x/diag: no need to check for PGM_PRIVILEGED in diag308 David Hildenbrand
2020-07-27 9:14 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 3/9] s390x: remove hypercall registration mechanism David Hildenbrand
2020-07-27 9:24 ` Cornelia Huck
2020-07-27 9:29 ` David Hildenbrand
2020-07-27 9:48 ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 4/9] s390x: prepare for more diag500 hypercalls David Hildenbrand
2020-07-27 9:42 ` Cornelia Huck
2020-07-27 10:45 ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 5/9] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region David Hildenbrand
2020-07-27 9:48 ` Cornelia Huck
2020-07-27 9:52 ` David Hildenbrand
2020-07-27 10:09 ` Cornelia Huck
2020-07-27 10:12 ` David Hildenbrand
2020-07-27 11:15 ` Heiko Carstens [this message]
2020-07-27 12:02 ` David Hildenbrand
2020-07-28 7:10 ` Cornelia Huck
2020-07-29 8:57 ` David Hildenbrand
2020-07-29 9:37 ` Cornelia Huck
2020-07-29 9:57 ` David Hildenbrand
2020-07-29 10:13 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 7/9] s390x: prepare device memory address space David Hildenbrand
2020-07-27 9:56 ` Cornelia Huck
2020-07-27 9:57 ` David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 8/9] s390x: implement virtio-mem-ccw David Hildenbrand
2020-07-27 9:58 ` Cornelia Huck
2020-07-27 10:02 ` David Hildenbrand
2020-07-27 10:11 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 9/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-27 10:03 ` Cornelia Huck
2020-07-27 10:04 ` David Hildenbrand
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=20200727111546.GA13770@osiris \
--to=hca@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.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.