On 08/07/2015 13:46, Jan Beulich wrote:
>>>> On 08.07.15 at 13:00, <kevin.t...@intel.com> wrote:
>>> @@ -1848,6 +1869,33 @@ static struct hvm_function_table __initdata
>>> vmx_function_table = {
>>> .enable_msr_exit_interception = vmx_enable_msr_exit_interception,
>>> };
>>>
>>> +/*
>>> + * Handle VT-d posted-interrupt when VCPU is blocked.
>>> + */
>>> +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
>>> +{
>>> + struct arch_vmx_struct *vmx;
>>> + unsigned int cpu = smp_processor_id();
>>> +
>>> + spin_lock(&per_cpu(pi_blocked_vcpu_lock, cpu));
>>> +
>>> + /*
>>> + * FIXME: The length of the list depends on how many
>>> + * vCPU is current blocked on this specific pCPU.
>>> + * This may hurt the interrupt latency if the list
>>> + * grows to too many entries.
>>> + */
>> let's go with this linked list first until a real issue is identified.
> This is exactly the way of thinking I dislike when it comes to code
> that isn't intended to be experimental only: We shouldn't wait
> for problems to surface when we already can see them. I.e. if
> there are no plans to deal with this, I'd ask for the feature to be
> off by default and be properly marked experimental in the
> command line option documentation (so people know to stay
> away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for longer
periods of time.
IMO, the PI feature cannot be declared as done/supported with this bug
remaining. OTOH, it is fine to be experimental, and disabled by default
for people who wish to experiment.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
