Linux Virtualization - Aug 2020 - [PATCH 1/4] vdpa: introduce config op to get valid iova range

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 at
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

>

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 at
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.


> 
> >

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 at
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


>
>
>