> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo > Bonzini > Sent: Friday, December 19, 2014 7:59 PM > To: Wu, Feng; Paolo Bonzini; Zhang, Yang Z; Thomas Gleixner; Ingo Molnar; H. > Peter Anvin; x86@xxxxxxxxxx; Gleb Natapov; dwmw2@xxxxxxxxxxxxx; > joro@xxxxxxxxxx; Alex Williamson; Jiang Liu > Cc: iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; KVM list; > Eric Auger > Subject: Re: [v3 13/26] KVM: Define a new interface kvm_find_dest_vcpu() for > VT-d PI > > > > On 19/12/2014 02:30, Wu, Feng wrote: > >>> How this can work well? All subsequent interrupts are delivered to > >>> one vCPU? It shouldn't be the best solution, need more consideration. > >> > >> Well, it's a hardware limitation. The alternative (which is easy to > >> implement) is to only do PI for single-CPU interrupts. This should work > >> well for multiqueue NICs (and of course for UP guests :)), so perhaps > >> it's a good idea to only support that as a first attempt. > >> > >> Paolo > > > > Paolo, what do you mean by "single-CPU interrupts"? Do you mean we don't > > support lowest priority interrupts for PI? But Linux OS uses lowest priority > > for most of the case? If so, we can hardly get benefit from this feature for > > Linux guest OS. > > You can post lowest priority interrupts if they are delivered to a > single CPU, in which case they are effectively fixed priority. > > If they are broadcast to multiple CPUs, do not post them. > > Paolo In my understanding, lowest priority interrupts are always delivered to a Single CPU, we need to find the right destination CPU from the cpumask. This is what I do in this patch. Did I misunderstanding something in your Comments? Thanks a lot! Actually, we don't support posting broadcast/multicast interrupts, because the interrupt is associated with one Posted-interrupts descriptor, then one vCPU. Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
