On 2/5/19 6:35 AM, David Gibson wrote:
> On Mon, Feb 04, 2019 at 08:07:20PM +0100, Cédric Le Goater wrote:
>> On 2/4/19 5:57 AM, David Gibson wrote:
>>> On Mon, Jan 07, 2019 at 07:43:21PM +0100, Cédric Le Goater wrote:
> [snip]
>>>> + sb = kvmppc_xive_create_src_block(xive, irq);
>>>> + if (!sb) {
>>>> + pr_err("Failed to create block...\n");
>>>> + return -ENOMEM;
>>>> + }
>>>> + }
>>>> + state = &sb->irq_state[idx];
>>>> +
>>>> + if (get_user(val, ubufp)) {
>>>> + pr_err("fault getting user info !\n");
>>>> + return -EFAULT;
>>>> + }
>>>> +
>>>> + /*
>>>> + * If the source doesn't already have an IPI, allocate
>>>> + * one and get the corresponding data
>>>> + */
>>>> + if (!state->ipi_number) {
>>>> + state->ipi_number = xive_native_alloc_irq();
>>>> + if (state->ipi_number == 0) {
>>>> + pr_err("Failed to allocate IRQ !\n");
>>>> + return -ENOMEM;
>>>> + }
>>>
>>> Am I right in thinking this is the point at which a specific guest irq
>>> number gets bound to a specific host irq number?
>>
>> yes. the XIVE IRQ state caches this information and 'state' should be
>> protected before being assigned, indeed ... The XICS-over-XIVE device
>> also has the same race issue.
>>
>> It's not showing because where initializing the KVM device sequentially
>> from QEMU and only once.
>
> Ok.
>
> So, for the passthrough case, what's the point at which we know that a
> particular guest interrupt needs to be bound to a specific real
> hardware interrupt, rather than a generic IPI?
when the guest driver requests MSIs, VFIO requests a mapping of the
HW irqs in the guest IRQ space. This is very briefly said as VFIO is
a huge framework.
Patch 18 adds some initial support to handle the ESB pages but this
should be done at the QEMU level.
C.
