Messages in this thread | | | Subject | Re: [PATCH 1/4] vdpa: introduce config op to get valid iova range | From | Jason Wang <> | Date | Wed, 12 Aug 2020 10:02:26 +0800 |
| |
On 2020/8/11 下午4:29, Michael S. Tsirkin wrote: > On Tue, Aug 11, 2020 at 10:53:09AM +0800, Jason Wang wrote: >> On 2020/8/10 下午8:05, Michael S. Tsirkin wrote: >>> On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote: >>>> On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote: >>>>> On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote: >>>>>> On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote: >>>>>>> On Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote: >>>>>>>> This patch introduce a config op to get valid iova range from the vDPA >>>>>>>> device. >>>>>>>> >>>>>>>> Signed-off-by: Jason Wang<jasowang@redhat.com> >>>>>>>> --- >>>>>>>> include/linux/vdpa.h | 14 ++++++++++++++ >>>>>>>> 1 file changed, 14 insertions(+) >>>>>>>> >>>>>>>> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h >>>>>>>> index 239db794357c..b7633ed2500c 100644 >>>>>>>> --- a/include/linux/vdpa.h >>>>>>>> +++ b/include/linux/vdpa.h >>>>>>>> @@ -41,6 +41,16 @@ struct vdpa_device { >>>>>>>> unsigned int index; >>>>>>>> }; >>>>>>>> +/** >>>>>>>> + * vDPA IOVA range - the IOVA range support by the device >>>>>>>> + * @start: start of the IOVA range >>>>>>>> + * @end: end of the IOVA range >>>>>>>> + */ >>>>>>>> +struct vdpa_iova_range { >>>>>>>> + u64 start; >>>>>>>> + u64 end; >>>>>>>> +}; >>>>>>>> + >>>>>>> This is ambiguous. Is end in the range or just behind it? >>>>>>> How about first/last? >>>>>> It is customary in the kernel to use start-end where end corresponds to >>>>>> the byte following the last in the range. See struct vm_area_struct >>>>>> vm_start and vm_end fields >>>>> Exactly my point: >>>>> >>>>> include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address >>>>> >>>>> in this case Jason wants it to be the last byte, not one behind. >>>>> >>>>> >>>> Maybe start, size? Not ambiguous, and you don't need to do annoying >>>> calculations like size = last - start + 1 >>> Size has a bunch of issues: can overlap, can not cover the entire 64 bit >>> range. The requisite checks are arguably easier to get wrong than >>> getting the size if you need it. >> Yes, so do you still prefer first/last or just begin/end which is consistent >> with iommu_domain_geometry? >> >> Thanks > I prefer first/last I think, these are unambiguous. > E.g. > > dma_addr_t aperture_start; /* First address that can be mapped */ > dma_addr_t aperture_end; /* Last address that can be mapped */ > > instead of addressing ambiguity with a comment, let's just name the field well.
Ok, will do.
Thanks
> > >
| |