Re: Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 29/3/08 11:23, "Samuel Thibault" <samuel.thibault@eu.citrix.com> wrote:

> HVMOP_get_param is needed yes (set_param doesn't seem to be).

I didn't revert any of the HVMOP ones. Basically, anything that a domain is
allowed to do to itself I also kept the IS_PRIV_FOR() case.

> set_foreigndom is probably needed in a lot of cases, but maybe not all,
> so maybe we should have two versions of it.

We can keep it as is. Really TLB flush masks should have the IS_PRIV_FOR()
domain ORed in though.

> DOMCTL_getdomaininfo is needed.
> DOMCTL_max_mem is needed.

These ones are a sticking point I'm afraid. DOMCTL_max_mem is a globally
privileged operation because it can give increased access to the global
memory resource. We can't let stub domains have at it. We'll have to keep
max_mem permanently increased, and set that up in xend. With that done you
probably don't really need getdomaininfo either.

> DOMCTL_settimeoffset is needed.

Why is this done in ioemu and not in xend (it's already done there for PV
guests).

> x86 DOMCTL_memory/ioport_mapping are needed for passthrough (not
> implemented yet, though)

Again, they are globally privileged operations. I can't see that they
logically belong in ioemu-dm in the first place. It's not necessarily your
job to clean this up of course, but it simply means that passthru is
incompatible with stub domains until it is cleaned up.

> IIRC the event channel ops are not needed right now, but will probably
> be in the future.

They were all fine, except there was one inexplicable check of IS_PRIV_FOR()
in bind_interdomain() which I nuked. It was so bizarre that I assumed you
must have put it there for a reason, and this would be one that you'd
complain about. If not, then great! :-)

> XENMEM_in/decrease_reservation and populate_physmap are needed.
> XENMEM_maximum_gpfn is needed.

All these I allowed, by the reasoning that DOMID_SELF is allowed them and
that should allow IS_PRIV_FOR() too.

> I don't have the time to test precisely what else would be needed, but
> the cases above should be at least 90% of what is.

Sounds to me like the domctls are the sticking point. And I can't reasonably
budge on those.

 -- Keir