[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 16/22] x86/setup: leave early boot slightly earlier


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 11 Jan 2023 15:34:51 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8mwZanp8D+FPIIeYcPrZURlT8a36AzCP0jEaVSmpmQc=; b=YLqsLxRhOPEq0HvQHskybO9Q6CNnON+udnmV/iR4gJtRy657XiF7iYLUFK4lJGP0fEsXnjbyFxjfJJ+bz2osEVBGJXAwDbFqJT9ZVtUOD9tt8vuHdjcXmPBie9qzIic8Y3uZCr6lHWPNsnSLvBv6NJJ2ZMD3XgZnsp+Mt0jHAkkTJcWfU9/bNGHecvSEHNi/hg2AKwTNchWWC+SqcEejY7XMc5E/6baZvcTf6UeXg3hcwuzEUd+S0V3WS2DdtXuiIp1j13PImLtzL5e9d87CeS+QJ9L++lxWIhcs22/R1234M3PBXeydaa3IUy02Iu7u5F5yQwjjAiOHsNYBblLFdA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KDxzQTkjy38BmcIoA4oe5Udj98+Z3b33bjT+lxvxs88ws5BhmE72rTD5RMvrnHbmRLEBLWQXHvdyMqeQ5LaSNdtJNC9Hql3xUAuZdk+MJudBz6TDetN/zx1fgSG4AexF86oka3If8UlHncsgwBII1u+/rZqEEPg/nROW0ZzuOyqAvVgRTcmEHXB54oUpKdQWf14vIuxvNW3dZY5eV9MaAwgMszecy5BkCypg68BrqRr5uubAZqc1auecC8VP7IQkelsvGuM2tYPV0ph58DCNn1h2+yItahtqa6+fH6BoUPn1NCXP/PqflofKbRAuyFqBDqBWAH8xrD99unKEI9ZoIA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Hongyan Xia <hongyxia@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 11 Jan 2023 14:35:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1648,6 +1648,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>      numa_initmem_init(0, raw_max_page);
>  
> +    /*
> +     * When we do not have a direct map, memory for metadata of heap nodes in
> +     * init_node_heap() is allocated from xenheap, which needs to be mapped 
> and
> +     * unmapped on demand. However, we cannot just take memory from the boot
> +     * allocator to create the PTEs while we are passing memory to the heap
> +     * allocator during end_boot_allocator().
> +     *
> +     * To solve this race, we need to leave early boot before
> +     * end_boot_allocator() so that Xen PTE pages are allocated from the heap
> +     * instead of the boot allocator. We can do this because the metadata for
> +     * the 1st node is statically allocated, and by the time we need memory 
> to
> +     * create mappings for the 2nd node, we already have enough memory in the
> +     * heap allocator in the 1st node.
> +     */

Is this "enough" guaranteed, or merely a hope (and true in the common case,
but maybe not when the 1st node ends up having very little memory)?

> +    system_state = SYS_STATE_boot;
> +
>      if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) )
>      {
>          unsigned long limit = virt_to_mfn(HYPERVISOR_VIRT_END - 1);
> @@ -1677,8 +1693,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      else
>          end_boot_allocator();
>  
> -    system_state = SYS_STATE_boot;

I'm afraid I don't view this as viable - there are assumptions not just in
the page table allocation functions that SYS_STATE_boot (or higher) means
that end_boot_allocator() has run (e.g. acpi_os_map_memory()). You also do
this for x86 only. I think system_state wants leaving alone here, and an
arch specific approach wants creating for the page table allocation you
talk of.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.