On Thu, 2008-03-13 at 09:17 -0700, Jeremy Fitzhardinge wrote:

Jeremy Fitzhardinge wrote:

quoted

Martin Schwidefsky wrote:

quoted

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

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