Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.05.17 at 09:42, <julien.grall@xxxxxxx> wrote:
> On 15/05/2017 08:20, Jan Beulich wrote:
>> Having thought about this some more, what's still missing is a
>> clear explanation why this new need of a non-stub mfn_to_gmfn()
>> isn't finally enough of a reason to introduce an M2P on ARM. We
>> currently have several uses already which ARM fakes one way or
>> another:
>> - gnttab_shared_gmfn()
> 
> This does not use mfn_to_gmfn on ARM.

Right, at the price of maintaining some other helper data.

>> - gnttab_status_gmfn()
> 
> gnttab_status_gmfn() returns 0 so far. I have to look at this one.
> 
>> - memory_exchange()
> 
> Memory exchange does not work on ARM today and will require more work 
> than that. When I looked at the code a couple of years ago, it was 
> possible to drop the call to mfn_to_gmfn().
> 
>> - getdomaininfo()
> 
> We could rework to store the gmfn in arch_domain.

Which again would mean you maintain extra data in order to avoid
the more general M2P.

>> With this I think there's quite a bit of justification needed to keep
>> going without M2P on ARM.
> 
> As said in a previous thread, I made a quick calculation, ARM32 supports 
> up 40-bit PA and IPA (e.g guest address), which means 28-bits of 
> MFN/GFN. The GFN would have to be stored in a 32-bit for alignment, so 
> we would need 2^28 * 4 = 1GiB of virtual address space and potentially 
> physical memory. We don't have 1GB of VA space free on 32-bit right now.

How come? You don't share address spaces with guests.

> ARM64 currently supports up to 48-bit PA and 48-bit IPA, which means 
> 36-bits of MFN/GFN. The GFN would have to be stored in 64-bit for 
> alignment, so we would need 2^36 * 8 = 512GiB of virtual address space 
> and potentially physical memory. While virtual address space is not a 
> problem, the memory is a problem for embedded platform. We want Xen to 
> be as lean as possible.

You don't need to allocate all 512Gb, the table can be as sparse as
present memory permits.

> So the M2P is not a solution on ARM. A better approach is to drop those 
> calls from common code and replace by something different (as we did for 
> gnttab_shared_mfn).

I'm of the exact opposite opinion. Or at the very least, have a mode
(read: config or command line option) where ARM maintains M2P and
make features like the IOMMU one here depend on being in that mode.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel