All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Juergen Gross <jgross@suse.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, keir@xen.org, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [PATCH V3 1/1] expand x86 arch_shared_info to support >3 level p2m tree
Date: Tue, 16 Sep 2014 12:56:17 +0100	[thread overview]
Message-ID: <54182561.6060403@citrix.com> (raw)
In-Reply-To: <54181329.7030000@suse.com>

On 16/09/14 11:38, Juergen Gross wrote:
> On 09/16/2014 12:14 PM, David Vrabel wrote:
>> 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.
> 
> Okay, then I'd come back to V1 of my patches. This is the minimum
> required to be able to boot up a system with Xen and more than 512GB
> memory without having to reduce the Dom0 memory via Xen boot parameter.
> 
> Otherwise the hypervisor built mfn_list mapped into the initial address
> space will be too large.
> 
> And no, I don't think setting the boot parameter is the solution here.
> Dom0 should be usable on a huge machine without special parameters.

Ok. The case where's dom0's p2m format matters is pretty specialized.

>> 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.
> 
> Hmm, do you think we could reserve an area of many GBs for Xen in
> virtual space? I suspect this would be rejected as another "Xen-ism".

alloc_vm_area()

> BTW: the mfn_list_list will still be required to be built as a tree.

The tools could be given the guest virtual address and walk the guest
page tables.

This is probably too much of a difference from the existing ABI to be
worth pursuing at this point.

David

  reply	other threads:[~2014-09-16 11:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09  9:58 [PATCH V3 0/1] support >3 level p2m tree Juergen Gross
2014-09-09  9:58 ` [PATCH V3 1/1] expand x86 arch_shared_info to " Juergen Gross
2014-09-09 10:27   ` Andrew Cooper
2014-09-09 10:49     ` Juergen Gross
2014-09-12 10:31       ` Juergen Gross
2014-09-15  8:29         ` Andrew Cooper
2014-09-15  8:52           ` Juergen Gross
2014-09-15  9:42             ` Jan Beulich
2014-09-15  9:48               ` Juergen Gross
2014-09-15  9:44             ` David Vrabel
2014-09-15  9:52               ` Juergen Gross
2014-09-15 10:30                 ` David Vrabel
2014-09-15 10:46                   ` Juergen Gross
2014-09-15 11:29                     ` Jan Beulich
2014-09-15 14:30                     ` David Vrabel
2014-09-16  3:52                       ` Juergen Gross
2014-09-16 10:14                         ` David Vrabel
2014-09-16 10:38                           ` Juergen Gross
2014-09-16 11:56                             ` David Vrabel [this message]
2014-09-16 12:44                               ` Juergen Gross
2014-09-17  4:25                                 ` Juergen Gross
2014-09-30  8:53   ` Jan Beulich
     [not found]   ` <542A8B93020000780003AE7B@suse.com>
2014-09-30  8:59     ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54182561.6060403@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.