FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

Wrong mailing list.
Resend :-(

Dong, Eddie wrote:
> Avi:
> 	This patch may be questionable at least for current VMX.
> 	If VM_ENTRY_INTR_INFO_FIELD is already set valid by
> previous irq injection, next injection will be refused with IRQ window
> enabled. This is because current implementation will inject exception
> earlier than irq injection and vmx_intr_assist doesn;t know if
> previous injected event is external irq (and thus overwrite) or
> exception. Guest will see lower priority irq get injected rather than
> higher 
> priority IRQ which
> arrives later.
> 
> 	BTW, I didn't see obvious benfit from this patch since
> inject_pending_irq still happens later after IRQ disable. maybe I
> miss something. 
> 
> thx,eddie
> 
> 
> 
> 
> kvm-commits-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>> repository: /home/avi/kvm/linux-2.6
>> branch: master
>> commit 817b54a86b0a3e0e5955714b84577101ffff9c59
>> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
> Wrong mailing list.
> Resend :-(
>
>   

(and here's a copy of my reply if someone is interested)

> Dong, Eddie wrote:
>   
>> Avi:
>> 	This patch may be questionable at least for current VMX.
>> 	If VM_ENTRY_INTR_INFO_FIELD is already set valid by
>> previous irq injection, next injection will be refused with IRQ window
>> enabled. This is because current implementation will inject exception
>> earlier than irq injection and vmx_intr_assist doesn;t know if
>> previous injected event is external irq (and thus overwrite) or
>> exception. Guest will see lower priority irq get injected rather than
>> higher 
>> priority IRQ which
>> arrives later.
>>
>>     

Well, the same thing happens with the code before this commit, no?  If a
high priority interrupt arrives after injection, it will have to wait. 
The difference is that before this commit, it woke up with the IPI and
now it notices with KVM_REQ_INTR.

The window grew larger, but not by much typically.



>> 	BTW, I didn't see obvious benfit from this patch since
>> inject_pending_irq still happens later after IRQ disable. maybe I
>> miss something. 
>>
>>     


That was accidental; I corrected it.



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

>>> previous irq injection, next injection will be refused with IRQ
>>> window enabled. This is because current implementation will inject
>>> exception earlier than irq injection and vmx_intr_assist doesn;t
>>> know if previous injected event is external irq (and thus
>>> overwrite) or exception. Guest will see lower priority irq get
>>> injected rather than higher priority IRQ which
>>> arrives later.
>>> 
>>> 
> 
> Well, the same thing happens with the code before this commit,
> no?  If a

Why? 
The philosiphy here is that the vCPU may receive new virtual irqs,
but it will not try to injected. From guest point of view, an old irq
(say irq_lo) arrives earlier and right before the virtual instruction
boundary,
and thus get responsed, while the new high priority irq (irq_hi) arrives
a little bit later than irq_lo, but right after the instruction boundary
and thus couldn't preempt irq_lo.

When guest response to irq_lo, eflag.if=0, so irq_hi can't be responsed
at that time although it see irq_hi in IRR.

That align with native where it uses micro-code.

If we enable pirq before physical irq is delivered, current code has 
obvious issue (see below comments too).
If we insist to move virq deliver out of irq disable. Then we need to
avoid 2nd injection of irq. But a big side effect is that frequently 
higher priority irq such as NIC/IDE irq will arrive right after lower
priority irq which will obviously hurt various benchmark and even
correctness.

I will argue the necessaity of this code movement. A VM
Exit/Resume itself probably will block system responsibility 
(can't deliver irq) in the level of 1K cycles, interrupt injection is
clearly far less than this granularity. Probably less than 100cycles.


> high priority interrupt arrives after injection, it will have to wait.
> The difference is that before this commit, it woke up with the IPI and
> now it notices with KVM_REQ_INTR.

When physical IRQ is disabled, the physical IPI will not interrupt 
pCPU, it get delivered only after we resume to guest.

> 
> The window grew larger, but not by much typically.


Maybe not much typical, but will frequently happen.
With this commit, now the window becomes huge since 
vcpu deschedule may happen :-(

Another serious issue in current code is that due to previous 
injection, the irq is already consumed, (IRR->ISR). So if there
are higher priority IRQs arrive later after the previous injection,
now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.

I will guess this one is the major problem source if no-kvm-irqchip
& kvm_irqchip still has difference. And I bet it should cause many
issues.

thx,eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
>>>> previous irq injection, next injection will be refused with IRQ
>>>> window enabled. This is because current implementation will inject
>>>> exception earlier than irq injection and vmx_intr_assist doesn;t
>>>> know if previous injected event is external irq (and thus
>>>> overwrite) or exception. Guest will see lower priority irq get
>>>> injected rather than higher priority IRQ which
>>>> arrives later.
>>>>
>>>>
>>>>         
>> Well, the same thing happens with the code before this commit,
>> no?  If a
>>     
>
> Why? 
> The philosiphy here is that the vCPU may receive new virtual irqs,
> but it will not try to injected. From guest point of view, an old irq
> (say irq_lo) arrives earlier and right before the virtual instruction
> boundary,
> and thus get responsed, while the new high priority irq (irq_hi) arrives
> a little bit later than irq_lo, but right after the instruction boundary
> and thus couldn't preempt irq_lo.
>
> When guest response to irq_lo, eflag.if=0, so irq_hi can't be responsed
> at that time although it see irq_hi in IRR.
>
> That align with native where it uses micro-code.
>
> If we enable pirq before physical irq is delivered, current code has 
> obvious issue (see below comments too).
> If we insist to move virq deliver out of irq disable. Then we need to
> avoid 2nd injection of irq. But a big side effect is that frequently 
> higher priority irq such as NIC/IDE irq will arrive right after lower
> priority irq which will obviously hurt various benchmark and even
> correctness.
>
> I will argue the necessaity of this code movement. A VM
> Exit/Resume itself probably will block system responsibility 
> (can't deliver irq) in the level of 1K cycles, interrupt injection is
> clearly far less than this granularity. Probably less than 100cycles.
>
>   

The reason for the code movement is that interrupt injection in real 
mode on Intel must be emulated, which means writing into guest memory, 
which means sleeping operations once swap is enabled.  A side benefit is 
removing the lapic calculations from the critical section.

But I still don't understand your object.  The interrupt has to be 
committed sometime.  We move the commit point earlier by the time it 
takes to ->prepare_guest_switch() (normally zero, but sometimes some 
thousand cycles), and kvm_load_guest_fpu() (usually zero as well).  The 
timing is sometimes worse, but there was always a window where a high 
priority interrupt is ignored over low priority interrupts.

[we can try to improve it by using vm86 interrupt redirection which may 
allow event injection using VT instead of writing to the guest stack].

>   
>> high priority interrupt arrives after injection, it will have to wait.
>> The difference is that before this commit, it woke up with the IPI and
>> now it notices with KVM_REQ_INTR.
>>     
>
> When physical IRQ is disabled, the physical IPI will not interrupt 
> pCPU, it get delivered only after we resume to guest.
>
>   

But the effect is the same: the high priority interrupt is delayed.

>> The window grew larger, but not by much typically.
>>     
>
>
> Maybe not much typical, but will frequently happen.
> With this commit, now the window becomes huge since 
> vcpu deschedule may happen :-(
>
>   

If the vcpu is descheduled, then both interrupts are delayed, by much 
more than it takes to process a single one.  If we're descheduled then 
interrupt priority is a very small problem with respect to timing.

> Another serious issue in current code is that due to previous 
> injection, the irq is already consumed, (IRR->ISR). So if there
> are higher priority IRQs arrive later after the previous injection,
> now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.
>
>   

I don't understand why.  If an event is pending in 
VM_ENTRY_INTR_INFO_FIELD, then we don't call kvm_cpu_get_interrupt() at all.

> I will guess this one is the major problem source if no-kvm-irqchip
> & kvm_irqchip still has difference. And I bet it should cause many
> issues.
>   
Well, I can thing of a workaround by using vm86 interrupt redirection.  
But I'm not convinced it is necessary.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

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

Avi Kivity wrote:
>> I will argue the necessaity of this code movement. A VM
>> Exit/Resume itself probably will block system responsibility
>> (can't deliver irq) in the level of 1K cycles, interrupt injection is
>> clearly far less than this granularity. Probably less than 100cycles.
>> 
>> 
> 
> The reason for the code movement is that interrupt injection in real
> mode on Intel must be emulated, which means writing into guest memory,
> which means sleeping operations once swap is enabled.  A side

OK, that is the difference between Xen & KVM.
An alternative is to lock the pages when in rmode before we disable
irq. But let us see if we can live with this movement.

> benefit is
> removing the lapic calculations from the critical section.
> 
> But I still don't understand your object.  The interrupt has to be
> committed sometime.  We move the commit point earlier by the time it
> takes to ->prepare_guest_switch() (normally zero, but sometimes some
> thousand cycles), and kvm_load_guest_fpu() (usually zero as
> well).  The
> timing is sometimes worse, but there was always a window where a high
> priority interrupt is ignored over low priority interrupts.

Yes even in rare native when 2 irqs arrives at almost same time.
But now we have frequent happenings. Guest frequently see
higher irq pending. Let us keep an eye to see if it will hurt something.

Then probably need this patch?

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index aab465d..46ad3b7 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2165,6 +2165,7 @@ again:
        if (unlikely(r))
                goto out;

+       vcpu->guest_mode = 1;
        kvm_inject_pending_timer_irqs(vcpu);
        clear_bit(KVM_REQ_INTR, &vcpu->requests);
        if (irqchip_in_kernel(vcpu->kvm))
@@ -2183,6 +2184,7 @@ again:
                local_irq_enable();
                preempt_enable();
                r = -EINTR;
+               vcpu->guest_mode = 0;
                kvm_run->exit_reason = KVM_EXIT_INTR;
                ++vcpu->stat.signal_exits;
                goto out;
@@ -2192,6 +2194,7 @@ again:
                if (test_and_clear_bit(KVM_REQ_TLB_FLUSH,
&vcpu->requests))
                        kvm_x86_ops->tlb_flush(vcpu);
                if (test_bit(KVM_REQ_INTR, &vcpu->requests)) {
+                       vcpu->guest_mode = 0;
                        local_irq_enable();
                        preempt_enable();
                        r = 1;
@@ -2199,7 +2202,6 @@ again:
                }
        }

-       vcpu->guest_mode = 1;
        kvm_guest_enter();

        kvm_x86_ops->run(vcpu, kvm_run);


> 
> [we can try to improve it by using vm86 interrupt redirection
> which may
> allow event injection using VT instead of writing to the guest stack].

:) Love this much more personaly, or lock pages.

> 

>> 
> 
> If the vcpu is descheduled, then both interrupts are delayed, by much
> more than it takes to process a single one.  If we're descheduled then
> interrupt priority is a very small problem with respect to timing.
> 
>> Another serious issue in current code is that due to previous
>> injection, the irq is already consumed, (IRR->ISR). So if there
>> are higher priority IRQs arrive later after the previous injection,
>> now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.
>> 
>> 
> 
> I don't understand why.  If an event is pending in
> VM_ENTRY_INTR_INFO_FIELD, then we don't call
> kvm_cpu_get_interrupt() at all.
> 
This is for protect mode. real mode is not setting this one,
and thus double consumed.

But this is fixable with other additional logic. My point is that
we may see more potential issues now :-(


Eddie

[-- Attachment #2: ll --]
[-- Type: application/octet-stream, Size: 1162 bytes --]

guest_mode is used for kvm_vcpu_kick as indicate to
whether send pIPI. With irq injection code moved
to earlier place, setting of this variable also need
to be moved up.

Signed-off-by: Yaozu (Eddie) Dong <eddie.dong@intel.com>

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index aab465d..46ad3b7 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2165,6 +2165,7 @@ again:
 	if (unlikely(r))
 		goto out;
 
+	vcpu->guest_mode = 1;
 	kvm_inject_pending_timer_irqs(vcpu);
 	clear_bit(KVM_REQ_INTR, &vcpu->requests);
 	if (irqchip_in_kernel(vcpu->kvm))
@@ -2183,6 +2184,7 @@ again:
 		local_irq_enable();
 		preempt_enable();
 		r = -EINTR;
+		vcpu->guest_mode = 0;
 		kvm_run->exit_reason = KVM_EXIT_INTR;
 		++vcpu->stat.signal_exits;
 		goto out;
@@ -2192,6 +2194,7 @@ again:
 		if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests))
 			kvm_x86_ops->tlb_flush(vcpu);
 		if (test_bit(KVM_REQ_INTR, &vcpu->requests)) {
+			vcpu->guest_mode = 0;
 			local_irq_enable();
 			preempt_enable();
 			r = 1;
@@ -2199,7 +2202,6 @@ again:
 		}
 	}
 
-	vcpu->guest_mode = 1;
 	kvm_guest_enter();
 
 	kvm_x86_ops->run(vcpu, kvm_run);

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: 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

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
>
>> benefit is
>> removing the lapic calculations from the critical section.
>>
>> But I still don't understand your object.  The interrupt has to be
>> committed sometime.  We move the commit point earlier by the time it
>> takes to ->prepare_guest_switch() (normally zero, but sometimes some
>> thousand cycles), and kvm_load_guest_fpu() (usually zero as
>> well).  The
>> timing is sometimes worse, but there was always a window where a high
>> priority interrupt is ignored over low priority interrupts.
>>     
>
> Yes even in rare native when 2 irqs arrives at almost same time.
> But now we have frequent happenings. Guest frequently see
> higher irq pending. Let us keep an eye to see if it will hurt something.
>
> Then probably need this patch?
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index aab465d..46ad3b7 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2165,6 +2165,7 @@ again:
>         if (unlikely(r))
>                 goto out;
>
> +       vcpu->guest_mode = 1;
>         kvm_inject_pending_timer_irqs(vcpu);
>         clear_bit(KVM_REQ_INTR, &vcpu->requests);
>         if (irqchip_in_kernel(vcpu->kvm))
> @@ -2183,6 +2184,7 @@ again:
>                 local_irq_enable();
>                 preempt_enable();
>                 r = -EINTR;
> +               vcpu->guest_mode = 0;
>                 kvm_run->exit_reason = KVM_EXIT_INTR;
>                 ++vcpu->stat.signal_exits;
>                 goto out;
> @@ -2192,6 +2194,7 @@ again:
>                 if (test_and_clear_bit(KVM_REQ_TLB_FLUSH,
> &vcpu->requests))
>                         kvm_x86_ops->tlb_flush(vcpu);
>                 if (test_bit(KVM_REQ_INTR, &vcpu->requests)) {
> +                       vcpu->guest_mode = 0;
>                         local_irq_enable();
>                         preempt_enable();
>                         r = 1;
> @@ -2199,7 +2202,6 @@ again:
>                 }
>         }
>
> -       vcpu->guest_mode = 1;
>         kvm_guest_enter();
>
>         kvm_x86_ops->run(vcpu, kvm_run);
>
>   

I don't see why this is needed.  The interrupt code will 
set_bit(KVM_REQ_INTR) even if the vcpu is not in guest mode.


>   
>> [we can try to improve it by using vm86 interrupt redirection
>> which may
>> allow event injection using VT instead of writing to the guest stack].
>>     
>
> :) Love this much more personaly, or lock pages.
>
>   

We could lock the pages like this:

- do the interrupt injection
    - if a real mode interrupt, abort, and set a flag requesting to lock 
the guest pages
        - exit the critical section
        - notice the flag is set, lock guest stack
        - retry
    - otherwise, proceed with injection

but using vm86 interrupt redirection is better.


>>> Another serious issue in current code is that due to previous
>>> injection, the irq is already consumed, (IRR->ISR). So if there
>>> are higher priority IRQs arrive later after the previous injection,
>>> now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.
>>>
>>>
>>>       
>> I don't understand why.  If an event is pending in
>> VM_ENTRY_INTR_INFO_FIELD, then we don't call
>> kvm_cpu_get_interrupt() at all.
>>
>>     
> This is for protect mode. real mode is not setting this one,
> and thus double consumed.
>
>   

Good point.  That is also fixed by using vm86 interrupt redirection.  
I'll read some more about it.

> But this is fixable with other additional logic. My point is that
> we may see more potential issues now :-(
>
>
>   

You're right.  Well, that's the price of progress (swapping).

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

Avi Kivity wrote:
> [we can try to improve it by using vm86 interrupt redirection
> which may
> allow event injection using VT instead of writing to the guest stack].
> 
Avi:
	I did an investigation to try to find a way if we can deliver
IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
is did in protect mode with minimal changes. It looks like we can't
do that without a VMXassist similar VM86 monitor in guest.

	I guess this is too big change for us to solve this small
purpose, right? And it looks like we can still survive with current
approach :-)

thx,eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> [we can try to improve it by using vm86 interrupt redirection
>> which may
>> allow event injection using VT instead of writing to the guest stack].
>>
>>     
> Avi:
> 	I did an investigation to try to find a way if we can deliver
> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
> is did in protect mode with minimal changes. It looks like we can't
> do that without a VMXassist similar VM86 monitor in guest.
>
>   

Can you explain why a monitor is needed?  I thought of using the VME 
interrupt redirection bitmap, does this approach not work?

> 	I guess this is too big change for us to solve this small
> purpose, right? And it looks like we can still survive with current
> approach :-)
>
>   

Yes, but I rather liked the reduction in code and simplification from 
eliminating the special case for injecting real mode interrupts.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>> 
>>> [we can try to improve it by using vm86 interrupt redirection which
>>> may allow event injection using VT instead of writing to the guest
>>> stack]. 
>>> 
>>> 
>> Avi:
>> 	I did an investigation to try to find a way if we can deliver
>> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
>> is did in protect mode with minimal changes. It looks like we can't
>> do that without a VMXassist similar VM86 monitor in guest.
>> 
>> 
> 
> Can you explain why a monitor is needed?  I thought of using the VME
> interrupt redirection bitmap, does this approach not work?

Yes I think so at beginning. But then I realized there are tricky:
VMX will restore guest state first and then inject HW IRQ if there is.
(SDM 22.5)

SDM 3 16.3 & 16.3.1.1 says the processor will switch to protect mode
exception interrupt & exception handler instead of 8086 program IVT
which we want in this case, where the VM86 monitor resides:-(

Only software interrupt can let processor directly refer IVT per 
manual 16.3.1.1 & 22.5. So I tried to inject a software interrupt 
for guest external interrupt, but it violatesSDM 20.8.3 and 
VM Resume fails. 

This could be one of the major reason why Xen implemented a VMXAssist.

> 
>> 	I guess this is too big change for us to solve this small
>> purpose, right? And it looks like we can still survive with current
>> approach :-) 
>> 
>> 
> 
> Yes, but I rather liked the reduction in code and simplification from
> eliminating the special case for injecting real mode interrupts.

Yes, I wanna too :-)

Eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>>     
>>> Avi Kivity wrote:
>>>
>>>       
>>>> [we can try to improve it by using vm86 interrupt redirection which
>>>> may allow event injection using VT instead of writing to the guest
>>>> stack]. 
>>>>
>>>>
>>>>         
>>> Avi:
>>> 	I did an investigation to try to find a way if we can deliver
>>> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
>>> is did in protect mode with minimal changes. It looks like we can't
>>> do that without a VMXassist similar VM86 monitor in guest.
>>>
>>>
>>>       
>> Can you explain why a monitor is needed?  I thought of using the VME
>> interrupt redirection bitmap, does this approach not work?
>>     
>
> Yes I think so at beginning. But then I realized there are tricky:
> VMX will restore guest state first and then inject HW IRQ if there is.
> (SDM 22.5)
>
> SDM 3 16.3 & 16.3.1.1 says the processor will switch to protect mode
> exception interrupt & exception handler instead of 8086 program IVT
> which we want in this case, where the VM86 monitor resides:-(
>
> Only software interrupt can let processor directly refer IVT per 
> manual 16.3.1.1 & 22.5. So I tried to inject a software interrupt 
> for guest external interrupt, but it violatesSDM 20.8.3 and 
> VM Resume fails. 
>
>   

I didn't see anything in 20.8.3 regarding injection of software 
interrupts to vm86 mode.  And other sections in the manual (22.5.1) 
imply that it is possible.

Maybe it's failing on something else?  VM-entry instruction length?  I 
see that it must be in the range 1-15.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

> 
> I didn't see anything in 20.8.3 regarding injection of software
> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
> imply that it is possible. 
> 
> Maybe it's failing on something else?  VM-entry instruction length?  I
> see that it must be in the range 1-15.
> 
It is VM instruction failure with error # 7, which means bad VM control.
Also one difference for software interrupt is that HW will adjust guest 
IP automatically. 
Eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
>> I didn't see anything in 20.8.3 regarding injection of software
>> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
>> imply that it is possible. 
>>
>> Maybe it's failing on something else?  VM-entry instruction length?  I
>> see that it must be in the range 1-15.
>>
>>     
> It is VM instruction failure with error # 7, which means bad VM control.
> Also one difference for software interrupt is that HW will adjust guest 
> IP automatically. 
>   

So you could set instruction length to 1 and adjust rip backwards by 1 :)

Though you may need to remember the adjustment and undo it if you get a 
page fault on the IVT.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

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


>-----Original Message-----
>From: Avi Kivity [mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org] 
>Sent: 2007年10月26日 18:14
>To: Dong, Eddie
>Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt 
>injection out of interruptdisabled section
>
>Dong, Eddie wrote:
>>> I didn't see anything in 20.8.3 regarding injection of software
>>> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
>>> imply that it is possible. 
>>>
>>> Maybe it's failing on something else?  VM-entry instruction 
>length?  I
>>> see that it must be in the range 1-15.
>>>
>>>     
>> It is VM instruction failure with error # 7, which means bad 
>VM control.
>> Also one difference for software interrupt is that HW will 
>adjust guest 
>> IP automatically. 
>>   
>
>So you could set instruction length to 1 and adjust rip 
>backwards by 1 :)
>
>Though you may need to remember the adjustment and undo it if 
>you get a 
>page fault on the IVT.
>
>
What I mean is HW implicitly take SW interrupt as what it should be.
And check exception #.


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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- 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

Re: FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

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

Dong, Eddie wrote:
>>>   
>>>       
>> So you could set instruction length to 1 and adjust rip 
>> backwards by 1 :)
>>
>> Though you may need to remember the adjustment and undo it if 
>> you get a 
>> page fault on the IVT.
>>
>>
>>     
> What I mean is HW implicitly take SW interrupt as what it should be.
> And check exception #.
>   

Sorry, I don't understand. Exception number for software interrupt can
be anything?

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



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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- 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