Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756910AbYCMRHK (ORCPT ); Thu, 13 Mar 2008 13:07:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755202AbYCMRG4 (ORCPT ); Thu, 13 Mar 2008 13:06:56 -0400 Received: from gw.goop.org ([64.81.55.164]:52640 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753880AbYCMRGz (ORCPT ); Thu, 13 Mar 2008 13:06:55 -0400 Message-ID: <47D95EC7.7030204@goop.org> Date: Thu, 13 Mar 2008 10:05:11 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: schwidefsky@de.ibm.com 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 , hugh@veritas.com Subject: Re: [patch 6/6] Guest page hinting: s390 support. References: <20080312132132.520833247@de.ibm.com> <20080312132704.474209626@de.ibm.com> <47D802A2.1030406@goop.org> <1205339285.8851.13.camel@localhost> <47D8085E.9030701@goop.org> <1205341164.8851.44.camel@localhost> <47D81771.5070400@goop.org> <47D8373C.40105@codemonkey.ws> <47D840E3.5090902@goop.org> <47D8436F.9080901@codemonkey.ws> <47D84CEB.6050300@goop.org> <1205401508.26537.37.camel@localhost> <47D95134.6030503@goop.org> <47D953AB.1030901@goop.org> <1205427338.5920.12.camel@localhost> In-Reply-To: <1205427338.5920.12.camel@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1853 Lines: 44 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 Uz access exception presumably just generates a normal oops. (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? > 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. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/