[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
On Sun, Apr 29, 2012 at 04:18:03PM +0300, Avi Kivity wrote: > On 04/24/2012 12:59 PM, Gleb Natapov wrote: > > > > > > +/* > > > + * kvm_pv_kick_cpu_op: Kick a vcpu. > > > + * > > > + * @apicid - apicid of vcpu to be kicked. > > > + */ > > > +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid) > > > +{ > > > + struct kvm_vcpu *vcpu = NULL; > > > + int i; > > > + > > > + kvm_for_each_vcpu(i, vcpu, kvm) { > > > + if (!kvm_apic_present(vcpu)) > > > + continue; > > > + > > > + if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0)) > > > + break; > > > + } > > > + if (vcpu) { > > > + /* > > > + * Setting unhalt flag here can result in spurious runnable > > > + * state when unhalt reset does not happen in vcpu_block. > > > + * But that is harmless since that should soon result in halt. > > > + */ > > > + vcpu->arch.pv.pv_unhalted = 1; > > > + /* We need everybody see unhalt before vcpu unblocks */ > > > + smp_mb(); > > > + kvm_vcpu_kick(vcpu); > > > + } > > > +} > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We > > can use one of reserved delivery modes as PV delivery mode. We will > > disallow guest to trigger it through apic interface, so this will not be > > part of ABI and can be changed at will. > > > > I'm not thrilled about this. Those delivery modes will eventually > become unreserved. We can have a kvm_lookup_apic_id() that is shared > among implementations. > This is only internal implementation. If they become unreserved we will use something else. -- Gleb. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |