[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47D84CEB.6050300@goop.org>
Date: Wed, 12 Mar 2008 14:36:43 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Anthony Liguori <anthony@...emonkey.ws>
CC: Jeremy Fitzhardinge <jeremy@...p.org>, akpm@...l.org,
linux-s390@...r.kernel.org, frankeh@...son.ibm.com,
nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
virtualization@...ts.osdl.org, schwidefsky@...ibm.com,
hugh@...itas.com
Subject: Re: [patch 6/6] Guest page hinting: s390 support.
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists