Re: [PATCH V3 1/1] expand x86 arch_shared_info to support >3 level p2m tree

[David Vrabel <david.vrabel@citrix.com>]

On 16/09/14 04:52, Juergen Gross wrote:
> On 09/15/2014 04:30 PM, David Vrabel wrote:
>> On 15/09/14 11:46, Juergen Gross wrote:
>>> So you'd prefer:
>>>
>>> 1) >512GB pv-domains (including Dom0) will be supported only with new
>>>     Xen (4.6?), no matter if the user requires migration to be supported
>>
>> Yes.  >512 GiB and not being able to migrate are not obviously related
>> from the point of view of the end user (unlike assigning a PCI device).
>>
>> Failing at domain save time is most likely too late for the end user.
> 
> What would you think about following compromise:
> 
> We add a flag that indicates support of multi-level p2m. Additionally
> the Linux kernel can ignore the flag not being set either if started as
> Dom0 or if told so via kernel parameter.

This sounds fine but this override should be via the command line
parameter only.  Crash dump analysis tools may not understand the 4
level p2m.

>>> to:
>>>
>>> 2) >512GB pv-domains (especially Dom0 and VMs with direct hw access) can
>>>     be started on current Xen versions, migration is possible only if
>>> Xen
>>>     is new (4.6?)
>>
>> There's also my preferred option:
>>
>> 3) >512 GiB PV domains are not supported.  Large guests must be PVH or
>> PVHVM.
> 
> In theory okay, but not right now, I think. PVH Dom0 is not production
> ready.

I'm not really seeing the need for such a large dom0.

I remain unconvinced that there are sufficient use cases to justify
extending the PV only ABI and increasing complexity of the current
3-level p2m code.

I'm concerned that 4-level p2m support will impact the performance of
guests that do not need the 4 levels.  It may be necessary to use the
alternatives mechanism to select the correct low-level lookup function.

I also think a flat array for the p2m might be better (less complex).
There's plenty of virtual address space in a 64-bit guest to allow for this.

David