Am Montag, 23. Juli 2007 schrieb Isaku Yamahata:
> On Fri, Jul 20, 2007 at 03:21:56PM +0200, Dietmar Hahn wrote:
> > Hi,
>
> Hi.
>
> > Can I replace pkrs[8];tmp[8]; with pkrs[16] to use this for protection
> > keys or should I expand pkrs and leave tmp[8] untouched. How about
> > changing the layout - is this possible here?
>
> Given that xen/ia64 haven't keep the ABI compatibility (Yes, we have
> changed the layout sometimes breaking the compatigbility), it would be
> acceptable to change the layout, I suppose.
>
> > In addition I would use a define for the number of pkrs. The only way to
> > get this is define it in arch-ia64.h for use from vmm and domU. Is this
> > OK or is there another solution possible?
>
> Probably it would be OK because I don't suppose that the number will
> be increased so frequently. Correct?
Yes. It would be something like that:
#define XEN_IA64_NPKRS 15 /* Number of pkr's in PV */
struct mapped_regs {
...
unsigned long pkrs[XEN_IA64_NPKRS+1];
...
}
My problem is, that the constant is needed in fw_emul.c to set max_pkr in the
PAL call emulation. And defining it twice doesn't make sense.
>
> > Btw. I'll use Isaku's suggestion and will add a new hypercall to let vmm
> > setup the cpu-pkrs with the values the domU changed.
>
> Please note that I only read your patch and I haven't even tested your
> patch. I'm not sure how you use pkrs.
> The design decision should depend on its usage model.
My problem is, I'am still unsure about the usage model.
With your suggestion (put pkrs in mapped_regs) the domU can get the pkr's
only with reading the memory, but I believe this isn't used often (In our
ported OS we never do this). Therewith the win of performance is only
marginal.
The write can be done by writing to pkrs[] and doing a hypercall with the
register number.
The problem with the pkr is the order in which the cpu-prk's are written from
the domU. The hypervisor must take care of the order. Within context_switch()
the cpu-pkr's must be loaded from the pkrs[] vector. This must be done in the
correct order, because writing a pkr-register leads to invalidating already
written registers with the same key.
Imaginable for better performance would be that the domU writes multiple pkr's
in memory, maybe invalidating multiple keys, and only one hypercall is used
with a bitmask (one bit for every register). But in this case the order gets
lost or we need a special interface, where the domU provides this
information. But than the hypercall interface is a lot more complex.
The other way would be the hypervisor doesn't look at the order and the domU
must ensure that no key is twice in pkrs[].
For our port we won't need the order handling in the hypervisor. But I think a
correct implementation should be done.
1. pkrs[] in struct arch_vcpu:
- hypervisor can simple take care about the order
- no new hypercall
- mov r=pkrs[], mov pkr[]=r and a hyperprivop
- simple domU interfaces
2. pkrs[] in struct mapped regs:
- not in the ABI.
- fast read possible (maybe not really needed)
- new hypercall for writing cpu-pkr
- mov r=pkrs[], mov pkr[]=r, a hyperprivop and the new hypercall
1. if only setting one pkr per hypercall than hypervisor can simple take
care of order.
2. if setting multiple prks[] per hypercall and handling the order in the
hypervisor, than more support from domU needed.
So what says your long time experience?
Dietmar.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home