[lkml]   [2008]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 6/6] Guest page hinting: s390 support.
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.


 \ /
  Last update: 2008-03-13 18:09    [W:0.186 / U:0.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site