Re: [RESEND RFC v2 1/4] KVM: add initial support for KVM_SET_IOREGION

[Jason Wang <jasowang@redhat.com>]

On 2021/2/9 下午10:59, Stefan Hajnoczi wrote:
> On Mon, Feb 08, 2021 at 02:21:35PM +0800, Jason Wang wrote:
>> On 2021/1/30 上午2:48, Elena Afanasova wrote:
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index ca41220b40b8..81e775778c66 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -732,6 +732,27 @@ struct kvm_ioeventfd {
>>>    	__u8  pad[36];
>>>    };
>>> +enum {
>>> +	kvm_ioregion_flag_nr_pio,
>>> +	kvm_ioregion_flag_nr_posted_writes,
>>> +	kvm_ioregion_flag_nr_max,
>>> +};
>>> +
>>> +#define KVM_IOREGION_PIO (1 << kvm_ioregion_flag_nr_pio)
>>> +#define KVM_IOREGION_POSTED_WRITES (1 << kvm_ioregion_flag_nr_posted_writes)
>>> +
>>> +#define KVM_IOREGION_VALID_FLAG_MASK ((1 << kvm_ioregion_flag_nr_max) - 1)
>>> +
>>> +struct kvm_ioregion {
>>> +	__u64 guest_paddr; /* guest physical address */
>>> +	__u64 memory_size; /* bytes */
>>
>> Do we really need __u64 here?
> I think 64-bit PCI BARs can be >4 GB. There is plenty of space in this
> struct to support a 64-bit field.
>
> That said, userspace could also add more ioregions if it needs to cover
> more than 4 GB. That would slow down ioregion lookups though since the
> in-kernel data structure would become larger.
>
> Making it 64-bit seems more future-proof and cleaner than having to work
> around the limitation using multiple ioregions. Did you have a
> particular reason in mind why this field should not be 64 bits?


Nope. Just wonder what's the use case for that.

Thanks