2016-02-16 13:15+0100, Paolo Bonzini:
> On 16/02/2016 07:29, Suravee Suthikulpanit wrote:
>> On 2/12/16 22:38, Paolo Bonzini wrote:
>>> On 12/02/2016 14:59, Suravee Suthikulpanit wrote:
>>>> + case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
| [...]
>>>> + case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
>>>> + kvm_lapic_reg_write(apic, APIC_ICR2, icrh);
>>>> + kvm_lapic_reg_write(apic, APIC_ICR, icrl);
>>>
>>> Wouldn't this cause a double injection of the IPI if the following
>>> happens:
>>>
>>> 1) destination 1 is running, so the processor sets IRR and sends a
>>> doorbell message
>>>
>>> 2) destination 2 is not running, so the processor sets IRR and exits
>>>
>>> 3) destination 1 processes the interrupt, moving it from IRR to ISR
>>>
>>> 4) destination 1 sends an EOI
>>>
>>> 5) the source exits and reinjects the interrupt
>>>
>>> 6) destination 1 then receives the interrupt again.
>>
>> Not sure if I am following your scenario here. IIUC, your concern is
>> regarding the dest2 that was not running at the time that the IPI
>> message is sent to both dest1 and dest2?
>>
>> In this case, since the HW cannot deliver due to one ore more target
>> vcpus due to not running, I believe it would not set the IRR bit of
>> dest1, and generate the AVIC_INCOMPLETE_IPI #vmexit above instead. I
>> don't think it would progress to step 3 right away.
(AVIC handles logical interrupts and broadcasts, so there is IPI to two
destinations that won't exit with AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE.)
I assume that the whole step must be completed before a subsequent step
is started, so either all IRRs are written or none is:
3,4: If any IPI destination is not valid, then AVIC exits with
!AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN before any IRR is written.
(Broadcast ignores invalid, which is ok.)
5: AVIC will set IRR and maybe send doorbell on all valid destinations.
6: If doorbell wasn't sent to all valid destinations, exit with
AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN
(Relevant bit of the spec is at the bottom.)
> The documentation doesn't say that setting the IRR bit is atomic across
> all CPUs (and from a hardware perspective that would be extremely
> unlikely).
Yeah, I think atomic there means that it won't race with other writes to
the same byte in IRR. We're fine as long as AVIC writes IRR before
checking IsRunning on every destination, which it seems to be.
> Another hint in my opinion is that the vmexit is called
> "incomplete" IPI, not something like "aborted" IPI. "abort" might
> suggest atomicity, "incomplete" definitely suggests *non*atomicity to me.
>
> Wei, what do you think/recall?
>
> I am afraid that this could be a showstopper for AVIC support in KVM.
(It would, but I believe that AVIC designers made it sane and the spec
doesn't let me read it in a way that supports your theories.)
> The only solution I see is to have a different page for each CPU, so
> that only self-IPIs are virtualized. Then you'd only support
> virtualization of self-IPIs, similar to Intel's APICv.
We need one APIC page per VCPU and a pair (physical, logical) of APIC ID
tables per VM, but per CPU structures shouldn't be necessary.
>> I'll make sure to confirm with the HW designer again just to be sure.
>
> Please do, thanks!
Thanks, looking forward to it!
We definitely have incompatible understanding of some aspects. :)
---
APM 2, June 2015, 15.29.2.4 Interrupt Delivery:
Interprocessor Interrupts. To process an IPI, AVIC hardware executes
the following steps:
[...]
3. If the destination(s) is (are) logically addressed, lookup the
guest physical APIC IDs for each logical ID using the Logical APIC
ID table. If the entry is not valid (V bit is cleared), cause a
#VMEXIT. If the entry is valid, but contains an invalid backing
page pointer, cause a #VMEXIT.
4. Lookup the vAPIC backing page address in the Physical APIC table using
the guest physical APIC ID as an index into the table. For
directed interrupts, if the selected table entry is not valid,
cause a #VMEXIT. For broadcast IPIs, invalid entries are ignored.
5. For every valid destination:
- Atomically set the appropriate IRR bit in each of the
destinations’ vAPIC backing page.
- Check the IsRunning status of each destination.
- If the destination IsRunning bit is set, send a doorbell message
using the host physical core number from the Physical APIC ID
table.
6. If any destinations are identified as not currently scheduled on a
physical core (i.e., the IsRunning bit for that virtual processor
is not set), cause a #VMEXIT.
--
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
