On Thu, Feb 16, 2006 at 11:49:00AM +0000, Keir Fraser wrote:
>
> On 15 Feb 2006, at 23:04, Ryan Grimm wrote:
>
> >This patch allows a domain's vcpus to increase beyond the max (up to
> >CONFIG_NR_CPUS) set at creation time by making 3 changes:
>
> I'd prefer to keep the current Xen mechanisms, but extend xend and/or
> config file formats so that we can distinguish max_vcpus from
> initial_vcpus. Currently the two values are conflated. Then you can set
> max_vcpus as high as you like, but xenstore will tell the guest how
> many CPUs to bring up during boot.
One drawback of this is that the store is not up for dom0's creation.
So, i guess the two values could not apply to dom0?
> If we want a 'hard limit' check in Xen (kind of like we have a
> per-domain memory limit) to ensure that guests do not sneakily bring up
> CPUs that we didn't ask them to, then we can add that but it's an
> orthogonal change (i.e., different patch) to what you are trying to do
> here.
So, you're saying that the config file could specify max_vcpus to say,
8, and initial to say, 2. Then, there would need to be another value
inside of XEN, that would be the hard limit. This could be enforced via
another dom0_op, which sets the hard limit, and a vcpu_op, which would
tell the domain whether it was allowed to bring up another cpu.
How does this approach sound to you?
I think the benefits of the approach that I submitted are that it makes
a very small change in XEN and brings smpboot.c to more closely mirror
the way linux does hot add, in terms of the mappings. Is it the use of
DOM0_MAX_VCPUS after domain creation that you find particularly ugly?
Thanks,
Ryan
sorry for the resent, forgot to CC xen-devel earlier
>
> -- Keir
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home