From: Ryan Harper <ryanh@us.ibm.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] 0/2 VCPU creation and allocation
Date: Mon, 10 Oct 2005 11:23:54 -0500 [thread overview]
Message-ID: <20051010162354.GP17358@us.ibm.com> (raw)
In-Reply-To: <f2c38fb2e629d2867f0a00e083c5813a@cl.cam.ac.uk>
* Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [2005-10-10 11:13]:
>
> On 10 Oct 2005, at 17:05, Ryan Harper wrote:
>
> >>Do you even need a max_vcpus variable? Surely the appropriate check is
> >>implicit in VCPUOP_initialise detecting whether or not the relevant
> >>VCPU has been created?
> >
> >I was going to ensure ordered VCPU creation. Without something like
> >vcpuid < max_vcpus+1, and increment on successful creation, one can
> >create vcpus in any order, 1,5,7, 10. I don't think it *should* matter
> >but I've not looked elsewhere through the code to see if there are any
> >other areas assuming all struct vcpu* being valid between 0 and n in
> >the d->vcpus[] array.
>
> Then the vcpu parameter to VCPUOP_create is redundant -- there's only
> one value you will be prepared to accept! If we don't want the
> flexibility of a sparse vcpu map (and I think we don't) then perhaps we
> are better off without VCPUOP_create (which is maybe even a bit neater,
> leaving vcpu_op as a completely unpriv local hypercall) and stick with
> the set_max_vcpus dom0_op? And have that implicitly create the vcpu
> struct for vcpus 0...n-1?
OK, that makes sense. I'll turn VCPUOP_create into set_max_vcpus(max)
which will create vcpus 1-(max-1). Any preference on the hypercall
name? Does set_max_vcpus() still make sense if it is also creating
vcpus?
How about DOM0_CREATEVCPUS and
do_createvcpus(struct domain* d, unsigned int max_vcpus).
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
next prev parent reply other threads:[~2005-10-10 16:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-10 15:16 [PATCH] 0/2 VCPU creation and allocation Ryan Harper
2005-10-10 15:29 ` Keir Fraser
2005-10-10 15:28 ` Ryan Harper
2005-10-10 16:01 ` Keir Fraser
2005-10-10 16:05 ` Ryan Harper
2005-10-10 16:17 ` Keir Fraser
2005-10-10 16:23 ` Ryan Harper [this message]
2005-10-10 16:39 ` Keir Fraser
2005-10-11 15:13 ` [PATCH] 2nd try: " Ryan Harper
2005-10-11 15:15 ` [PATCH] 2nd try: 1/2 " Ryan Harper
2005-10-11 15:16 ` [PATCH] 2nd try: 2/2 " Ryan Harper
2005-10-12 16:10 ` Keir Fraser
2005-10-12 16:15 ` Ryan Harper
-- strict thread matches above, loose matches on Subject: below --
2005-10-10 15:31 [PATCH] 0/2 " Ian Pratt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051010162354.GP17358@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.