Re: [PATCH v8 18/27] ARM: vITS: handle MAPD command

[Andre Przywara <andre.przywara@arm.com>]

Hi,

On 12/04/17 18:05, Julien Grall wrote:
> Hi Andre,
> 
> On 12/04/17 18:03, Andre Przywara wrote:
>> On 12/04/17 16:21, Julien Grall wrote:
>>> On 12/04/17 01:44, Andre Przywara wrote:
>>>> +
>>>> +    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
>>>> +
>>>> +    /* Remove the corresponding host LPI entry */
>>>> +    return gicv3_remove_guest_event(its->d, its->doorbell_address,
>>>> +                                    vdevid, vevid);
>>>> +}
>>>> +
>>>> +static int its_unmap_device(struct virt_its *its, uint32_t devid)
>>>> +{
>>>> +    uint64_t itt, evid;
>>>> +    int ret;
>>>> +
>>>> +    spin_lock(&its->its_lock);
>>>> +
>>>> +    ret = its_get_itt(its, devid, &itt);
>>>> +    if ( ret )
>>>> +    {
>>>> +        spin_unlock(&its->its_lock);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    for ( evid = 0; evid < DEV_TABLE_ITT_SIZE(itt); evid++ )
>>>> +        /* Don't care about errors here, clean up as much as
>>>> possible. */
>>>> +        its_discard_event(its, devid, evid);
>>>> +
>>>> +    spin_unlock(&its->its_lock);
>>>
>>> This code can be long to execute as the number of event can be huge. How
>>> do you plan to handle that?
>>
>> It is assumed that DomUs get only a *very* limited and controlled number
>> of ITS resources, so the number of LPIs, number of devices and their
>> number of events will be very small, probably just enough as really
>> needed (event ID bits being 4 or so, for instance).
> 
> I really doubt this. I would not be surprised to see PCI device
> passthrough with hundreds of event.

But that's not *huge*. Chasing down the calls from here I don't see
anything which takes a long time to execute. So the execution time
becomes only an issue if we reach into the tens of thousands of events,
but I'd rely on the responsibility of a sysadmin when passing through
devices with that large number of MSI. I'd hope that PCI passthrough
would help here with providing some means of policy limits if users care
about this.

Cheers,
Andre.

> And then we will have a beloved XSA
> to handle...
> 
>>
>>> *hint* this likely means a comment + ASSERT + TODO in the cover letter
>>> *hint*
>>
>> Added.
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel