Gleb Natapov wrote on 2012-12-27:
> On Thu, Dec 27, 2012 at 06:34:37AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-27:
>>> On Thu, Dec 27, 2012 at 03:32:47AM +0000, Zhang, Yang Z wrote:
>>>> Marcelo Tosatti wrote on 2012-12-21:
>>>>> On Mon, Dec 17, 2012 at 01:30:49PM +0800, Yang Zhang wrote:
>>>>>> From: Yang Zhang <yang.z.zhang@xxxxxxxxx>
>>>>>>
>>>>>> @@ -3925,6 +3942,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx
>>> *vmx)
>>>>>> vmx_secondary_exec_control(vmx));
>>>>>> }
>>>>>> + if (enable_apicv_reg_vid) {
>>>>>> + vmcs_write64(EOI_EXIT_BITMAP0, 0);
>>>>>> + vmcs_write64(EOI_EXIT_BITMAP1, 0);
>>>>>> + vmcs_write64(EOI_EXIT_BITMAP2, 0);
>>>>>> + vmcs_write64(EOI_EXIT_BITMAP3, 0);
>>>>>> +
>>>>>> + vmcs_write16(GUEST_INTR_STATUS, 0);
>>>>>> + }
>>>>>
>>>>> AFAICS SVI should be regenerated on migration. Consider:
>>>>>
>>>>> 1. vintr delivery, sets SVI = vector = RVI.
>>>>> 2. clears RVI.
>>>>> 3. migration.
>>>>> 4. RVI properly set from VIRR on entry.
>>>>> 5. SVI = 0.
>>>>> 6. EOI -> EOI virtualization with SVI = 0.
>>>>>
>>>>> Could hook into kvm_apic_post_state_restore() to do that (set highest
>>>>> index of bit set in VISR).
>>>> Ok. How about to make a request(KVM_REQ_UPDATE_SVI) and handle it in
>>>> vmentry to set highest index of bit in VISR to RVI.
>>>>
>>> Just do it in kvm_apic_post_state_restore() directly, no need to do
>>> a request.
>> What you mean "do it directly". Since we are not in target vcpu's context, we
> cannot access vmcs at this point. We still need a request or variable to indicate
> the migration happened.
>>
> We are in a target vcpu context.
Ok, I misread the code.
Best regards,
Yang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
