On Mon, Jul 23, 2007 at 02:09:02PM +0200, Dietmar Hahn wrote:
> 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?
Thanks for detailed explanation.
Given that the usage model is unsure, I think the simple way is better.
After it is done, then we can re-consider on whether the more complex
way is necessary or not.
thanks,
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home