Re: [PATCH 0/7] Rework irq injection infrastructure

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

Dong, Eddie wrote:
> It is not a small change, I still need to study the whole patch :(
> If I can get some question clarified earlier, that helps a lot.
>
>
>   
>> -----Original Message-----
>> From: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>> [mailto:kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>> Avi Kivity
>> Sent: 2007年12月4日 17:44
>> To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> Subject: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure
>>
>> The current irq and exception injection infrastructure is 
>> quite complex and
>> has been the source of a number of bugs in the past.  This 
>> patchset simplifies
>> irq and exception injection:
>>
>> - Much more work is carried out in common code rather than 
>> vmx/svm specific
>>  code.  Information is kept in C variables rather than 
>> hardware registers
>>
>> - Exception and interrupts are separated into two independent 
>> queues.  This
>>  will allow later optimization on AMD where the hardware 
>> supports two queues,
>>  and also simplifies the Intel case as now we don't need to 
>> check the hardware
>>  whether an exception is pending when injecting and interrupt.
>>
>> - Interrupts are now only acked after they have been 
>> successfully injected,
>>     
>
> Mmm, how can you know if it is injected successfully?
> From the patch, it looks like you know this by checking
> IDT_Vectoring in next VM Exit. That means the virtual 
> interrupt controller state in memory is incorrect temply.
>
> If the injection success & we can get VM Exit before 
> next access to those virtual interrupt controller state,
> that will be OK, 

That's the idea.

> but that means we eliminate future HW
> optimization opportunity.  I think we just pay too much
> for coding style reason to narrow HW optimization space.
>   

I don't know enough about future hardware...

But the motivation here is not coding style, it's to be able to do the
injection non-atomically. The tpr-opt patchset wants to write the tpr to
memory, and that is a sleeping operation. Similarly, if we emulate big
real mode we need to simulate interrupt injection by writing to the stack.

Moving the logic to common code helps, but it could have been done with
the original system as well.

> If the injection fails, the previous logic will inject it back 
> immediately; current logic will do normal irq inject path.
> The potential differences are:
> 	1: If a new higher interrupt arrives, we inject new vector.
> that is probably OK.
> 	2: If the fault VM Exit is due to nested exception, the
> previous logic will probably inject double fault with the original
> interrupt consumed (acked); the new logic will probably inject
> double fault too, but keep the IRQ not consumed. I don't have
> direct case, but worry about those kind of deviation from native
> behavor.
>   

We can probably fix it to ack the interrupt when injecting a double fault.

-- 
error compiling committee.c: too many arguments to function



[-- Attachment #2: Type: text/plain, Size: 309 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel