All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [libvirt] [Xen-devel] [PATCH] libxl: Correctly initialize vcpu bitmap
Date: Tue, 23 Jul 2013 15:20:41 -0600	[thread overview]
Message-ID: <51EEF3A9.3000705@suse.com> (raw)
In-Reply-To: <20130722193959.GQ30300@phenom.dumpdata.com>

One comment below in addition to Konrad's...

Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 22, 2013 at 12:51:05PM +0200, Stefan Bader wrote:
>   
>> This fixes the basic setup but there is likely more to do if things
>> like manual CPU hirarchy (nodes, cores, threads) to be working.
>>
>> Cross-posting to xen-devel to make sure I am doing things correctly.
>>
>> -Stefan
>>
>>
>> >From 1ec5e7ea0d3498b9f61b83e8aed87cc3cae106de Mon Sep 17 00:00:00 2001
>> From: Stefan Bader <stefan.bader@canonical.com>
>> Date: Fri, 19 Jul 2013 15:20:00 +0200
>> Subject: [PATCH] libxl: Correctly initialize vcpu bitmap
>>
>> The avai_vcpu bitmap has to be allocated before it can be used (using
>>     
>
> avail_vcpu ?
>
>   
>> the maximum allowed value for that). Then for each available VCPU the
>> bit in the mask has to be set (libxl_bitmap_set takes a bit position
>> as an argument, not the number of bits to set).
>>
>> Without this, I would always only get one VCPU for guests created
>> through libvirt/libxl.
>>
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>>     
>
> The libxl calling logic looks Ok to me. So from the libxl perspective
> you can tack on Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
>   
>> ---
>>  src/libxl/libxl_conf.c |   14 +++++++++++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index 4a0fba9..7592dd2 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -331,7 +331,8 @@ error:
>>  }
>>  
>>  static int
>> -libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config)
>> +libxlMakeDomBuildInfo(libxlDriverPrivatePtr driver, virDomainDefPtr def,
>> +                      libxl_domain_config *d_config)
>>  {
>>      libxl_domain_build_info *b_info = &d_config->b_info;
>>      int hvm = STREQ(def->os.type, "hvm");
>> @@ -343,8 +344,15 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config)
>>          libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_HVM);
>>      else
>>          libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_PV);
>> +
>>      b_info->max_vcpus = def->maxvcpus;
>> -    libxl_bitmap_set((&b_info->avail_vcpus), def->vcpus);
>> +    if (libxl_cpu_bitmap_alloc(driver->ctx, &b_info->avail_vcpus,
>> +                               def->maxvcpus))
>>     

You are using the driver-wide libxl_ctx in libxlDriverPrivate here, but
should be using the per-domain libxl_ctx in libxlDomainObjPrivate
structure IMO.

It looks like libxlBuildDomainConfig, which calls libxlMakeDomBuildInfo,
should have just taken virDomainObjPtr instead of virDomainDefPtr. 
libxlBuildDomainConfig would then have access to the per-domain
libxl_ctx, and no longer need the libxlDriverPrivatePtr parameter as well.

Regards,
Jim

>> +        goto error;
>> +    libxl_bitmap_set_none(&b_info->avail_vcpus);
>> +    for (i = 0; i < def->vcpus; i++)
>> +        libxl_bitmap_set((&b_info->avail_vcpus), i);
>> +
>>      if (def->clock.ntimers > 0 &&
>>          def->clock.timers[0]->name == VIR_DOMAIN_TIMER_NAME_TSC) {
>>          switch (def->clock.timers[0]->mode) {
>> @@ -802,7 +810,7 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
>>      if (libxlMakeDomCreateInfo(driver, def, &d_config->c_info) < 0)
>>          return -1;
>>  
>> -    if (libxlMakeDomBuildInfo(def, d_config) < 0) {
>> +    if (libxlMakeDomBuildInfo(driver, def, d_config) < 0) {
>>          return -1;
>>      }
>>  
>> -- 
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>     
>
>   

  parent reply	other threads:[~2013-07-23 21:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 10:51 [libvirt] [PATCH] libxl: Correctly initialize vcpu bitmap Stefan Bader
2013-07-22 19:39 ` [libvirt] [Xen-devel] " Konrad Rzeszutek Wilk
2013-07-23  7:08   ` Stefan Bader
2013-07-23 21:20   ` Jim Fehlig [this message]
2013-07-24 11:43     ` Stefan Bader
2013-07-24 15:14       ` Jim Fehlig

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=51EEF3A9.3000705@suse.com \
    --to=jfehlig@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=libvir-list@redhat.com \
    --cc=stefan.bader@canonical.com \
    --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.