On Thu, May 15, 2008 at 09:36:59AM -0700, Paul Leisy wrote:
> Hi Tristan,
Hi,
did I forget to reply ? Seems so.
> Thank you for the comments. This really helps since I'm
pretty new
> to Xen. Here are more questions and assumptions I'm
making:
>
> I agree that it's important to know which PKR is used
by the HP-UX IVTs
> if we go with the plan of sharing a PKR. What about
this approach---
>
> Since HP-UX must use a key (PKR) for IVT and I assume
an ITR and DTR,
> Xen could observe when HP-UX sets the IVA and the ITR
and the DTR
> before it enters virtual mode. If the ITR is covering
the IVA, then it's a good
> bet that the key in the ITR is for the IVT. Does this
sound reasonable?
Yes it does.
> Another assumption is that once HP-UX sets up the IVT
areas with ITR
> and DTR (along with key) to cover them, they won't
change.
Reasonable too.
However if two different guests use two different PK,
switching from one
to the other will be harder...
> I thought there was a huge disadvantage to using
M->N map of PKRs.
> For example, if HP-UX set up all 16 PKRs and Xen has to
steal one for it's
> use, Xen could end up with a case where many accesses
by the guest
> will get false Key miss faults and Xen will have to
handle each one?
Right but this is also true for itc/itr which are
virtualized.
> Xen gets a key miss fault, determines that the key for
the access was
> stolen by Xen, then Xen has to put back the original
guest key and pick
> another guest key to steal. Then return to guest so
that it can make
> the access. Doesn't that create performance overhead
and mess with
> TLBs (since they contain keys).
I don't think this messes with TLBs. What do you have in
mind ?
M->N map will add overhead (but virtualization adds
overhead in any case).
But if N > M (ie you have more virtual PKR than hard
one), it will save
fault injection to the guest.
> On the other hand, perhaps HP-UX never uses all 16 PKRs
and it's no
> big deal to steal one for Xen. I know pretty much zero
about HP-UX.
> All guesses at this point.
Sure.
We will know more about HPUX once it will start to run in
Xen!
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel lists.xensource.com
http://list
s.xensource.com/xen-ia64-devel
|