Messages in this thread | | | Subject | Re: [patch 6/6] Guest page hinting: s390 support. | From | Martin Schwidefsky <> | Date | Thu, 13 Mar 2008 17:55:38 +0100 |
| |
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, Martin.
"Reality continues to ruin my life." - Calvin.
| |