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

[Julien Grall <julien.grall@arm.com>]

On 05/10/2017 11:42 AM, Andre Przywara wrote:
> Hi,

Hi Andre,

> 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.

I am getting annoyed to repeat that again and again. Xen has to deal 
with *any* number of MSIs as long as the spec says it is possible and 
not expose a security issue. The problem can appear easily because of 
command time may be multiplied * 32K if the guest decides to queue 32K 
command.

How a sysadmin, which very likely does not know the internal Xen, would 
know that he should not passing through devices with that large number 
of MSI? Surely he will not be able to guess that the ITS code is not 
able to cope with any number without any documentation.

I really don't want to have to deal with XSAs because you knowingly hide 
a potential issue thinking someone else will fix for you.

Cheers,

-- 
Julien Grall

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