All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hongyan Xia <hx242@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: julien@xen.org, "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 04/16] x86/srat: vmap the pages for acpi_slit
Date: Mon, 30 Nov 2020 18:11:38 +0000	[thread overview]
Message-ID: <8118aa61528cb14acab8a399bd483557bd3c921e.camel@xen.org> (raw)
In-Reply-To: <d41fee35-8889-3ab8-2a5e-f4b442747362@suse.com>

On Mon, 2020-11-30 at 11:16 +0100, Jan Beulich wrote:
> On 30.04.2020 22:44, Hongyan Xia wrote:
> > --- a/xen/arch/x86/srat.c
> > +++ b/xen/arch/x86/srat.c
> > @@ -196,7 +196,8 @@ void __init acpi_numa_slit_init(struct
> > acpi_table_slit *slit)
> >  		return;
> >  	}
> >  	mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
> > -	acpi_slit = mfn_to_virt(mfn_x(mfn));
> > +	acpi_slit = vmap_boot_pages(mfn, PFN_UP(slit->header.length));
> > +	BUG_ON(!acpi_slit);
> >  	memcpy(acpi_slit, slit, slit->header.length);
> >  }
> 
> I'm not sure in how far this series is still to be considered
> active / pending; I still have it in my inbox as something to
> look at in any event. If it is, then I think the latest by this
> patch it becomes clear that we either want to make vmalloc()
> boot-allocator capable, or introduce e.g. vmalloc_boot().
> Having this recurring pattern including the somewhat odd
> vmap_boot_pages() is imo not the best way forward. It would
> then also no longer be necessary to allocate contiguous pages,
> as none of the users up to here appear to have such a need.

This series is blocked on the PTE domheap conversion series so I will
definitely come back here after that series is merged.

vmap_boot_pages() (poorly named, there is nothing "boot" about it) is
actually useful in other patches as well, especially when there is no
direct map but we need to map a contiguous range, since
map_domain_page() can only handle a single one. So I would say there
will be a need for this function (maybe call it vmap_contig_pages()?)
even if for this patch a boot-capable vmalloc can do the job.

Hongyan



  reply	other threads:[~2020-11-30 18:12 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 20:44 [PATCH 00/16] Remove the direct map Hongyan Xia
2020-04-30 20:44 ` [PATCH 01/16] x86/setup: move vm_init() before acpi calls Hongyan Xia
2020-04-30 20:44 ` [PATCH 02/16] acpi: vmap pages in acpi_os_alloc_memory Hongyan Xia
2020-05-01 12:02   ` Wei Liu
2020-05-01 12:46     ` Hongyan Xia
2020-05-01 21:35   ` Julien Grall
2020-05-04  8:27     ` Hongyan Xia
2020-04-30 20:44 ` [PATCH 03/16] x86/numa: vmap the pages for memnodemap Hongyan Xia
2020-04-30 20:44 ` [PATCH 04/16] x86/srat: vmap the pages for acpi_slit Hongyan Xia
2020-11-30 10:16   ` Jan Beulich
2020-11-30 18:11     ` Hongyan Xia [this message]
2020-12-01  7:37       ` Jan Beulich
2020-04-30 20:44 ` [PATCH 05/16] x86: map/unmap pages in restore_all_guests Hongyan Xia
2020-04-30 20:44 ` [PATCH 06/16] x86/pv: domheap pages should be mapped while relocating initrd Hongyan Xia
2020-04-30 20:44 ` [PATCH 07/16] x86/pv: rewrite how building PV dom0 handles domheap mappings Hongyan Xia
2020-04-30 20:44 ` [PATCH 08/16] x86: add Persistent Map (PMAP) infrastructure Hongyan Xia
2020-04-30 20:44 ` [PATCH 09/16] x86: lift mapcache variable to the arch level Hongyan Xia
2020-04-30 20:44 ` [PATCH 10/16] x86/mapcache: initialise the mapcache for the idle domain Hongyan Xia
2020-04-30 20:44 ` [PATCH 11/16] x86: add a boot option to enable and disable the direct map Hongyan Xia
2020-05-01  8:43   ` Julien Grall
2020-05-01 12:11   ` Wei Liu
2020-05-01 12:59     ` Hongyan Xia
2020-05-01 13:11       ` Wei Liu
2020-05-01 15:59         ` Julien Grall
2020-04-30 20:44 ` [PATCH 12/16] x86/domain_page: remove the fast paths when mfn is not in the directmap Hongyan Xia
2020-04-30 20:44 ` [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map Hongyan Xia
2020-05-01  8:50   ` Julien Grall
2021-04-22 12:31   ` Jan Beulich
2021-04-28 11:04     ` Hongyan Xia
2021-04-28 11:51       ` Jan Beulich
2021-04-28 13:22         ` Hongyan Xia
2021-04-28 13:55           ` Jan Beulich
2020-04-30 20:44 ` [PATCH 14/16] x86/setup: leave early boot slightly earlier Hongyan Xia
2020-04-30 20:44 ` [PATCH 15/16] x86/setup: vmap heap nodes when they are outside the direct map Hongyan Xia
2020-04-30 20:44 ` [PATCH 16/16] x86/setup: do not create valid mappings when directmap=no Hongyan Xia
2020-05-01 12:07 ` [PATCH 00/16] Remove the direct map Wei Liu
2020-05-01 13:53   ` Hongyan Xia
2020-06-02  9:08     ` Wei Liu
2021-04-28 10:14       ` Hongyan Xia

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=8118aa61528cb14acab8a399bd483557bd3c921e.camel@xen.org \
    --to=hx242@xen.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.