On 20/01/2015 08:54, Wincy Van wrote:
> On Tue, Jan 20, 2015 at 3:34 PM, Paolo Bonzini wrote:
>>> Hence, we can disable local interrupts while delivering nested posted
>>> interrupts to make sure
>>> we are faster than the destination vcpu. This is a bit tricky but it
>>> an avoid that race. I
On 20/01/2015 08:54, Wincy Van wrote:
On Tue, Jan 20, 2015 at 3:34 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Hence, we can disable local interrupts while delivering nested posted
interrupts to make sure
we are faster than the destination vcpu. This is a bit tricky but it
an avoid that
On Tue, Jan 20, 2015 at 3:34 PM, Paolo Bonzini wrote:
>> Hence, we can disable local interrupts while delivering nested posted
>> interrupts to make sure
>> we are faster than the destination vcpu. This is a bit tricky but it
>> an avoid that race. I think we
>> do not need to add a spin lock
On 19/01/2015 13:34, Wincy Van wrote:
>
> Actually, there is a race window between
> vmx_deliver_nested_posted_interrupt and nested_release_vmcs12
> since posted intr delivery is async:
>
> cpu 1
> cpu 2
> (nested posted intr) (dest vcpu,
On Mon, Jan 19, 2015 at 7:43 PM, Paolo Bonzini wrote:
> Hi Wincy,
>
> there is only one thing that I don't understand in this patchset, and it is:
>
> On 16/01/2015 06:59, Wincy Van wrote:
>> + /*
>> +* if vcpu is in L2, we are fast enough to complete
>> +* before L1
Hi Wincy,
there is only one thing that I don't understand in this patchset, and it is:
On 16/01/2015 06:59, Wincy Van wrote:
> + /*
> +* if vcpu is in L2, we are fast enough to complete
> +* before L1 changes/destroys vmcs12.
> +*/
... this comment. What do you
On 19/01/2015 13:34, Wincy Van wrote:
Actually, there is a race window between
vmx_deliver_nested_posted_interrupt and nested_release_vmcs12
since posted intr delivery is async:
cpu 1
cpu 2
(nested posted intr) (dest vcpu,
On Tue, Jan 20, 2015 at 3:34 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Hence, we can disable local interrupts while delivering nested posted
interrupts to make sure
we are faster than the destination vcpu. This is a bit tricky but it
an avoid that race. I think we
do not need to add a spin
On Mon, Jan 19, 2015 at 7:43 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Hi Wincy,
there is only one thing that I don't understand in this patchset, and it is:
On 16/01/2015 06:59, Wincy Van wrote:
+ /*
+* if vcpu is in L2, we are fast enough to complete
+* before L1
Hi Wincy,
there is only one thing that I don't understand in this patchset, and it is:
On 16/01/2015 06:59, Wincy Van wrote:
+ /*
+* if vcpu is in L2, we are fast enough to complete
+* before L1 changes/destroys vmcs12.
+*/
... this comment. What do you mean
If vcpu has a interrupt in vmx non-root mode, we will
kick that vcpu to inject interrupt timely. With posted
interrupt processing, the kick intr is not needed, and
interrupts are fully taken care of by hardware.
In nested vmx, this feature avoids much more vmexits
than non-nested vmx.
This patch
If vcpu has a interrupt in vmx non-root mode, we will
kick that vcpu to inject interrupt timely. With posted
interrupt processing, the kick intr is not needed, and
interrupts are fully taken care of by hardware.
In nested vmx, this feature avoids much more vmexits
than non-nested vmx.
This patch
12 matches
Mail list logo
