| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of
On 29/3/08 11:23, "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home