Re: [Xen-devel] [PATCH 2/4] VMX: Turn on posted interrupt bit in vmcs

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2013-04-09:
>>>> On 09.04.13 at 10:30, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2013-04-09:
>>>>>> On 09.04.13 at 08:01, Yang Zhang <yang.z.zhang@xxxxxxxxx> wrote:
>>>> --- a/xen/include/asm-x86/mach-default/irq_vectors.h
>>>> +++ b/xen/include/asm-x86/mach-default/irq_vectors.h
>>>> @@ -9,12 +9,13 @@
>>>>  #define CALL_FUNCTION_VECTOR      0xfb
>>>>  #define LOCAL_TIMER_VECTOR        0xfa
>>>>  #define PMU_APIC_VECTOR   0xf9
>>>> +#define POSTED_INTERRUPT_VECTOR   0xf8
>>> 
>>> Is it really necessary to use a static, high priority vector here?
>> There is an corner case. During vmenty, cpu will not respond external
>> interrupt. And it is possible that posted interrupt and another
>> interrupt are pending in IRR. We hope posted interrupt have high
>> priority and it can be consumed immediately after vmentry finished. Or
>> else, there may two separate interrupt arrived in hypervisor.
> 
> If there is a window, using a static, high priority vector only shrinks
> its size. If what you describe is an actual problem (and not just a
> latency issue), then it needs to be fixed properly rather just lowering
It is not a problem, it is really a latency issue. We expect to eliminate 
unnecessary interrupt as possible as we can.

> its likelihood to occur. And if it isn't, I think you ought to demonstrate
> that using a static vector indeed provides meaningful benefit over
> a dynamically allocated one.
It do happen. But hard to catch.

Also, posted interrupt have the same meaning with EVENT_CHECK_VECTOR if 
hypervisor received it. I think it is reasonable to use similar vector as 
event_check_vector did.

Best regards,
Yang


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