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-users] Xen 3.0 Dom0 Smp enable?

To: "Ryan Harper" <ryanh@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [Xen-users] Xen 3.0 Dom0 Smp enable?
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 8 Aug 2005 19:57:55 +0100
Cc: Stephan Diestelhorst <sd386@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alan Greenspan <alan@xxxxxxxxxxx>
Delivery-date: Mon, 08 Aug 2005 18:56:18 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: AcWcRn9Q1/NtmjRsTzaJKoYwUL4u2wAAdSWQ
Thread-topic: [Xen-devel] RE: [Xen-users] Xen 3.0 Dom0 Smp enable?
 
> I suppose it is a toss up.  Should the DOM0_CREATEDOMAIN hypercall be
> responsible for cpu allocation?  One could argue both ways.  Even now,
> it is merely responsible for picking which physical cpu is used for a
> dom's VCPU0. Then alloc_vcpu_struct() in schedule.c picks the
> processor for additional vcpu as they get booted via do_boot_vcpu()
> 
> I think there is more work to do things cleanly.  We can make things
> work with pinvcpu operations, but it feels hacky.  I think there is
> quite a bit of work, and I'm still not convinced that this should be
> done for 3.0 simply because of the size of the change.

None of the proposal touches anything at all complicated, so it's low
risk and I'd be inclined to make the change if I received a patch soon.
 
> 1. create domain hypercall should take cpumap to indicate 
> which physical
> cpus any of a domain's vcpus can utilize

The create hypercall effectively just allocates a domid. We set all
other parameters via separate ops these days.

We could move the per VCPU pin mask to the domain strcture and
initialise it with defaults when the domain is created. Alternatively we
could have a 'master' cpu map which is used to initialise the maps of
new vcpus. It could be set by the existing hypercall with a VCPU number
of -1.

> 2. remove physical cpu selection from DOM0_CREATEDOMAIN in dom0_ops.c
> 3. remove physical cpu selection from alloc_vcpu_struct()
> 4. create new function, get_next_processor(struct domain *) 
> which reads
> the domain's cpumap and returns the next physical cpu the 
> domain should
> use.  Update DOM0_CREATEDOMAIN and alloc_vcpu_struct() 
> functions to use
> get_next_processor()
> 5. update tools/libs to pass in/require cpumap when creating domains
> 6. create high-level map abstractions (e.g. don't use hyperthreads)


Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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