Re: [PATCH v1 00/14] s390x: virtio-mem support

[David Hildenbrand]

On 30.09.24 23:49, Halil Pasic wrote:
> On Fri, 27 Sep 2024 20:29:19 +0200
> David Hildenbrand <david@redhat.com> wrote:
>
> > On 27.09.24 20:20, Halil Pasic wrote:
> > > On Wed, 11 Sep 2024 21:09:27 +0200
> > > David Hildenbrand <david@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