On 7 December 2015 at 10:53, Pavel Fedin <p.fe...@samsung.com> wrote: >> TAGET_PAGE_ALIGN tells us that it *could* be a valid DMA target though. >> The VM model is capable of using that as a page size, which means we >> assume it is and want to generate a fault. > > We seem to have looped back. So... > It is possible to fix this according to this assumption. In this > case we would need to make TARGET_PAGE_BITS a variable. If we are > emulating ancient armv5te, it will be set to 10. For modern targets, > ARMv6 and newer, it will be 12.
You can't just make TARGET_PAGE_BITS a variable, it is used as a compile time constant in a bunch of TCG internal stuff. It would be nice if we didn't require it to be compile time, but it would be a lot of work to fix (especially if you want to avoid it being a performance hit). In any case, that still doesn't fix the problem. On an AArch64 target CPU, TARGET_PAGE_BITS still has to be 12 (for a 4K minimum page size), but the guest and host could still be using 64K pages. So your VFIO code *must* be able to deal with the situation where TARGET_PAGE_BITS is smaller than any alignment that the guest, host or IOMMU need to care about. I still think the VFIO code needs to figure out what alignment it actually cares about and find some way to determine what that is, or alternatively if the relevant alignment is not possible to determine, write the code so that it doesn't need to care. Either way, TARGET_PAGE_ALIGN is not the answer. thanks -- PMM