WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] Xen Itanium features available in Xen HVM?

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