On Fri, 2007-07-27 at 07:41 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > So the in-kernel apic code has to traverse every element in the array?
> > That is clearly better because?
>
> Rusty, don't make me do this.
>
> Arrays give you random access. Hand the array an index, and it hands
Rusty Russell wrote:
> I agree: Qemu supports up to 255 processors, but that's kind of silly if
> it's static. I'll leave the current limit (4) and let someone else code
> up a dynamic one.
>
>
Hopefully that someone else will address the real limits to guest
scalability as well.
(with npt/ep
Rusty Russell wrote:
> On Thu, 2007-07-26 at 14:05 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> Great minds think alike. This is a little rough, but I decided to send
>>> it out tonight because it would make your life easier...
>>>
>> What about my life? Which patc
On Thu, 2007-07-26 at 19:50 -0400, Gregory Haskins wrote:
> On Fri, 2007-07-27 at 09:27 +1000, Rusty Russell wrote:
>
> > So the in-kernel apic code has to traverse every element in the array?
> > That is clearly better because?
>
> I can't speak for Eddie's implementation, but the one that I ha
On Fri, 2007-07-27 at 09:27 +1000, Rusty Russell wrote:
> So the in-kernel apic code has to traverse every element in the array?
> That is clearly better because?
I can't speak for Eddie's implementation, but the one that I had worked
on did in fact take advantage of the array. Not for traversi
On Thu, 2007-07-26 at 14:05 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > Great minds think alike. This is a little rough, but I decided to send
> > it out tonight because it would make your life easier...
>
> What about my life? Which patch should I apply first?
Such are the responsi
Gregory Haskins wrote:
>>>
>>> Hmm..well, you still have pointers. The advantage is that they are
>>> implicitly maintained, but now you have to do pointer arithmetic to
>>> compute it. :( I personally would probably rather have the explicit
>>> management code than the run-time overhead
>>>
On Thu, 2007-07-26 at 16:37 +0300, Avi Kivity wrote:
> Gregory Haskins wrote:
> > On Thu, 2007-07-26 at 15:33 +0300, Avi Kivity wrote:
> >
> >
> >> The suggestion I liked best (Anthony's) was
> >>
> >> struct vmx_vcpu {
> >> struct kvm_vcpu vcpu;
> >> void *vmcs;
> >> /
Gregory Haskins wrote:
> On Thu, 2007-07-26 at 15:33 +0300, Avi Kivity wrote:
>
>
>> The suggestion I liked best (Anthony's) was
>>
>> struct vmx_vcpu {
>> struct kvm_vcpu vcpu;
>> void *vmcs;
>> // other vmx-specific data
>>};
>>
>> to move from a kvm_vcpu to a vmx
On Thu, 2007-07-26 at 15:33 +0300, Avi Kivity wrote:
> The suggestion I liked best (Anthony's) was
>
> struct vmx_vcpu {
> struct kvm_vcpu vcpu;
> void *vmcs;
> // other vmx-specific data
>};
>
> to move from a kvm_vcpu to a vmx_vcpu, you use container_of() (inside
(v2)
Incorporates all feedback except for the arch-pointer stuff which is still
being discussed.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h | 31 -
drivers/kvm/kvm_main.c | 26 +---
drivers/kvm/kvm_svm.h |3
drivers/kvm/svm.c | 322
Gregory Haskins wrote:
>
>>
>>> struct kvm *kvm;
>>> struct preempt_hook preempt_hook;
>>> int vcpu_id;
>>> - union {
>>> - struct vmcs *vmcs;
>>> - struct vcpu_svm *svm;
>>> - };
>>> + void *_priv;
>>>
>>>
>> The other cooks did this by embeddin
On Thu, 2007-07-26 at 13:03 +0300, Avi Kivity wrote:
> This is okay as a temporary measure, until the vcpu array is replaced by
> a vcpu pointer array (when vcpu->valid can be replaced by vcpu != NULL).
Ack
>
>
> > struct kvm *kvm;
> > struct preempt_hook preempt_hook;
> > int vcp
Rusty Russell wrote:
> On Thu, 2007-07-26 at 00:31 -0400, Gregory Haskins wrote:
>
>> This is a cleanup patch to "de-VMX" the general code. It was developed in
>> the
>> preempt-hooks branch, but it should apply elsewhere as well.
>>
>
> Hi Gregory,
>
> Great minds think alike. Thi
Gregory Haskins wrote:
> This is a cleanup patch to "de-VMX" the general code. It was developed in the
> preempt-hooks branch, but it should apply elsewhere as well.
>
>
Many cooks on this patch...
> @@ -310,16 +301,13 @@ void kvm_io_bus_register_dev(struct kvm_io_bus *bus,
>
On Thu, 2007-07-26 at 00:31 -0400, Gregory Haskins wrote:
> This is a cleanup patch to "de-VMX" the general code. It was developed in the
> preempt-hooks branch, but it should apply elsewhere as well.
Hi Gregory,
Great minds think alike. This is a little rough, but I decided to send
it
This is a cleanup patch to "de-VMX" the general code. It was developed in the
preempt-hooks branch, but it should apply elsewhere as well.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h | 33 +
drivers/kvm/kvm_main.c | 12 +-
drivers/kvm/kvm_svm.h |3
17 matches
Mail list logo
