xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Julien Grall <julien@xen.org>,
	paul@xen.org, xen-devel@lists.xenproject.org
Cc: "'Stefano Stabellini'" <sstabellini@kernel.org>,
	"'Wei Liu'" <wl@xen.org>,
	"'Andrew Cooper'" <andrew.cooper3@citrix.com>,
	"'Ian Jackson'" <ian.jackson@eu.citrix.com>,
	"'George Dunlap'" <george.dunlap@citrix.com>,
	hongyxia@amazon.com, "'Jan Beulich'" <jbeulich@suse.com>,
	"'Volodymyr Babchuk'" <Volodymyr_Babchuk@epam.com>,
	"'Roger Pau Monné'" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce PGC_state_uninitialised
Date: Mon, 23 Mar 2020 10:55:14 +0000	[thread overview]
Message-ID: <d86994c7fa3bf73136d1caf4999181223d7bdf2c.camel@infradead.org> (raw)
In-Reply-To: <3018bb93-b79c-9182-30cc-364fb59ec2fd@xen.org>


[-- Attachment #1.1: Type: text/plain, Size: 1726 bytes --]

On Mon, 2020-03-23 at 09:34 +0000, Julien Grall wrote:
> For liveupdate, we will need a way to initialize a page but mark it as 
> already inuse (i.e in the same state as they would be if allocated 
> normally).

I am unconvinced of the veracity of this claim.

We don't want to turn specific details of the current Xen buddy
allocator part into of the implicit ABI of live update. That goes for
the power-of-two zone boundaries, amongst other things.

What if Xen receives LU state in which *all* pages in a given zone are
marked as already in use? That's one of the cases in which we *really*
want to pass through init_heap_pages() instead of just
free_heap_pages(), in order to allocate the zone data structures for
the first pages that get freed into that zone.

What if Xen starts to exclude more pages, like the exclusion at zero?

What if new Xen wants to exclude an additional page due to a hardware
erratum? It can't take it away from existing domains (especially if
there are assigned PCI devices) but it could be part of the vetting in
init_heap_pages(), for example.

My intent for PGC_state_uninitialised was to mark pages that haven't
been through init_heap_pages(), whatever init_heap_pages() does in the
current version of Xen.

The pages which are "already in use" because they're inherited through
LU state should be in PGC_state_uninitialised, shouldn't they?

Perhaps if there's a need for a helper, it could be a companion
function to init_heap_pages() which would return a boolean saying,
"nah, I didn't want to do anything to this page anyway", which could
short-circuit it into the PGC_state_inuse state. But I'm not sure I see
the need for such an optimisation. 


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-03-23 10:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 21:17 [Xen-devel] [PATCH 0/2] Handle David Woodhouse
2020-03-19 21:21 ` [Xen-devel] [PATCH 1/2] xen/mm: fold PGC_broken into PGC_state bits David Woodhouse
2020-03-19 21:21   ` [Xen-devel] [PATCH 2/2] xen/mm: Introduce PGC_state_uninitialised David Woodhouse
2020-03-20 13:33     ` Paul Durrant
2020-03-20 13:53       ` Jan Beulich
2020-03-20 15:17       ` David Woodhouse
2020-03-23  8:49         ` Paul Durrant
2020-03-23 10:45           ` David Woodhouse
2020-03-23  9:34         ` Julien Grall
2020-03-23 10:55           ` David Woodhouse [this message]
2020-03-24 10:08             ` Julien Grall
2020-03-24 17:55               ` David Woodhouse
2020-03-24 18:34                 ` Julien Grall
2020-03-31 12:10     ` Jan Beulich
2020-03-20 13:17   ` [Xen-devel] [PATCH 1/2] xen/mm: fold PGC_broken into PGC_state bits Paul Durrant
2020-03-31 12:00   ` Jan Beulich

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=d86994c7fa3bf73136d1caf4999181223d7bdf2c.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=hongyxia@amazon.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).