[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfe448f7-0b4e-680d-46a7-33ad25a4c09b@redhat.com>
Date: Wed, 18 May 2022 16:33:48 +0200
From: David Hildenbrand <david@...hat.com>
To: Pierre Morel <pmorel@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc: kvm@...r.kernel.org, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, borntraeger@...ibm.com,
frankja@...ux.ibm.com, cohuck@...hat.com, thuth@...hat.com,
hca@...ux.ibm.com, gor@...ux.ibm.com, wintera@...ux.ibm.com,
seiden@...ux.ibm.com, nrb@...ux.ibm.com
Subject: Re: [PATCH v9 3/3] s390x: KVM: resetting the Topology-Change-Report
On 16.05.22 16:21, Pierre Morel wrote:
>
>
> On 5/12/22 12:01, David Hildenbrand wrote:
>>>>
>>>> I think we prefer something like u16 when copying to user space.
>>>
>>> but then userspace also has to expect a u16, right?
>>
>> Yep.
>>
>
> Yes but in fact, inspired by previous discussion I had on the VFIO
> interface, that is the reason why I did prefer an int.
> It is much simpler than a u16 and the definition of a bit.
>
> Despite a bit in a u16 is what the s3990 achitecture proposes I thought
> we could make it easier on the KVM/QEMU interface.
>
> But if the discussion stops here, I will do as you both propose change
> to u16 in KVM and userland and add the documentation for the interface.
In general, we pass via the ABI fixed-sized values -- u8, u16, u32, u64
... instead of int. Simply because sizeof(int) is in theory variable
(e.g., 32bit vs 64bit).
Take a look at arch/s390/include/uapi/asm/kvm.h and you won't find any
usage of int or bool.
Having that said, I'll let the maintainers decide. Using e.g., u8 is
just the natural thing to do on a Linux ABI, but we don't really support
32 bit ... maybe we'll support 128bit at one point? ;)
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists