All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@sgi.com>
To: kvm-ia64@vger.kernel.org
Subject: Re: [patch] remove vcpu_info array v5
Date: Mon, 10 Nov 2008 13:24:15 +0000	[thread overview]
Message-ID: <491835FF.9030400@sgi.com> (raw)
In-Reply-To: <4909C00F.8050704@sgi.com>

Avi Kivity wrote:
> Jes Sorensen wrote:
>> Move contents of struct vcpu_info directly into CPU_COMMON. Rename
>> struct qemu_kvm_work_item to qemu_work_item as it really isn't KVM
>> specific.
> 
> Well, it is actually kvm specific, since qemu doesn't have vccpu threads.

Hi Avi,

Anthony suggested I moved things directly in there, after my previous
patch kept it as a struct.

>> -int kvm_run(kvm_context_t kvm, int vcpu)
>> +int kvm_run(kvm_context_t kvm, int vcpu, void *env)
>>   
> 
> That's a little ugly -- passing two arguments which describe the vcpu.  
> How about passing env to kvm_create_vcpu() instead?

I am all in favor of doing this, but in order to do so, we have to
teach libkvm about CPUState - are you ok with that?

> 
> struct kvm_stuff { ... } and put that in as a member, so it's easier to 
> remember this is a kvm addition.

If we can agree, I really don't care too much. There's already plenty
of stuff in CPU_COMMON that isn't used by specific users, so I didn't
think this was an issue.

>>  
>>  #if defined(TARGET_I386) || defined(TARGET_X86_64)
>> +#ifdef USE_KVM
>> +static CPUState *qemu_kvm_cpu_env(int index)
>> +{
>> +    CPUState *penv;
>> +
>> +    penv = first_cpu;
>> +
>> +    while (penv) {
>> +        if (penv->cpu_index = index)
>> +            return penv;
>> +        penv = (CPUState *)penv->next_cpu;
>> +    }
>> +
>> +    return NULL;
>> +}
>> +#endif
>>   
> 
> This can't be the best way of determining the env pointer from a cpu 
> number.

It's not pretty, but this is only used in the ACPU hotplug code now, so
it's less performance critical.

>> +/* work queue */
>> +struct qemu_work_item {
>> +    struct qemu_kvm_work_item *next;
>>   
> 
> Missed rename here.
 >
>> +    void (*func)(void *data);
>> +    void *data;
>> +    int done;
>> +};
>> +
>>   
> 
> Please keep this in kvm specific files.

Why? There really isn't anything specific about a work queue list
like this. Making it an available functionality for QEMU shouldn't
hurt.

>> -#define bool _Bool
>>   
> 
> why?

It was unused and didn't add any value.

> Please separate into a patch that does the kvm_run int vcpu -> void 
> *vcpu conversion, and then the vcpu_info -> env conversion.

As mentioned above, if I am going to go that way, we need to teach
libkvm about 'env'. I am all in favor, but I am not going to do that
unless I can get an ack that it's acceptable to do so.


Cheers,
Jes

WARNING: multiple messages have this Message-ID (diff)
From: Jes Sorensen <jes@sgi.com>
To: Avi Kivity <avi@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Hollis Blanchard <hollisb@us.ibm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvm-ia64@vger.kernel.org" <kvm-ia64@vger.kernel.org>,
	Glauber de Oliveira Costa <glommer@gmail.com>
Subject: Re: [patch] remove vcpu_info array v5
Date: Mon, 10 Nov 2008 14:24:15 +0100	[thread overview]
Message-ID: <491835FF.9030400@sgi.com> (raw)
In-Reply-To: <49103812.1070104@redhat.com>

Avi Kivity wrote:
> Jes Sorensen wrote:
>> Move contents of struct vcpu_info directly into CPU_COMMON. Rename
>> struct qemu_kvm_work_item to qemu_work_item as it really isn't KVM
>> specific.
> 
> Well, it is actually kvm specific, since qemu doesn't have vccpu threads.

Hi Avi,

Anthony suggested I moved things directly in there, after my previous
patch kept it as a struct.

>> -int kvm_run(kvm_context_t kvm, int vcpu)
>> +int kvm_run(kvm_context_t kvm, int vcpu, void *env)
>>   
> 
> That's a little ugly -- passing two arguments which describe the vcpu.  
> How about passing env to kvm_create_vcpu() instead?

I am all in favor of doing this, but in order to do so, we have to
teach libkvm about CPUState - are you ok with that?

> 
> struct kvm_stuff { ... } and put that in as a member, so it's easier to 
> remember this is a kvm addition.

If we can agree, I really don't care too much. There's already plenty
of stuff in CPU_COMMON that isn't used by specific users, so I didn't
think this was an issue.

>>  
>>  #if defined(TARGET_I386) || defined(TARGET_X86_64)
>> +#ifdef USE_KVM
>> +static CPUState *qemu_kvm_cpu_env(int index)
>> +{
>> +    CPUState *penv;
>> +
>> +    penv = first_cpu;
>> +
>> +    while (penv) {
>> +        if (penv->cpu_index == index)
>> +            return penv;
>> +        penv = (CPUState *)penv->next_cpu;
>> +    }
>> +
>> +    return NULL;
>> +}
>> +#endif
>>   
> 
> This can't be the best way of determining the env pointer from a cpu 
> number.

It's not pretty, but this is only used in the ACPU hotplug code now, so
it's less performance critical.

>> +/* work queue */
>> +struct qemu_work_item {
>> +    struct qemu_kvm_work_item *next;
>>   
> 
> Missed rename here.
 >
>> +    void (*func)(void *data);
>> +    void *data;
>> +    int done;
>> +};
>> +
>>   
> 
> Please keep this in kvm specific files.

Why? There really isn't anything specific about a work queue list
like this. Making it an available functionality for QEMU shouldn't
hurt.

>> -#define bool _Bool
>>   
> 
> why?

It was unused and didn't add any value.

> Please separate into a patch that does the kvm_run int vcpu -> void 
> *vcpu conversion, and then the vcpu_info -> env conversion.

As mentioned above, if I am going to go that way, we need to teach
libkvm about 'env'. I am all in favor, but I am not going to do that
unless I can get an ack that it's acceptable to do so.


Cheers,
Jes

  parent reply	other threads:[~2008-11-10 13:24 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 14:09 [patch] remove vcpu_info array v5 Jes Sorensen
2008-10-30 14:09 ` Jes Sorensen
2008-11-04 11:54 ` Avi Kivity
2008-11-04 11:54   ` Avi Kivity
2008-11-04 13:55 ` Glauber Costa
2008-11-04 13:55   ` Glauber Costa
2008-11-04 14:30 ` Avi Kivity
2008-11-04 14:30   ` Avi Kivity
2008-11-04 14:35 ` Glauber Costa
2008-11-04 14:35   ` Glauber Costa
2008-11-04 14:40 ` Avi Kivity
2008-11-04 14:40   ` Avi Kivity
2008-11-04 14:43 ` Glauber Costa
2008-11-04 14:43   ` Glauber Costa
2008-11-04 14:47 ` Avi Kivity
2008-11-04 14:47   ` Avi Kivity
2008-11-10 12:30 ` Jes Sorensen
2008-11-10 12:30   ` Jes Sorensen
2008-11-10 13:24 ` Jes Sorensen [this message]
2008-11-10 13:24   ` Jes Sorensen
2008-11-10 13:30 ` Jes Sorensen
2008-11-10 13:30   ` Jes Sorensen
2008-11-10 13:40 ` Avi Kivity
2008-11-10 13:40   ` Avi Kivity
2008-11-10 13:48 ` Avi Kivity
2008-11-10 13:48   ` Avi Kivity
2008-11-10 15:22 ` Anthony Liguori
2008-11-10 15:22   ` Anthony Liguori
2008-11-10 15:45 ` Avi Kivity
2008-11-10 15:45   ` Avi Kivity
2008-11-10 15:47 ` Jes Sorensen
2008-11-10 15:47   ` Jes Sorensen
2008-11-10 15:54 ` Avi Kivity
2008-11-10 15:54   ` Avi Kivity
2008-11-10 15:58 ` Jes Sorensen
2008-11-10 15:58   ` Jes Sorensen
2008-11-11  9:26 ` Avi Kivity
2008-11-11  9:26   ` Avi Kivity
2008-11-12 13:02 ` Jes Sorensen
2008-11-12 13:02   ` Jes Sorensen
2008-11-12 13:09 ` Glauber Costa
2008-11-12 13:09   ` Glauber Costa
2008-11-12 13:12 ` Avi Kivity
2008-11-12 13:12   ` Avi Kivity
2008-11-12 13:14 ` Avi Kivity
2008-11-12 13:14   ` Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2008-11-13 16:46 [patch] pass opague CPUState through libkvm instead of int vcpu Jes Sorensen
2008-11-13 16:46 ` Jes Sorensen
2008-11-18 12:55 ` Avi Kivity
2008-11-18 12:55   ` Avi Kivity
2008-11-18 12:59 ` Jes Sorensen
2008-11-18 12:59   ` Jes Sorensen

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=491835FF.9030400@sgi.com \
    --to=jes@sgi.com \
    --cc=kvm-ia64@vger.kernel.org \
    /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.