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?
Attachment:
signature.asc
Description: PGP signature
