[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] x86/SVM-IOMMU: Don't opencode memcpy() in queue_iommu_command()



>>> On 24.09.18 at 13:59, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> Sent: 24 September 2018 11:55
>> 
>> @@ -35,12 +34,9 @@ static int queue_iommu_command(struct amd_iommu *iommu,
>> u32 cmd[])
>>                                        IOMMU_CMD_BUFFER_HEAD_OFFSET));
>>      if ( head != tail )
>>      {
>> -        cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
>> -                             (iommu->cmd_buffer.tail *
>> -                             IOMMU_CMD_BUFFER_ENTRY_SIZE));
>> -
>> -        for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
>> -            cmd_buffer[i] = cmd[i];
>> +        memcpy(iommu->cmd_buffer.buffer +
>> +               (iommu->cmd_buffer.tail * IOMMU_CMD_BUFFER_ENTRY_SIZE),
>> +               cmd, IOMMU_CMD_BUFFER_ENTRY_SIZE);
> 
> ...since the built-in memcpy may not guarantee to the copy in 4 byte chunks 
> in ascending order. As long as that change poses no danger (and seeing as the 
> code contains no barrer-ing I'd assume that to be the case) then this change 
> looks fine to me (with the 'no functional change' comment removed).

I don't think the compiler is required to translate the original loop to
accesses of 4 bytes in ascending order, so I think I agree with
Andrew's "no functional change".

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.