Kernel Panics on Xen ARM64 for Domain0 and Guest
00 [1.038570] 7e80: [1.046469] 7ea0: 08082b30 08815688 [1.054367] 7ec0: [1.062270] 7ee0: [1.070165] 7f00: [1.078064] 7f20: [1.085962] 7f40: [1.093865] 7f60: [1.101760] 7f80: [1.109659] 7fa0: [1.117557] 7fc0: 0005 [1.125460] 7fe0: [1.133355] Call trace: [1.135876] Exception stack(0x8001f6ca7af0 to 0x8001f6ca7c20) [1.142383] 7ae0: 08486608 0001 [1.150282] 7b00: 8001f6ca7cc0 08483124 08bd2cf0 08a1ad00 [1.158180] 7b20: 0001 8001f6c10190 8001f6ca7c20 08158648 [1.166079] 7b40: 08baf000 024080c0 [1.173978] 7b60: 08b25b18 08b25000 08a76fb0 0001 [1.181880] 7b80: 024080c0 08bd7000 [1.189775] 7ba0: 08a123e8 08b726e8 [1.197674] 7bc0: 03ff 7e0007d930c0 8001fff2b458 [1.205573] 7be0: 7f7f7f7f7f7f7f7f 0101010101010101 0008 8001f6c26150 [1.213472] 7c00: 8001f6c2691c deadbeef 105d2c2d [1.221372] [] bind_evtchn_to_irq+0x1c/0x108 [1.227274] [] bind_evtchn_to_irqhandler+0x28/0x90 [1.233698] [] xb_init_comms+0x6c/0xf8 [1.239078] [] xs_init+0xa8/0x1d0 [1.244028] [] xenbus_init+0x258/0x2e4 [1.249408] [] do_one_initcall+0x84/0x114 [1.255050] [] kernel_init_freeable+0x1a4/0x244 [1.261212] [] kernel_init+0x10/0x100 [1.266507] [] ret_from_fork+0x10/0x20 [1.271889] Code: f90013f5 2a0003f5 f9414820 a90153f3 (f940) [1.278065] ---[ end trace 1a0c84ed669d59e3 ]--- [1.282747] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [1.282747] [1.292025] SMP: stopping secondary CPUs [1.296045] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b -- Regards, Wei Chen IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Kernel Panics on Xen ARM64 for Domain0 and Guest
00 [1.038570] 7e80: [1.046469] 7ea0: 08082b30 08815688 [1.054367] 7ec0: [1.062270] 7ee0: [1.070165] 7f00: [1.078064] 7f20: [1.085962] 7f40: [1.093865] 7f60: [1.101760] 7f80: [1.109659] 7fa0: [1.117557] 7fc0: 0005 [1.125460] 7fe0: [1.133355] Call trace: [1.135876] Exception stack(0x8001f6ca7af0 to 0x8001f6ca7c20) [1.142383] 7ae0: 08486608 0001 [1.150282] 7b00: 8001f6ca7cc0 08483124 08bd2cf0 08a1ad00 [1.158180] 7b20: 0001 8001f6c10190 8001f6ca7c20 08158648 [1.166079] 7b40: 08baf000 024080c0 [1.173978] 7b60: 08b25b18 08b25000 08a76fb0 0001 [1.181880] 7b80: 024080c0 08bd7000 [1.189775] 7ba0: 08a123e8 08b726e8 [1.197674] 7bc0: 03ff 7e0007d930c0 8001fff2b458 [1.205573] 7be0: 7f7f7f7f7f7f7f7f 0101010101010101 0008 8001f6c26150 [1.213472] 7c00: 8001f6c2691c deadbeef 105d2c2d [1.221372] [] bind_evtchn_to_irq+0x1c/0x108 [1.227274] [] bind_evtchn_to_irqhandler+0x28/0x90 [1.233698] [] xb_init_comms+0x6c/0xf8 [1.239078] [] xs_init+0xa8/0x1d0 [1.244028] [] xenbus_init+0x258/0x2e4 [1.249408] [] do_one_initcall+0x84/0x114 [1.255050] [] kernel_init_freeable+0x1a4/0x244 [1.261212] [] kernel_init+0x10/0x100 [1.266507] [] ret_from_fork+0x10/0x20 [1.271889] Code: f90013f5 2a0003f5 f9414820 a90153f3 (f940) [1.278065] ---[ end trace 1a0c84ed669d59e3 ]--- [1.282747] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [1.282747] [1.292025] SMP: stopping secondary CPUs [1.296045] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b -- Regards, Wei Chen IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping
/* Direct vCPU id mapping for ARM guests. */
> - per_cpu(xen_vcpu_id, 0) = 0;
> + for_each_possible_cpu(cpu)
> + per_cpu(xen_vcpu_id, cpu) = cpu;
>
> xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
> if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
>
> (not tested, if we can't use for_each_possible_cpu() that early we'll
> have to check against NR_CPUS instead).
>
I have tested this patch just now, it can work with the latest Linux
kernel and latest Xen hypervisor on my ARM platform:
[0.299927] xen:events: Using FIFO-based ABI
[0.304259] Xen: initializing cpu0
[0.336402] EFI services will not be available.
[0.388985] Detected PIPT I-cache on CPU1
[0.389024] Xen: initializing cpu1
[0.389036] CPU1: Booted secondary processor [411fd072]
[0.421064] Detected PIPT I-cache on CPU2
[0.421105] Xen: initializing cpu2
[0.421119] CPU2: Booted secondary processor [411fd072]
[0.453143] Detected PIPT I-cache on CPU3
[0.453178] Xen: initializing cpu3
[0.453190] CPU3: Booted secondary processor [411fd072]
[0.485226] Detected PIPT I-cache on CPU4
[0.485265] Xen: initializing cpu4
[0.485278] CPU4: Booted secondary processor [411fd072]
[0.517303] Detected PIPT I-cache on CPU5
[0.517339] Xen: initializing cpu5
[0.517351] CPU5: Booted secondary processor [411fd072]
[0.549389] Detected PIPT I-cache on CPU6
[0.549428] Xen: initializing cpu6
[0.549442] CPU6: Booted secondary processor [411fd072]
[0.581470] Detected PIPT I-cache on CPU7
[0.581506] Xen: initializing cpu7
[0.581518] CPU7: Booted secondary processor [411fd072]
[0.581570] Brought up 8 CPUs
[0.674360] SMP: Total of 8 processors activated.
[0.679138] CPU features: detected feature: 32-bit EL0 Support
[0.685040] CPU: All CPU(s) started at EL1
Regards,
> But unfortunatelly we'll have to get back to this in future. Turns out
> we need to know Xen's idea of vCPU id _before_ this vCPU starts
> executing code. On x86 we used ACPI_ID from MADT. Is there anything like
> it on ARM?
>
>>
>> [...]
>>
>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>> index 0f87db2..c833912 100644
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)
>>>
>>> xen_setup_features();
>>>
>>> +cpuid(base + 4, , , , );
>>> +if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
>>> +this_cpu_write(xen_vcpu_id, ebx);
>>> +else
>>> +this_cpu_write(xen_vcpu_id, smp_processor_id());
>>> +
>>> pv_info.name = "Xen HVM";
>>>
>>> xen_domain_type = XEN_HVM_DOMAIN;
>>> @@ -1806,6 +1823,10 @@ static int xen_hvm_cpu_notify(struct notifier_block
>>> *self, unsigned long action,
>>> int cpu = (long)hcpu;
>>> switch (action) {
>>> case CPU_UP_PREPARE:
>>> +if (cpu_acpi_id(cpu) != U32_MAX)
>>> +per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
>>> +else
>>> +per_cpu(xen_vcpu_id, cpu) = cpu;
>>
>> I have not tried myself. But looking at the code, the notifiers
>> xen_hvm_cpu_notifier and evtchn_fifo_cpu_notifier have the same
>> priority. So what does prevent the code above to be executed after the
>> event channel callback?
>
> Nothing, actually, but xen_hvm_guest_init() happens early and we always
> get these notifiers in the right order (and, reading Boris' reply, we're
> gonna make it explicit in future).
>
>>
>>> xen_vcpu_setup(cpu);
>>> if (xen_have_vector_callback) {
>>> if (xen_feature(XENFEAT_hvm_safe_pvclock))
>>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>>> index 86abe07..648ce814 100644
>>> --- a/include/xen/xen-ops.h
>>> +++ b/include/xen/xen-ops.h
>>> @@ -9,6 +9,12 @@
>>>
>>> DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>
>>> +DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
>>> +static inline int xen_vcpu_nr(int cpu)
>>> +{
>>> +return per_cpu(xen_vcpu_id, cpu);
>>> +}
>>> +
>>> void xen_arch_pre_suspend(void);
>>> void xen_arch_post_suspend(int suspend_cancelled);
>>
>> Regards,
>
--
Regards,
Wei Chen
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping
per_cpu(xen_vcpu_id, 0) = 0;
> + for_each_possible_cpu(cpu)
> + per_cpu(xen_vcpu_id, cpu) = cpu;
>
> xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
> if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
>
> (not tested, if we can't use for_each_possible_cpu() that early we'll
> have to check against NR_CPUS instead).
>
I have tested this patch just now, it can work with the latest Linux
kernel and latest Xen hypervisor on my ARM platform:
[0.299927] xen:events: Using FIFO-based ABI
[0.304259] Xen: initializing cpu0
[0.336402] EFI services will not be available.
[0.388985] Detected PIPT I-cache on CPU1
[0.389024] Xen: initializing cpu1
[0.389036] CPU1: Booted secondary processor [411fd072]
[0.421064] Detected PIPT I-cache on CPU2
[0.421105] Xen: initializing cpu2
[0.421119] CPU2: Booted secondary processor [411fd072]
[0.453143] Detected PIPT I-cache on CPU3
[0.453178] Xen: initializing cpu3
[0.453190] CPU3: Booted secondary processor [411fd072]
[0.485226] Detected PIPT I-cache on CPU4
[0.485265] Xen: initializing cpu4
[0.485278] CPU4: Booted secondary processor [411fd072]
[0.517303] Detected PIPT I-cache on CPU5
[0.517339] Xen: initializing cpu5
[0.517351] CPU5: Booted secondary processor [411fd072]
[0.549389] Detected PIPT I-cache on CPU6
[0.549428] Xen: initializing cpu6
[0.549442] CPU6: Booted secondary processor [411fd072]
[0.581470] Detected PIPT I-cache on CPU7
[0.581506] Xen: initializing cpu7
[0.581518] CPU7: Booted secondary processor [411fd072]
[0.581570] Brought up 8 CPUs
[0.674360] SMP: Total of 8 processors activated.
[0.679138] CPU features: detected feature: 32-bit EL0 Support
[0.685040] CPU: All CPU(s) started at EL1
Regards,
> But unfortunatelly we'll have to get back to this in future. Turns out
> we need to know Xen's idea of vCPU id _before_ this vCPU starts
> executing code. On x86 we used ACPI_ID from MADT. Is there anything like
> it on ARM?
>
>>
>> [...]
>>
>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>> index 0f87db2..c833912 100644
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)
>>>
>>> xen_setup_features();
>>>
>>> +cpuid(base + 4, , , , );
>>> +if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
>>> +this_cpu_write(xen_vcpu_id, ebx);
>>> +else
>>> +this_cpu_write(xen_vcpu_id, smp_processor_id());
>>> +
>>> pv_info.name = "Xen HVM";
>>>
>>> xen_domain_type = XEN_HVM_DOMAIN;
>>> @@ -1806,6 +1823,10 @@ static int xen_hvm_cpu_notify(struct notifier_block
>>> *self, unsigned long action,
>>> int cpu = (long)hcpu;
>>> switch (action) {
>>> case CPU_UP_PREPARE:
>>> +if (cpu_acpi_id(cpu) != U32_MAX)
>>> +per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
>>> +else
>>> +per_cpu(xen_vcpu_id, cpu) = cpu;
>>
>> I have not tried myself. But looking at the code, the notifiers
>> xen_hvm_cpu_notifier and evtchn_fifo_cpu_notifier have the same
>> priority. So what does prevent the code above to be executed after the
>> event channel callback?
>
> Nothing, actually, but xen_hvm_guest_init() happens early and we always
> get these notifiers in the right order (and, reading Boris' reply, we're
> gonna make it explicit in future).
>
>>
>>> xen_vcpu_setup(cpu);
>>> if (xen_have_vector_callback) {
>>> if (xen_feature(XENFEAT_hvm_safe_pvclock))
>>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>>> index 86abe07..648ce814 100644
>>> --- a/include/xen/xen-ops.h
>>> +++ b/include/xen/xen-ops.h
>>> @@ -9,6 +9,12 @@
>>>
>>> DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>
>>> +DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
>>> +static inline int xen_vcpu_nr(int cpu)
>>> +{
>>> +return per_cpu(xen_vcpu_id, cpu);
>>> +}
>>> +
>>> void xen_arch_pre_suspend(void);
>>> void xen_arch_post_suspend(int suspend_cancelled);
>>
>> Regards,
>
--
Regards,
Wei Chen
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
RE: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS
> -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: 2016年6月14日 16:56 > To: Wei Chen > Cc: Wei Chen; Steve Capper; j...@8bytes.org; linux-kernel@vger.kernel.org; > io...@lists.linux-foundation.org; Robin Murphy; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS > > On Tue, Jun 14, 2016 at 11:11:36AM +0800, Wei Chen wrote: > > On 13 June 2016 at 20:45, Will Deacon <will.dea...@arm.com> wrote: > > > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: > > >> The PCIe ACS capability will affect the layout of iommu groups. > > >> Generally speaking, if the path from root port to the PCIe device > > >> is ACS enabled, the iommu will create a single iommu group for this > > >> PCIe device. If all PCIe devices on the path are ACS enabled then > > >> Linux can determine this path is ACS enabled. > > >> > > >> Linux use two PCIe configuration registers to determine the ACS > > >> status of PCIe devices: > > >> ACS Capability Register and ACS Control Register. > > >> > > >> The first register is used to check the implementation of ACS > > >> function of a PCIe device, the second register is used to check the > > >> enable status of ACS function. If one PCIe device has implemented > > >> and enabled the ACS function then Linux will determine this PCIe > device enabled ACS. > > >> > > >> From the Chapter:6.12 of PCI Express Base Specification Revision > > >> 3.1a, we can find that when a PCIe device implements ACS function, > > >> the enable status is set to disabled by default and can be enabled > > >> by ACS-aware software. > > >> > > >> ACS will affect the iommu groups topology, so, the iommu driver is > > >> ACS-aware software. This patch adds a call to pci_request_acs() to > > >> the arm-smmu driver to enable the ACS function in PCIe devices that > > >> support it. > > >> > > >> Signed-off-by: Wei Chen <wei.c...@arm.com> > > >> --- > > >> drivers/iommu/arm-smmu-v3.c | 2 ++ > > >> drivers/iommu/arm-smmu.c| 4 +++- > > >> 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > Thanks, queued for 4.8 w/ Robin and Eric's reviewed-by tags and the > > > minor commit wording change. > > > > > > > Thanks, I will post a v2 patch to include above changes. > > :/ As above, I've already queued this. Oh, thank you :) > > Will IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
RE: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS
> -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: 2016年6月14日 16:56 > To: Wei Chen > Cc: Wei Chen; Steve Capper; j...@8bytes.org; linux-kernel@vger.kernel.org; > io...@lists.linux-foundation.org; Robin Murphy; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS > > On Tue, Jun 14, 2016 at 11:11:36AM +0800, Wei Chen wrote: > > On 13 June 2016 at 20:45, Will Deacon wrote: > > > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: > > >> The PCIe ACS capability will affect the layout of iommu groups. > > >> Generally speaking, if the path from root port to the PCIe device > > >> is ACS enabled, the iommu will create a single iommu group for this > > >> PCIe device. If all PCIe devices on the path are ACS enabled then > > >> Linux can determine this path is ACS enabled. > > >> > > >> Linux use two PCIe configuration registers to determine the ACS > > >> status of PCIe devices: > > >> ACS Capability Register and ACS Control Register. > > >> > > >> The first register is used to check the implementation of ACS > > >> function of a PCIe device, the second register is used to check the > > >> enable status of ACS function. If one PCIe device has implemented > > >> and enabled the ACS function then Linux will determine this PCIe > device enabled ACS. > > >> > > >> From the Chapter:6.12 of PCI Express Base Specification Revision > > >> 3.1a, we can find that when a PCIe device implements ACS function, > > >> the enable status is set to disabled by default and can be enabled > > >> by ACS-aware software. > > >> > > >> ACS will affect the iommu groups topology, so, the iommu driver is > > >> ACS-aware software. This patch adds a call to pci_request_acs() to > > >> the arm-smmu driver to enable the ACS function in PCIe devices that > > >> support it. > > >> > > >> Signed-off-by: Wei Chen > > >> --- > > >> drivers/iommu/arm-smmu-v3.c | 2 ++ > > >> drivers/iommu/arm-smmu.c| 4 +++- > > >> 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > Thanks, queued for 4.8 w/ Robin and Eric's reviewed-by tags and the > > > minor commit wording change. > > > > > > > Thanks, I will post a v2 patch to include above changes. > > :/ As above, I've already queued this. Oh, thank you :) > > Will IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS
On 13 June 2016 at 20:45, Will Deacon <will.dea...@arm.com> wrote: > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will create a single iommu group for this >> PCIe device. If all PCIe devices on the path are ACS enabled then >> Linux can determine this path is ACS enabled. >> >> Linux use two PCIe configuration registers to determine the ACS >> status of PCIe devices: >> ACS Capability Register and ACS Control Register. >> >> The first register is used to check the implementation of ACS function >> of a PCIe device, the second register is used to check the enable status >> of ACS function. If one PCIe device has implemented and enabled the ACS >> function then Linux will determine this PCIe device enabled ACS. >> >> From the Chapter:6.12 of PCI Express Base Specification Revision 3.1a, >> we can find that when a PCIe device implements ACS function, the enable >> status is set to disabled by default and can be enabled by ACS-aware >> software. >> >> ACS will affect the iommu groups topology, so, the iommu driver is >> ACS-aware software. This patch adds a call to pci_request_acs() to the >> arm-smmu driver to enable the ACS function in PCIe devices that support >> it. >> >> Signed-off-by: Wei Chen <wei.c...@arm.com> >> --- >> drivers/iommu/arm-smmu-v3.c | 2 ++ >> drivers/iommu/arm-smmu.c| 4 +++- >> 2 files changed, 5 insertions(+), 1 deletion(-) > > Thanks, queued for 4.8 w/ Robin and Eric's reviewed-by tags and the minor > commit wording change. > Thanks, I will post a v2 patch to include above changes. > Will > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS
On 13 June 2016 at 20:45, Will Deacon wrote: > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will create a single iommu group for this >> PCIe device. If all PCIe devices on the path are ACS enabled then >> Linux can determine this path is ACS enabled. >> >> Linux use two PCIe configuration registers to determine the ACS >> status of PCIe devices: >> ACS Capability Register and ACS Control Register. >> >> The first register is used to check the implementation of ACS function >> of a PCIe device, the second register is used to check the enable status >> of ACS function. If one PCIe device has implemented and enabled the ACS >> function then Linux will determine this PCIe device enabled ACS. >> >> From the Chapter:6.12 of PCI Express Base Specification Revision 3.1a, >> we can find that when a PCIe device implements ACS function, the enable >> status is set to disabled by default and can be enabled by ACS-aware >> software. >> >> ACS will affect the iommu groups topology, so, the iommu driver is >> ACS-aware software. This patch adds a call to pci_request_acs() to the >> arm-smmu driver to enable the ACS function in PCIe devices that support >> it. >> >> Signed-off-by: Wei Chen >> --- >> drivers/iommu/arm-smmu-v3.c | 2 ++ >> drivers/iommu/arm-smmu.c| 4 +++- >> 2 files changed, 5 insertions(+), 1 deletion(-) > > Thanks, queued for 4.8 w/ Robin and Eric's reviewed-by tags and the minor > commit wording change. > Thanks, I will post a v2 patch to include above changes. > Will > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH] iommu/arm-smmu: request pcie devices to enable ACS
The PCIe ACS capability will affect the layout of iommu groups.
Generally speaking, if the path from root port to the PCIe device
is ACS enabled, the iommu will create a single iommu group for this
PCIe device. If all PCIe devices on the path are ACS enabled then
Linux can determine this path is ACS enabled.
Linux use two PCIe configuration registers to determine the ACS
status of PCIe devices:
ACS Capability Register and ACS Control Register.
The first register is used to check the implementation of ACS function
of a PCIe device, the second register is used to check the enable status
of ACS function. If one PCIe device has implemented and enabled the ACS
function then Linux will determine this PCIe device enabled ACS.
>From the Chapter:6.12 of PCI Express Base Specification Revision 3.1a,
we can find that when a PCIe device implements ACS function, the enable
status is set to disabled by default and can be enabled by ACS-aware
software.
ACS will affect the iommu groups topology, so, the iommu driver is
ACS-aware software. This patch adds a call to pci_request_acs() to the
arm-smmu driver to enable the ACS function in PCIe devices that support
it.
Signed-off-by: Wei Chen <wei.c...@arm.com>
---
drivers/iommu/arm-smmu-v3.c | 2 ++
drivers/iommu/arm-smmu.c| 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 94b6821..30ea899 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2686,6 +2686,8 @@ static int __init arm_smmu_init(void)
if (ret)
return ret;
+ pci_request_acs();
+
return bus_set_iommu(_bus_type, _smmu_ops);
}
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9345a3f..ab365ec 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2096,8 +2096,10 @@ static int __init arm_smmu_init(void)
#endif
#ifdef CONFIG_PCI
- if (!iommu_present(_bus_type))
+ if (!iommu_present(_bus_type)) {
+ pci_request_acs();
bus_set_iommu(_bus_type, _smmu_ops);
+ }
#endif
return 0;
--
2.7.4
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
[PATCH] iommu/arm-smmu: request pcie devices to enable ACS
The PCIe ACS capability will affect the layout of iommu groups.
Generally speaking, if the path from root port to the PCIe device
is ACS enabled, the iommu will create a single iommu group for this
PCIe device. If all PCIe devices on the path are ACS enabled then
Linux can determine this path is ACS enabled.
Linux use two PCIe configuration registers to determine the ACS
status of PCIe devices:
ACS Capability Register and ACS Control Register.
The first register is used to check the implementation of ACS function
of a PCIe device, the second register is used to check the enable status
of ACS function. If one PCIe device has implemented and enabled the ACS
function then Linux will determine this PCIe device enabled ACS.
>From the Chapter:6.12 of PCI Express Base Specification Revision 3.1a,
we can find that when a PCIe device implements ACS function, the enable
status is set to disabled by default and can be enabled by ACS-aware
software.
ACS will affect the iommu groups topology, so, the iommu driver is
ACS-aware software. This patch adds a call to pci_request_acs() to the
arm-smmu driver to enable the ACS function in PCIe devices that support
it.
Signed-off-by: Wei Chen
---
drivers/iommu/arm-smmu-v3.c | 2 ++
drivers/iommu/arm-smmu.c| 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 94b6821..30ea899 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2686,6 +2686,8 @@ static int __init arm_smmu_init(void)
if (ret)
return ret;
+ pci_request_acs();
+
return bus_set_iommu(_bus_type, _smmu_ops);
}
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9345a3f..ab365ec 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2096,8 +2096,10 @@ static int __init arm_smmu_init(void)
#endif
#ifdef CONFIG_PCI
- if (!iommu_present(_bus_type))
+ if (!iommu_present(_bus_type)) {
+ pci_request_acs();
bus_set_iommu(_bus_type, _smmu_ops);
+ }
#endif
return 0;
--
2.7.4
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
