All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: vNUMA for PV guest: kernel and toolstack interaction regarding e820_host=1
Date: Fri, 6 Feb 2015 19:42:15 +0000	[thread overview]
Message-ID: <54D51917.9000605@citrix.com> (raw)
In-Reply-To: <20150206193219.GH30821@zion.uk.xensource.com>

On 06/02/15 19:32, Wei Liu wrote:
> Hi all
> 
> I encounter a problem that I would like to get some advice. It's PV
> specific because of the P2M manipulation is only required by PV.
> 
> Current scheme of memory allocation scheme:
> 
> 1. Libxc populate contiguous chunk of pages and fill in initial P2M. The
>    holes in e820 map are in fact filled with pages.
> 
> 2. Guest kernel reads e820 map from Xen and remap pages in e820 holes if
>    there are holes, update P2M as it sees fit. (That is normally true when
>    e820_host=1 is set)
> 
> This is not very ideal for PV vNUMA, because those pages remapped may
> end up in the wrong vnode.
> 
> What I have in mind is:
> 
> 1. Libxc populates pages, but skips e820 holes. The initial P2M is the
>    final P2M guest sees.
> 2. Guest kernel skips remapping. But Linux still needs to setup 1-1
>    mapping for holes.
> 
> In order to avoid misconfiguration, we would need to introduce a new
> feature flag to indicate guest has the ability to skip remapping. Libxc
> will check that feature flag when building domain.
> 
> Does the above scheme make sense?

I really not keen on any additional complexity in PV guest memory setup.
 Particularly as I don't see a long term future for x86 PV guests.  I
also don't think we should bake into the Xen ABI the behaviour of one
particular guest.

Consider how you can fix this purely in the guest.

David

  reply	other threads:[~2015-02-06 19:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-06 19:32 vNUMA for PV guest: kernel and toolstack interaction regarding e820_host=1 Wei Liu
2015-02-06 19:42 ` David Vrabel [this message]
2015-02-06 20:26   ` Wei Liu

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=54D51917.9000605@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=wei.liu2@citrix.com \
    --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.