WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 29 Mar 2008 11:47:57 +0000
Delivery-date: Sat, 29 Mar 2008 04:49:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080329112316.GC4482@implementation>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciRkrsU+Yh7cP2FEdymtAAWy6hiGQ==
Thread-topic: [Xen-devel] Re: [Xen-changelog] [xen-unstable] Clean up handling of IS_PRIV_FOR() and rcu_[un]lock_domain().
User-agent: Microsoft-Entourage/11.4.0.080122
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

<Prev in Thread] Current Thread [Next in Thread>