Re: [PATCH v2 1/2] iommu/amd: Don't block updates to GATag if guest mode is on

[Joao Martins <joao.m.martins@oracle.com>]

On 28/03/2023 10:07, Alexey Kardashevskiy wrote:
> On 17/3/23 07:02, Joao Martins wrote:
>> On KVM GSI routing table updates, specially those where they have vIOMMUs
>> with interrupt remapping enabled (to boot >255vcpus setups without relying
>> on KVM_FEATURE_MSI_EXT_DEST_ID), a VMM may update the backing VF MSIs
>> with a new VCPU affinity.
>>
>> On AMD with AVIC enabled, the new vcpu affinity info is updated via:
>>     avic_pi_update_irte()
>>         irq_set_vcpu_affinity()
>>             amd_ir_set_vcpu_affinity()
>>                 amd_iommu_{de}activate_guest_mode()
>>
>> Where the IRTE[GATag] is updated with the new vcpu affinity. The GATag
>> contains VM ID and VCPU ID, and is used by IOMMU hardware to signal KVM
>> (via GALog) when interrupt cannot be delivered due to vCPU is in
>> blocking state.
>>
>> The issue is that amd_iommu_activate_guest_mode() will essentially
>> only change IRTE fields on transitions from non-guest-mode to guest-mode
>> and otherwise returns *with no changes to IRTE* on already configured
>> guest-mode interrupts. To the guest this means that the VF interrupts
>> remain affined to the first vCPU they were first configured,and guest
>> will be unable to either VF interrupts and receive messages like this
>> from spuruious interrupts (e.g. from waking the wrong vCPU in GALog):
> 
> The "either" above sounds like there should be a verb which it is not, or is it?
> (my english skills are meh). I kinda get the idea anyway (I hope).
> 
It should be 'issue'. I'll delete the 'either'

> btw s/spuruious/spurious/, says my vim. Thanks,
> 
/me nods