Re: [Qemu-devel] Re: [PATCHv2] qemu: target library, use it in msix

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Sep 27, 2009 at 02:19:41PM +0200, Avi Kivity wrote:
> On 09/27/2009 02:00 PM, Michael S. Tsirkin wrote:
>> On Sun, Sep 27, 2009 at 01:55:17PM +0200, Avi Kivity wrote:
>>    
>>> On 09/27/2009 01:45 PM, Michael S. Tsirkin wrote:
>>>      
>>>>
>>>>        
>>>>>> Thinking about this some more, this function just says "align a value to
>>>>>> page size". The value might not be a bus address at all, and indeed with
>>>>>> msix use, it is not. Makes sense?
>>>>>>
>>>>>>
>>>>>>            
>>>>> In any case restricting it to unsigned invites truncation.
>>>>>
>>>>>          
>>>> If the value we are aligning fits in 32 bit, so does the aligned value.
>>>>
>>>>        
>>> It's perfectly reasonable to call a such a function with a
>>> target_ulong_t
>>>      
>> [mst@tuck qemu]$ grep -rIi target_ulong_t .
>> [mst@tuck qemu]$
>>
>> ?
>>
>>    
>
> target_ulong.
>
>>> or target_phys_addr_t input and expect it to work.
>>>      
>> Not if it's called target_page_align32 :)
>>    
>
> You generally don't know the size of quantities you align.
>
>>> How would the caller know what size argument they have?  They usually
>>> have a target_phys_addr_t or a target_ulong_t.
>>>      
>> In practice, the only user is now msix and it does not.  It has 0x1000
>> as a constant parameter.  For target_phys_addr_t users if we ever have
>> them, we'll just add target_phys_page_align. Generally it's unusual for
>> devices to care about size of target physical page.
>>    
>
> I'd fill better with uint64_t, at least that won't truncate.

Doesn't naming it target_page_align32 address this concern?

> -- 
> Do not meddle in the internals of kernels, for they are subtle and quick to panic.