From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: akpm@osdl.org, linux-s390@vger.kernel.org,
frankeh@watson.ibm.com, nickpiggin@yahoo.com.au,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
Anthony Liguori <anthony@codemonkey.ws>,
hugh@veritas.com
Subject: Re: [patch 6/6] Guest page hinting: s390 support.
Date: Thu, 13 Mar 2008 18:23:38 +0100 [thread overview]
Message-ID: <1205429018.5920.38.camel@localhost> (raw)
In-Reply-To: <47D95EC7.7030204@goop.org>
On Thu, 2008-03-13 at 10:05 -0700, Jeremy Fitzhardinge wrote:
> Martin Schwidefsky wrote:
> > Vz is the page discarded state. The difference to Uz is slim, both
> > states will cause a program check on access. Vz generates a discard
> > fault, Uz generates an addressing exception which is nice for debugging.
> >
>
> How do you handle these different cases in Linux? Do you use Vr pages
> in the pagecache, and then shoot down the pagecache entry if the host
> steals the page?
The environment where we currently run all this is z/VM as the host and
Linux as the guest. We have two page tables on s390, a host page table
and a guest page table. If the host discards a page it simple removes
the entry for the page in the host page table. If the guest comes along
and accesses the page the host gets the fault and generates the
appropriate fault.
> The Uz access exception presumably just generates a normal oops.
Yes, the handler for an addressing exception will call die() for a
kernel check without a fixup.
> (I should probably make time to read the rest of the series.)
>
> >> But given how you've described V-state pages, I really would expect
> >> writes to a Vz to work, or alternatively, all writes to V-state pages to
> >> be disallowed. Are there any real uses for a writable Vr page?
> >>
> >
> > You mean in the section that speaks about the guests states S/U/V/P ?
> > Always keep in mind that you can access a V/P page only until it gets
> > discarded. Then the useful content of the page frame is lost and any
> > read of write to the not Vz page will be answered with a discard fault.
> >
>
> Presumably reads from a Vz page also generate a discard fault?
Yes.
> > A Vr page is read-only. If a page gets mapped for writing it needs to
> > get into the Pr state. This is the hint for the host to look at the
> > dirty bit before it discards a page.
> > So yes, there is no use for a writable Vr page.
> >
>
> OK, thanks, that clears things up. I was assuming that Vr was
> technically writable but that writes could be discarded at any time (ie,
> allowing guests to merrily shoot themselves in the foot ;). Making it
> forced RO is much more sensible.
Well, technically you could write to a Vr page via the kernel address
space. The thing is that the host can just discard the page although it
is dirty. The Vr state is used for page cache pages which do not have
any writable mapping.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2008-03-13 17:23 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 13:21 [patch 0/6] Guest page hinting version 6 Martin Schwidefsky
2008-03-12 13:21 ` [patch 1/6] Guest page hinting: core + volatile page cache Martin Schwidefsky
2008-03-12 23:12 ` Rusty Russell
2008-03-13 9:24 ` Martin Schwidefsky
2008-03-12 13:21 ` [patch 2/6] Guest page hinting: volatile swap cache Martin Schwidefsky
2008-03-12 13:21 ` [patch 3/6] Guest page hinting: mlocked pages Martin Schwidefsky
2008-03-12 23:27 ` Rusty Russell
2008-03-13 9:13 ` Martin Schwidefsky
2008-03-12 13:21 ` [patch 4/6] Guest page hinting: writable page table entries Martin Schwidefsky
2008-03-12 23:35 ` Rusty Russell
2008-03-13 9:11 ` Martin Schwidefsky
2008-03-12 13:21 ` [patch 5/6] Guest page hinting: minor fault optimization Martin Schwidefsky
2008-03-12 13:21 ` [patch 6/6] Guest page hinting: s390 support Martin Schwidefsky
2008-03-12 16:19 ` Jeremy Fitzhardinge
2008-03-12 16:28 ` Martin Schwidefsky
2008-03-12 16:44 ` Jeremy Fitzhardinge
2008-03-12 16:59 ` Martin Schwidefsky
2008-03-12 17:48 ` Jeremy Fitzhardinge
2008-03-12 20:04 ` Anthony Liguori
2008-03-12 20:45 ` Jeremy Fitzhardinge
2008-03-12 20:56 ` Anthony Liguori
2008-03-12 21:36 ` Jeremy Fitzhardinge
2008-03-13 9:45 ` Martin Schwidefsky
2008-03-13 16:07 ` Jeremy Fitzhardinge
2008-03-13 16:17 ` Jeremy Fitzhardinge
2008-03-13 16:55 ` Martin Schwidefsky
2008-03-13 17:05 ` Jeremy Fitzhardinge
2008-03-13 17:23 ` Martin Schwidefsky [this message]
2008-03-13 9:42 ` Martin Schwidefsky
2008-03-13 9:36 ` Martin Schwidefsky
2008-03-13 9:32 ` Martin Schwidefsky
2008-03-12 22:41 ` [patch 0/6] Guest page hinting version 6 Rusty Russell
2008-03-13 9:47 ` Martin Schwidefsky
2008-03-13 16:57 ` Hugh Dickins
2008-03-13 17:14 ` Martin Schwidefsky
2008-03-13 17:45 ` Zachary Amsden
2008-03-13 19:45 ` Andrea Arcangeli
2008-03-13 21:41 ` Zachary Amsden
2008-03-13 18:41 ` Jeremy Fitzhardinge
2008-03-13 18:55 ` Hugh Dickins
2008-03-13 19:53 ` Zachary Amsden
2008-03-14 18:30 ` Jeremy Fitzhardinge
2008-03-14 21:32 ` Zachary Amsden
2008-03-14 21:37 ` Jeremy Fitzhardinge
2008-03-17 9:21 ` Martin Schwidefsky
2008-05-06 15:33 ` Martin Schwidefsky
2008-05-06 19:46 ` Rik van Riel
2008-05-07 3:49 ` Zachary Amsden
2008-05-07 7:00 ` Martin Schwidefsky
-- strict thread matches above, loose matches on Subject: below --
2009-03-27 15:09 [patch 0/6] Guest page hinting version 7 Martin Schwidefsky
2009-03-27 15:09 ` [patch 6/6] Guest page hinting: s390 support Martin Schwidefsky
2009-04-01 16:18 ` Rik van Riel
[not found] <20070628164049.118610355@de.ibm.com>
2007-06-28 16:40 ` Martin Schwidefsky
2007-05-11 13:58 [patch 0/6] [rfc] guest page hinting version 5 Martin Schwidefsky
2007-05-11 13:58 ` [patch 6/6] Guest page hinting: s390 support Martin Schwidefsky
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=1205429018.5920.38.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@osdl.org \
--cc=anthony@codemonkey.ws \
--cc=frankeh@watson.ibm.com \
--cc=hugh@veritas.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=virtualization@lists.osdl.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).