Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

[Raghavendra K T <raghukt@xxxxxxxxxxxxxxxxxx>]

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> > > +/*
> > > + * kvm_pv_kick_cpu_op: Kick a vcpu.
> > > + *
> > > + * @cpu - vcpu to be kicked.
> > > + */
> > > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> > > +{
> > > + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> > There is no guarantee that guest cpu numbers match host vcpu numbers.
> > Use APIC IDs, and kvm_apic_match_dest().
> Okay. I have to dig more on this.
Sorry for late reply on this, was experimenting with the changes needed.

Wanted to confirm if it is according to your expectation.

 Host side change should look like this to get vcpu,

        int i;
        struct kvm_vcpu *vcpu = NULL;

        kvm_for_each_vcpu(i, vcpu, kvm) {
                if (!kvm_apic_present(vcpu))
                continue;

                if (kvm_apic_match_dest(vcpu, 0, 0, cpu, 0)) {
                break;
                }
        }


In guest side, convert the cpu to apicid using,

apicid = apic->cpu_present_to_apicid(cpu);
OR
apicid =  per_cpu(x86_cpu_to_apicid, cpu);

But I have a question, as you know, we are storing the waiting cpus in
cpumask, to track the cpu to be kicked.

You want to change the logic to store the apicid directly instead of
cpu during contention or is it OK to convert before kick hypercall?.

Probably it would be more good if I can get to know the scenario,
where guest cpu numbers does not match host vcpu numbers. It may answer 
the whole question and help me in testing/validating the code.
Thanks
- Raghu








_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel