|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [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
|
|
|
|
|