Hi,
sharing a PKR with one set by the OS might work.
If you want to use this method, you'd better to know which PKR is used
by the IVT, otherwise the OS might change frequently the PKR value during
execution which has to be handled (not that easy).
In other word, you have to discover the right PK. Might be easy or not.
The PK id is required to map (through itr and itc) Xen code & data. Don't
forget that some data accesses are done through itc.
Things might be more complex if xd/rd/wr bit is set. In this case many
PK might be tracked. (Not sure HPUX does this but...)
I am not against this approach (not far from PV approach), but I am not
sure there is a gain compared to keeping an N->M map. The map has one
advantage: xen will be able to present more virtual PKR then real one.
If you feel more confortable with this approach, go ahead. This is only
one part of the whole work.
Tristan.
On Wed, May 14, 2008 at 01:31:36PM -0700, Paul Leisy wrote:
> Hi Tristan,
>
> Do you know why Xen cannot share a PKR with one set by the OS?
>
> It is my understanding that the Itanium architecture does not provide a way
> to disable protection keys on interrupts (psr.pk will stay set). Therefore,
> the
> HP-UX kernel must set it's own key to use so it can process interrupts.
> It seems like Xen could use that same key (share it) to proccess interrupts,
> intercepts, emulation on behalf of the guest(s).
>
> Since the protection keys (psr.pk) are not turned off during an interrupt,
> I assume Xen needs a PKR so it won't get key miss faults. If the HP-UX
> kernel has the same goal, it would seem they could share the same PKR.
>
> Just my first impression, I'm probably missing some details that negate
> this approach. What are your thoughts?
>
> Thanks again,
> -Paul Leisy
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home