[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.
On Thu, 2008-03-13 at 09:17 -0700, Jeremy Fitzhardinge wrote:
> Jeremy Fitzhardinge wrote:
> > Martin Schwidefsky wrote:
> >> Vz->Vr cannot happen. This would be a bug in the host.
> >>
> >
> > Does that mean that Vz is effectively identical to Uz?
> Hm, on further thought:
> If guests writes to Vz pages are disallowed, then the only way out of Vz
> is if the guest sets it to something else (Uz,Sz). If so, what's the
> point of using that state? Why not make:
> Vr -> Uz host discard
> Pr -> Uz host discard clean
> Sp -> Uz set volatile
> Uz -> Uz set volatile

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.
But I don't see a reason why an implementation that uses Uz instead of
Vz shouldn't work.

> 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.

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.

blue skies,

"Reality continues to ruin my life." - Calvin.

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