[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Enabling VT-d PI by default



>>> On 18.04.17 at 05:41, <chao.gao@xxxxxxxxx> wrote:
> On Tue, Apr 18, 2017 at 02:13:36AM -0600, Jan Beulich wrote:
>>>>> On 16.04.17 at 22:13, <chao.gao@xxxxxxxxx> wrote:
>>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>>> maximum of entry we support in the list. With this approach, during
>>> domain creation, we calculate the available entries and compare with
>>> the domain's vCPU number to decide whether the domain can use VT-d PI.
>>> This method will pose a strict restriction to the maximum of entry in
>>> one list. But it may affect vCPU hotplug. 
>>
>>I don't view this as really suitable - irq_guest_action is quite different,
>>as one can reasonably place expectations on how many devices may
>>share an interrupt line. If someone really hit this boundary, (s)he
>>could likely re-configure their system by moving expansion cards
>>between slots. Neither of this is comparable with the PI situation, as
>>it looks to me.
>>
>>Furthermore, whether a guest would be able to start / use PI would
>>be quite hard to tell for an admin as it seems, again as opposed to
>>the case with the shared interrupt lines.
> 
> Indeed. It would annoy the admin. What's your opinion on the
> first and second methods? Do you think we need such policy to
> restrict the #entry in the list even with the first two methods?

Well, I'm in agreement with Kevin that all reasonable approaches
should be made use of here, so I'd like to defer a decision on a
forced limit until we see what effects can be achieved by the other
two methods.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.