On Thu, Mar 14, 2013 at 04:32:16PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:28, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 13:18, Gleb Natapov wrote:
> >>> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> On 2013-03-14
On 2013-03-14 13:28, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 13:18, Gleb Natapov wrote:
>>> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
On 2013-03-14 13:12, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 12:29:48PM +
On Thu, Mar 14, 2013 at 11:32:59AM -0300, Marcelo Tosatti wrote:
> > > Also the fact kvm_apic_accept_events() is called from sites is annoying,
> > > why is that necessary again?
> >
> > - to avoid having pending events in the APIC when delivering mp_state
> > to user space
> > - to keep mp_stat
On Thu, Mar 14, 2013 at 11:15:02AM +0100, Jan Kiszka wrote:
> On 2013-03-14 01:08, Marcelo Tosatti wrote:
> > On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> >> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> >> remote VCPU's mp_state. When we were unlucky, KVM_
On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:18, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 13:12, Gleb Natapov wrote:
> >>> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> On 2013-03-14
On 2013-03-14 13:18, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 13:12, Gleb Natapov wrote:
>>> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
On 2013-03-14 11:15, Jan Kiszka wrote:
>>>
>>> - if (unlikely(vcpu-
On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:12, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 11:15, Jan Kiszka wrote:
> >
> > - if (unlikely(vcpu->arch.mp_state ==
> > KVM_MP_STATE_SIPI
On 2013-03-14 13:12, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 11:15, Jan Kiszka wrote:
>
> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
> - pr_debug("vcpu %d received sipi with vector # %x\n",
>>
On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> On 2013-03-14 11:15, Jan Kiszka wrote:
> >>>
> >>> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
> >>> - pr_debug("vcpu %d received sipi with vector # %x\n",
> >>> - vcpu->vcpu_id, vcpu->
On 2013-03-14 11:15, Jan Kiszka wrote:
>>>
>>> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
>>> - pr_debug("vcpu %d received sipi with vector # %x\n",
>>> -vcpu->vcpu_id, vcpu->arch.sipi_vector);
>>> - kvm_lapic_reset(vcpu);
>>> -
On Thu, Mar 14, 2013 at 11:15:02AM +0100, Jan Kiszka wrote:
> On 2013-03-14 01:08, Marcelo Tosatti wrote:
> > On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> >> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> >> remote VCPU's mp_state. When we were unlucky, KVM_
On 2013-03-14 01:08, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
>> A VCPU sending INIT or SIPI to some other VCPU races for setting the
>> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
>> was overwritten by kvm_emulate_halt and, t
> vmx_vcpu_reset overwrites vcpu->srcu_idx if ->vcpu_reset is called from
> within srcu section.
>
> Also, this is not part of the hotpath and therefore it could be farther
> from vcpu_enter_guest. What about processing a new request bit here?
> (KVM_REQ_EVENT <-> apic->pending_events relationship
On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events f
On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events f
On 2013-03-13 13:27, Paolo Bonzini wrote:
> With the following hack to inject an INIT and corresponding QEMU changes:
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 2609e7b99..efdab35 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6182,8 +6182,16 @@ int kvm_ar
Il 13/03/2013 12:42, Jan Kiszka ha scritto:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events for those two sig
A VCPU sending INIT or SIPI to some other VCPU races for setting the
remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
was overwritten by kvm_emulate_halt and, thus, got lost.
This introduces APIC events for those two signals, keeping them in
kvm_apic until kvm_apic_accept_e
18 matches
Mail list logo
