Re: [Xen-devel] [PATCH v2] VT-d PI: disable VT-d PI when APICv is disabled

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.17 at 17:06, <chao.gao@xxxxxxxxx> wrote:
> On Wed, Jun 07, 2017 at 06:31:18AM -0600, Jan Beulich wrote:
>>>>> On 07.06.17 at 11:29, <chao.gao@xxxxxxxxx> wrote:
>>> @@ -2266,8 +2267,10 @@ int __init intel_vtd_setup(void)
>>>           * We cannot use posted interrupt if X86_FEATURE_CX16 is
>>>           * not supported, since we count on this feature to
>>>           * atomically update 16-byte IRTE in posted format.
>>> +         * VT-d PI implementation relies on APICv. Thus, disable
>>> +         * VT-d PI when APICv is disabled.
>>>           */
>>> -        if ( !cap_intr_post(iommu->cap) || !cpu_has_cx16 )
>>> +        if ( !cap_intr_post(iommu->cap) || !cpu_has_cx16 || 
>>> !opt_apicv_enabled )
>>>              iommu_intpost = 0;
>>
>>I'm sorry for thinking of this only now, but why do you check the
>>command line option here instead of whether APIC-V is actually
>>in use? I guess there's not going to be hardware supporting VT-d
>>PI but not APIC-V (albeit one is a chipset feature aiui and the
>>other a CPU one, so they are kind of independent), but I could
>>easily imagine hypervisors supporting them entirely independently.
>>Hence I think you would be better off checking the relevant
>>secondary exec bit(s).
> 
> Those relevant structure hasn't been initialized here. But your
> thought is definitely right. How about clear iommu_intpost in
> vmx_init_vmcs_config() when finding cpu-side interrupt posting
> can't be enabled?

If clearing the flag is all it takes - sure.

Jan


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