xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: Tim Deegan <tim@xen.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [PATCH 2 of 4 RFC] xen, pod: Check zero-check pages returned by the balloon driver
Date: Thu, 14 Jun 2012 05:57:38 -0700	[thread overview]
Message-ID: <d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org> (raw)
In-Reply-To: <20120614102808.GI82539@ocelot.phlegethon.org>

> At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
>> +        else if( p2m_is_ram(t) )
>> +        {
>> +            if ( steal_for_cache )
>> +            {
>> +                struct page_info *page;
>> +
>> +                ASSERT(mfn_valid(mfn));
>
> I think this assertion is broken by the paging code, which adds
> paged-out pages to the RAM types.  One fix is to undo that change and
> have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> would be less disruptive to test here for the paged-out and paging
> types.
>
> Cc'ing Andres on the larger question -- do you think we can have
> p2m_is_ram() imply mfn_valid() again?  I'm not sure whether it will make
> things cleaner (or at least move the burden of handling paged-out memory
> into the paging code) or add more boilerplate to paths where the paging
> will be handled after a check for p2m_os_ram().  What do you think?
>

Imho, pages in any of the states of the paging state machine, are ram.
They are not mmio, grants or whatever. They just happen to be absent at
the moment.

This is not an immediately useful response because its corollary entails
that PoD pages are also ram.

There are a few possible ways around this. One problem is that
p2m_ram_paging_in may or may not have a backing mfn, so we can't just
check the p2mt, and that is frankly annoying (plenty of wth conditionals
in the p2m code relate to this). We could disambiguate with two states,
e.g.:
 p2m_ram_paging_in_absent
 p2m_ram_paging_present
 p2m_is_paging_in(p2mt) returns true for both -> use in most cases where
p2m_ram_paging_in is used right now
 p2m_is_ram_present(p2mt) returns true for p2m_ram_rw, log dirty, shared,
paging_out and paging_in present -> used in cases like above
 p2m_is_ram(p2mt) includes ram_present and pod and paging_in_absent ->
used in broader cases

That looks like a fairly dangerous changeset. But the more comprehensive
solution. The path of least resistance is obviously to just fix George's
current patches.

btw, George, couple of #if 0's and //'s on your "Check zero-check pages
returned by the balloon driver" patch. Those are going out before tree
inclusion, I assume?

Thanks
Andres


) Then most checks for p2m_ram_paging, s/
> Cheers,
>
> Tim.
>

  reply	other threads:[~2012-06-14 12:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 11:54 [PATCH 0 of 4 RFC] Populate-on-demand: Check pages being returned by the balloon driver George Dunlap
2012-06-08 11:54 ` [PATCH 1 of 4 RFC] xen, p2m: get_entry returns level of entry as well George Dunlap
2012-06-14 10:21   ` Tim Deegan
2012-06-14 15:01     ` George Dunlap
2012-06-14 15:31       ` Tim Deegan
2012-06-14 16:39       ` George Dunlap
2012-06-14 17:00         ` Tim Deegan
2012-06-08 11:54 ` [PATCH 2 of 4 RFC] xen, pod: Check zero-check pages returned by the balloon driver George Dunlap
2012-06-14 10:28   ` Tim Deegan
2012-06-14 12:57     ` Andres Lagar-Cavilla [this message]
2012-06-14 13:19       ` Tim Deegan
2012-06-14 13:19     ` Olaf Hering
2012-06-14 13:20       ` Tim Deegan
2012-06-08 11:54 ` [PATCH 3 of 4 RFC] imported patch CA-72761-libxc-error.patch George Dunlap
2012-06-08 11:57   ` George Dunlap
2012-06-08 11:54 ` [PATCH 4 of 4 RFC] imported patch pygrub-invalid-disk-catch.patch George Dunlap
2012-06-08 11:58   ` George Dunlap
2012-06-08 11:58 ` [PATCH 0 of 4 RFC] Populate-on-demand: Check pages being returned by the balloon driver George Dunlap
2012-06-14 10:14 ` Tim Deegan

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=d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org \
    --to=andres@lagarcavilla.org \
    --cc=george.dunlap@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /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).