Re: [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region

[David Hildenbrand <david@redhat.com>]

On 28.07.20 09:10, Cornelia Huck wrote:
> On Mon, 27 Jul 2020 14:02:47 +0200
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 27.07.20 13:15, Heiko Carstens wrote:
>>> 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 :)  
>>
>> So I'd suggest documenting it in QEMU (docs/specs ...) for now, and
>> referencing it from the relevant Linux patch - other suggestions?
> 
> That's probably the easiest way for now... the kernel's s390-diag.rst
> should also point to it.
> 
> However, I think we really need a central place for definitions that
> are not just a Linux/QEMU interface, but can potentially also be used
> by other hypervisors/guests. Nothing as complicated as an OASIS spec,
> but maybe a git??b project?

Sounds good. Maintainers? I can volunteer (+setup/create initial
version), but would be good to have other QEMU/KVM maintainers there as
well.

-- 
Thanks,

David / dhildenb