>>> 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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to