[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |