Anthony Liguori wrote:
Vp should never happen, since you'd never preserve a V page. And
surely it would be Pr -> Sr, since the hypervisor wouldn't push the
page to backing store when you change the client state.
You're right, I meant Vp/Pp but they are invalid states. I think one of
the things that keeps tripping me up is that the host can change both
the host and guest page states. My initial impression was that the host
handled the host state and the guest handled the guest state.
Yes. And it seems to me that you get unfortunate outcomes if you have a
Pr->Vz->Vr transition.
Do the host states even really need visibility to the guest at all?
It may be useful for the guest to be able to distinguish between Ur
and Uz but it doesn't seem necessary.
Well, you implicitly see the hypervisor state. If you touch a [UV]z
page then you get a fault telling you that the page has been taken
away from you (I think). And it would definitely help with debugging
(seems likely there's lots of scope for race conditions if you
prematurely tell the hypervisor you don't need the page any more...).
I was thinking that it may be useful to know a Ur verses a Uz when
allocating memory. In this case, you'd rather allocate Ur pages verses
Uz to avoid the fault. I don't read s390 arch code well, is the host
state explicit to the guest?
Yes, reusing Ur pages might well be better, but who knows - they've
probably got an instruction which makes Uz cheap...
Stuff like this suggets that both parts of the state are packed
together, and are guest-visible:
+ return (state & ESSA_USTATE_MASK) == ESSA_USTATE_VOLATILE &&
+ (state & ESSA_CSTATE_MASK) == ESSA_CSTATE_ZERO;
J
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
