Thanks for the review. Both points are the same concern: an unaligned property making mem->start and mem->end unaligned.
This is pre-existing. viommu_add_resv_mem() already performed the le64_to_cpu() reads of mem->start and mem->end before this patch; the patch only adds the bounds check in the walk and moves the existing length check ahead of those reads, so it neither introduces nor widens the unaligned access. And it does not fault on the architectures that build this driver. VIRTIO_IOMMU depends on (ARM64 || X86) (drivers/iommu/Kconfig), and both select HAVE_EFFICIENT_UNALIGNED_ACCESS and read unaligned normal memory without trapping. I tested this on x86-64: with the RESV_MEM property forced to an odd offset so mem->start and mem->end are misaligned, the values are read back correctly with no alignment fault, both with and without this patch (I have not run the same on arm64). The 8-byte property alignment is a device-side requirement; the driver does not need to rely on it, since an unaligned property is still read correctly here. If you would prefer the parser to be alignment-safe regardless, for instance for a UBSAN_ALIGNMENT build, I can convert the device-provided reads to get_unaligned_le64() as a follow-up. Thanks, Yehyeong
