Re: [PATCH v3] KVM: Introduce direct MSI message injection for in-kernel irqchips

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-04-13 00:38, Marcelo Tosatti wrote:
>>> Have you checked that direct MSI injection does not make use of 
>>> IRQ routing data structures, such as for acking? 
>>
>> See kvm_set_msi: The routing structure is only read in the context of
>> that function, no reference is kept.
> 
> I was thinking more along the lines of inconsistent state
> due to races.
> 
> - set MSI for IOAPIC handled vector before kvm->irq_routing 
> is assigned.
> - IOAPIC EOI for that vector.
> - EOI handler expects kvm->irq_routing present.

OK, starting to understand your worries. But isn't kvm->irq_routing
always pointing to some traversable table after KVM_CREATE_IRQCHIP? If
not, that race would have been exploitable before.

> 
>>> irqchip_in_kernel(kvm) returns true before kvm->irq_routing is 
>>> actually in place. With kvm_set_irq there is no problem, but now
>>> there is another path into injection.
>>>
>>> The real purpose of this is not entirely clear (and as Avi mentioned two
>>> interfaces should be avoided if possible).
>>
>> See [1] for an implementation of one of Avi's proposals.
> 
> Just now that i start to appreciate KVM_SIGNAL_MSI.
> 
> "so we have a single ioctl for all interrupt handling.  This allows
> eventual removal of the line-oriented ioctls." 
> 
> So you move from one interface that handles both MSI/INTx, to _another_
> interface that handles both. KVM_SIGNAL_MSI with address/data is clean
> and obvious.

Well, I'm just looking for a MSI message injection mechanism. So I'm
fine with both KVM_GENERAL_IRQ and KVM_SIGNAL_MSI.

KVM_GENERAL_IRQ /may/ be helpful for kernel irqchips of upcoming arch if
they need to provide IRQ injection paths that do not match well on the
existing ones. However, it will surely take a long while until we can
drop KVM_IRQ_LINE/KVM_IRQ_LINE_STATUS.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux