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

[David Hildenbrand <david@redhat.com>]

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