On 30.09.24 23:49, Halil Pasic wrote:
On Fri, 27 Sep 2024 20:29:19 +0200
David Hildenbrand <da...@redhat.com> wrote:
On 27.09.24 20:20, Halil Pasic wrote:
On Wed, 11 Sep 2024 21:09:27 +0200
David Hildenbrand <da...@redhat.com> wrote:
Anyway, if we want to proceed with the gitlab project, would it make
sense to create an org for it, so that it doesn't look like David's
personal project?
Frankly, I would prefer making Documentation/virt/kvm/s390/s390-diag.rst
the authoritative documentation on DIAGs.
My train of thought is DIAG 500 is a KVM thing, and KVM is a linux
kernel thing, so it just feels right for the documentatio to
live within the linux source tree.
QEMU/TCG is the proof that KVM is not necessarily involved.
Are you sure that no other OS out there besides Linux implements virtio
on s390x, or would want to implement it? :)
As Christian has pointed out in another thread DIAG 500 is documented
as the KVM hypervisor call, and that made me argue it is a KVM thing.
You are right KVM is not necessarily involved, and neither is QEMU. For
me it is not about the components involved in the visualization, but
about the people, projects and governance.
IMHO this is basically extending the s390 architecture. We are guaranteed
to not collide with the Architecture because DIAG 500 is reserved for
KVM as a project I guess.
That's my understanding. I assume because the CCW virtio machine started
out as KVM-only, documenting that it is "KVM ONLY" may be because of
historical reasons.
I may have missed some of the discussion: what were the benefits
of having this in its separate project/repository?
Having it independent of the implementation.
That is a valid point. But IMHO the benefit of having this independent,
does not justify the churn of having a separate project with its
own governance, and communication infrastructure. And I suppose for an
open(?) specification, one would need those things.
I don't see the need to bring in all that bureaucracy. The original idea
was simple: if QEMU/TCG or QEMU/KVM implement a hypercall (IOW: it was
acked by the s390x maintainers), we document it somewhere.
Implementing something in QEMU and then modifying a KVM document in the
kernel tree sounded odd.
It is a valid question to ask: what if any other hypervisor
(cloud-hypervisor etc.) would want to implement a custom diag500
hypercall, and who would ack it. But I don't really think that we would
have to sort this out this at this point in time.
No strong opinions though. If Christian, Janosch and Claudio are in
favor of a separate "Specifications for open-source virtualization on
s390x (IBM z Systems)" project, I'm fine with it as well.
I'm more than happy if we don't need that. As said, I'm happy to
document wherever people tell me to document.
4 years ago we thought that having a separate repository was a good
idea, maybe it is no longer. In that case, s390x mainters please let me
know what to do :)
--
Cheers,
David / dhildenb
