Nicholas Piggin writes:
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
> b/arch/powerpc/include/asm/ppc-opcode.h
> index 2a39c716c343..b2bdc4de1292 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -257,6 +257,7 @@
> #define PPC_INST_MF
Hari Bathini writes:
> On 22/07/20 9:55 am, Michael Ellerman wrote:
>> Hari Bathini writes:
>>> Right now purgatory implementation is only minimal. But if purgatory
>>> code is to be enhanced to copy memory to the backup region and verify
>>> sha256 digest, relocations may have to be applied to t
Pingfan Liu writes:
> On Wed, Jul 22, 2020 at 12:57 PM Michael Ellerman wrote:
>>
>> Pingfan Liu writes:
>> > A bug is observed on pseries by taking the following steps on rhel:
>> ^
>>
On Tue, Jun 23, 2020 at 09:14:16PM +0800, Tianjia Zhang wrote:
> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. For historical reasons, many kvm-related function parameters
> retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This
> patch does a
On Tue, Jun 02, 2020 at 03:53:25PM +1000, Alistair Popple wrote:
> Adds support for emulating ISAv3.1 guests by adding the appropriate PCR
> and FSCR bits.
>
> Signed-off-by: Alistair Popple
Thanks, patch applied to my kvm-ppc-next branch.
Paul.
On Tue, Jun 09, 2020 at 12:12:29PM +1000, Alexey Kardashevskiy wrote:
> The kvm_vcpu_read_guest/kvm_vcpu_write_guest used for nested guests
> eventually call srcu_dereference_check to dereference a memslot and
> lockdep produces a warning as neither kvm->slots_lock nor
> kvm->srcu lock is held and
On Mon, Jun 08, 2020 at 01:57:14PM +0200, Cédric Le Goater wrote:
> POWER8 and POWER9 have 12-bit LPIDs. Change LPID_RSVD to support up to
> (4096 - 2) guests on these processors. POWER7 is kept the same with a
> limitation of (1024 - 2), but it might be time to drop KVM support for
> POWER7.
>
>
On Fri, Jul 17, 2020 at 01:00:26AM -0700, Ram Pai wrote:
> @@ -812,7 +842,7 @@ unsigned long kvmppc_h_svm_page_in(struct kvm *kvm,
> unsigned long gpa,
> struct vm_area_struct *vma;
> int srcu_idx;
> unsigned long gfn = gpa >> page_shift;
> - int ret;
> + int ret, repeat_
On Fri, Jul 17, 2020 at 01:00:25AM -0700, Ram Pai wrote:
>
> +int kvmppc_uv_migrate_mem_slot(struct kvm *kvm,
> + const struct kvm_memory_slot *memslot)
Don't see any callers for this outside of this file, so why not static?
> +{
> + unsigned long gfn = memslot->base_gfn;
> +
On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote:
> Hi Nic,
>
> Le 02/07/2020 à 20:42, Nicolin Chen a écrit :
> > Hi Arnaud,
> >
> > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote:
> >> The current ASRC driver hardcodes the input and output clocks used for
> >> sam
On 7/21/20 11:32 AM, kajoljain wrote:
>
>
> On 7/17/20 8:08 PM, Athira Rajeev wrote:
>> From: Anju T Sudhakar
>>
>> Add support for perf extended register capability in powerpc.
>> The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the
>> PMU which support extended registers.
> -Original Message-
> From: Vladimir Oltean
> Sent: Wednesday, July 22, 2020 8:24 PM
> To: robh...@kernel.org; shawn...@kernel.org; m...@ellerman.id.au;
> devicet...@vger.kernel.org
> Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kern
Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit :
On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote:
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > I guess I don't understand why this is necessary at all.
> > Specifically: why
> > can't we just relocate the kern
Hi Palmer,
Le 7/21/20 à 3:05 PM, Palmer Dabbelt a écrit :
On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.
Sorry for being slow here. I haven't replied because I h
Hi Benjamin,
Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit :
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
I guess I don't understand why this is necessary at all.
Specifically: why
can't we just relocate the kernel within the linear map? That would
let the
bootloader put the ker
On Fri, Jul 17, 2020 at 01:00:24AM -0700, Ram Pai wrote:
> During the life of SVM, its GFNs transition through normal, secure and
> shared states. Since the kernel does not track GFNs that are shared, it
> is not possible to disambiguate a shared GFN from a GFN whose PFN has
> not yet been migrated
On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
> When a secure memslot is dropped, all the pages backed in the secure device
> (aka really backed by secure memory by the Ultravisor) should be paged out
> to a normal page. Previously, this was achieved by triggering the page
> fault
On Wed, Jul 22, 2020 at 12:57 PM Michael Ellerman wrote:
>
> Pingfan Liu writes:
> > A bug is observed on pseries by taking the following steps on rhel:
> ^
> RHEL
>
> I
On Thu, Jul 16, 2020 at 06:49:09PM +0200, Christophe Leroy wrote:
> Jarkko Sakkinen a écrit :
>
> > Rename module_alloc() to text_alloc() and module_memfree() to
> > text_memfree(), and move them to kernel/text.c, which is unconditionally
> > compiled to the kernel proper. This allows kprobes, ft
On Thu, Jul 23, 2020 at 11:26 AM Jordan Niethe wrote:
>
> On Sat, Jul 18, 2020 at 1:26 AM Athira Rajeev
> wrote:
> >
> > PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB).
> >
> > BHRB disable is controlled via Monitor Mode Control Register A (MMCRA)
> > bit, namely "BHRB
On Sat, Jul 18, 2020 at 1:26 AM Athira Rajeev
wrote:
>
> PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB).
>
> BHRB disable is controlled via Monitor Mode Control Register A (MMCRA)
> bit, namely "BHRB Recording Disable (BHRBRD)". This field controls
> whether BHRB entries
On Tue, 2020-07-21 at 19:52 -0500, Brian King wrote:
> >
> > As of today, there seems to be nothing like that happening in the
> > driver I am testing.
> > I spoke to Brian King on slack, and he mentioned that at the point DDW
> > is created there should be no allocations in place.
>
> I think t
On Wed, 2020-07-22 at 11:28 +1000, Alexey Kardashevskiy wrote:
>
> On 22/07/2020 08:13, Leonardo Bras wrote:
> > On Tue, 2020-07-21 at 14:59 +1000, Alexey Kardashevskiy wrote:
> > > On 16/07/2020 17:16, Leonardo Bras wrote:
> > > > Move the part of iommu_table_free() that does struct iommu_table
Hi Scott,
I'm hitting this issue and Rick just pointed my at your patch. Any
chance we could get it upstream?
Thanks,
Anton
> On PowerPC, memory_add_physaddr_to_nid() uses a linear search to find
> an LMB matching the given address. This scales very poorly when there
> are many LMBs. The poor
On 22/07/20 4:19 pm, Chris Packham wrote:
> Hi,
>
> I've just fired up linux kernel v5.7 on a p2040 based system and I'm
> getting the following new warning
>
> OF: Can't handle multiple dma-ranges with different offsets on
> node(/pcie@ffe202000)
> OF: Can't handle multiple dma-ranges with diff
Define the network interface names for the switch ports and hook them up
to the 2 QSGMII PHYs that are onboard.
A conscious decision was taken to go along with the numbers that are
written on the front panel of the board and not with the hardware
numbers of the switch chip ports. The 2 are shifted
In preparation of referencing the MDIO nodes from board DTS files (so
that we can add PHY nodes easier), add labels to mdio0 and mdio1.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powe
We're going to add 8 more PHYs in a future patch. It is easier to follow
the hardware description if we don't need to fish for the path of the
MDIO controllers inside the SoC and just use the labels.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040rdb.dts | 12 ++--
1 f
Seville is a DSA switch that is embedded inside the T1040 SoC, and
supported by the mscc_seville DSA driver. The driver has been accepted
this release cycle and is currently available in net-next (and
therefore, in linux-next).
This series adds this switch to the SoC's dtsi files and to the T1040R
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 75 +
1 file changed, 75 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
b/arch/powe
On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann wrote:
>
> On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote:
> > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
> > > The eventual goal is to have a split of 3840MB for e
On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote:
> On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
> > The eventual goal is to have a split of 3840MB for either user or linear map
> > plus and 256MB for vmalloc, includi
On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
> Let's try to make progress here: I add linux-mm in CC to get feedback on
> this patch as it blocks sv48 support
On 22/07/20 9:55 am, Michael Ellerman wrote:
> Hari Bathini writes:
>> Right now purgatory implementation is only minimal. But if purgatory
>> code is to be enhanced to copy memory to the backup region and verify
>> sha256 digest, relocations may have to be applied to the purgatory.
>> So, add
Hello Daniel,
On 21/07/20 8:27 pm, Daniel Lezcano wrote:
On 21/07/2020 14:42, Pratik Rajesh Sampat wrote:
v2: https://lkml.org/lkml/2020/7/17/369
Changelog v2-->v3
Based on comments from Gautham R. Shenoy adding the following in the
selftest,
1. Grepping modules to determine if already loaded
2
On Tue, 14 Jul 2020 09:22:26 +0200, Linus Walleij wrote:
> This converts the PPC4xx SPI driver to use GPIO descriptors.
>
> The driver is already just picking some GPIOs from the device
> tree so the conversion is pretty straight forward. However
> this driver is looking form a pure "gpios" proper
Ram Pai writes:
> On Wed, Jul 22, 2020 at 12:06:06PM +1000, Michael Ellerman wrote:
>> Ram Pai writes:
>> > An instruction accessing a mmio address, generates a HDSI fault. This
>> > fault is
>> > appropriately handled by the Hypervisor. However in the case of
>> > secureVMs, the
>> > fault i
> On 22-Jul-2020, at 4:19 PM, Jordan Niethe wrote:
>
> On Wed, Jul 22, 2020 at 5:55 PM Athira Rajeev
> mailto:atraj...@linux.vnet.ibm.com>> wrote:
>>
>>
>>
>> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote:
>>
>> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev
>> wrote:
>>
>>
>> From: M
On 7/21/20 3:38 PM, Nicholas Piggin wrote:
Excerpts from Ganesh Goudar's message of July 20, 2020 6:03 pm:
When an UE or memory error exception is encountered the MCE handler
tries to find the pfn using addr_to_pfn() which takes effective
address as an argument, later pfn is used to poison the
> On 22-Jul-2020, at 9:48 AM, Jordan Niethe wrote:
>
> On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev
> mailto:atraj...@linux.vnet.ibm.com>> wrote:
>>
>> From: Madhavan Srinivasan
>>
>> PowerISA v3.1 includes new performance monitoring unit(PMU)
>> special purpose registers (SPRs). They are
>
> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote:
>
> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev
> mailto:atraj...@linux.vnet.ibm.com>> wrote:
>>
>> From: Madhavan Srinivasan
>>
>> Add power10 feature function to dt_cpu_ftrs.c along
>> with a power10 specific init() to initialize pmu sp
Jordan Niethe writes:
> On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev
> wrote:
>> From: Madhavan Srinivasan
>>
>> PowerISA v3.1 includes new performance monitoring unit(PMU)
>> special purpose registers (SPRs). They are
...
>>
>> diff --git a/arch/powerpc/include/asm/perf_event_server.h
>> b/a
On Wed, Jul 22, 2020 at 6:07 PM Athira Rajeev
wrote:
>
>
>
> On 22-Jul-2020, at 9:48 AM, Jordan Niethe wrote:
>
> On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev
> wrote:
>
>
> From: Madhavan Srinivasan
>
> PowerISA v3.1 includes new performance monitoring unit(PMU)
> special purpose registers (S
On Wed, Jul 22, 2020 at 5:55 PM Athira Rajeev
wrote:
>
>
>
> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote:
>
> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev
> wrote:
>
>
> From: Madhavan Srinivasan
>
> Add power10 feature function to dt_cpu_ftrs.c along
> with a power10 specific init() to i
On 22/07/2020 17:34, Nicholas Piggin wrote:
> Alexey reports lockdep_assert_irqs_enabled() warnings when stress testing
> perf, e.g.,
>
> WARNING: CPU: 0 PID: 1556 at kernel/softirq.c:169
> __local_bh_enable_ip+0x258/0x270
> CPU: 0 PID: 1556 Comm: syz-executor
> NIP: c01ec888 LR: c00
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
For the record:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Athira Rajeev writes:
>> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote:
>>
>> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev
>> mailto:atraj...@linux.vnet.ibm.com>> wrote:
>>>
>>> From: Madhavan Srinivasan
>>>
>>> Add power10 feature function to dt_cpu_ftrs.c along
>>> with a power10 specif
On 22/07/2020 15:39, Oliver O'Halloran wrote:
> On Wed, Jul 15, 2020 at 6:00 PM Alexey Kardashevskiy wrote:
>>
>*
> - * Generally, one M64 BAR maps one IOV BAR. To avoid
> conflict
> - * with other devices, IOV BAR size is expanded to b
On Fri, Jul 17, 2020 at 01:00:27AM -0700, Ram Pai wrote:
> From: Laurent Dufour
>
> When a memory slot is hot plugged to a SVM, PFNs associated with the
> GFNs in that slot must be migrated to secure-PFNs, aka device-PFNs.
>
> Call kvmppc_uv_migrate_mem_slot() to accomplish this.
> Disable page-
On 22/07/2020 15:01, Oliver O'Halloran wrote:
> On Tue, Jul 14, 2020 at 7:16 PM Alexey Kardashevskiy wrote:
>>
>> On 10/07/2020 15:23, Oliver O'Halloran wrote:
>>> + align = pci_iov_resource_size(pdev, resno);
>>> +
>>> + /*
>>> + * iov can be null if we have an SR-IOV device with
On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
>
> On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
> > Let's try to make progress here: I add linux-mm in CC to get feedback on
> > this patch as it blocks sv48 support too.
>
> Sorry for being slow here. I haven't replied beca
On Wed, Jul 22, 2020 at 10:48:54AM +0200, Peter Zijlstra wrote:
> But reading your explanation, it looks like the Linux topology setup
> could actually unravel the fused-faux-SMT8 into two independent SMT4
> parts, negating that firmware option.
Ah, it looks like that's exactly what you're doing.
On Fri, Jul 17, 2020 at 01:00:23AM -0700, Ram Pai wrote:
> Page-merging of pages in memory-slots associated with a Secure VM,
> is disabled in H_SVM_PAGE_IN handler.
>
> This operation should have been done much earlier; the moment the VM
> is initiated for secure-transition. Delaying this operati
On Wed, Jul 22, 2020 at 01:48:22PM +0530, Srikar Dronamraju wrote:
> * pet...@infradead.org [2020-07-22 09:46:24]:
>
> > On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote:
> > > Currently "CACHE" domain happens to be the 2nd sched domain as per
> > > powerpc_topology. This domain
On Wed, Jul 22, 2020 at 11:35:06AM +0530, Bharata B Rao wrote:
> On Tue, Jul 21, 2020 at 10:25:58PM +1000, Michael Ellerman wrote:
> > Bharata B Rao writes:
> > > On Tue, Jul 21, 2020 at 11:45:20AM +1000, Michael Ellerman wrote:
> > >> Nathan Lynch writes:
> > >> > "Aneesh Kumar K.V" writes:
> >
* pet...@infradead.org [2020-07-22 09:46:24]:
> On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote:
> > Currently "CACHE" domain happens to be the 2nd sched domain as per
> > powerpc_topology. This domain will collapse if cpumask of l2-cache is
> > same as SMT domain. However we co
* Michael Ellerman [2020-07-22 17:41:41]:
> Srikar Dronamraju writes:
> > While cpu_to_node is inline function with access to per_cpu variable.
> > However when using repeatedly, it may be cleaner to cache it in a local
> > variable.
>
> It's not clear what "cleaner" is supposed to mean. Are yo
On Wed, Jul 22, 2020 at 12:06:06PM +1000, Michael Ellerman wrote:
> Ram Pai writes:
> > An instruction accessing a mmio address, generates a HDSI fault. This
> > fault is
> > appropriately handled by the Hypervisor. However in the case of secureVMs,
> > the
> > fault is delivered to the ultrav
On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote:
> Currently "CACHE" domain happens to be the 2nd sched domain as per
> powerpc_topology. This domain will collapse if cpumask of l2-cache is
> same as SMT domain. However we could generalize this domain such that it
> could mean eit
On Wed, Jul 22, 2020 at 12:42:05AM -0700, Ram Pai wrote:
> On Wed, Jul 22, 2020 at 03:02:32PM +1000, Paul Mackerras wrote:
> > On Thu, Jul 16, 2020 at 01:32:13AM -0700, Ram Pai wrote:
> > > An instruction accessing a mmio address, generates a HDSI fault. This
> > > fault is
> > > appropriately ha
On Wed, Jul 22, 2020 at 03:02:32PM +1000, Paul Mackerras wrote:
> On Thu, Jul 16, 2020 at 01:32:13AM -0700, Ram Pai wrote:
> > An instruction accessing a mmio address, generates a HDSI fault. This
> > fault is
> > appropriately handled by the Hypervisor. However in the case of secureVMs,
> > th
Srikar Dronamraju writes:
> While cpu_to_node is inline function with access to per_cpu variable.
> However when using repeatedly, it may be cleaner to cache it in a local
> variable.
It's not clear what "cleaner" is supposed to mean. Are you saying it
makes the source clearer, or the generated c
* Gautham R Shenoy [2020-07-22 12:26:40]:
> Hello Srikar,
>
> On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote:
> > Currently "CACHE" domain happens to be the 2nd sched domain as per
> > powerpc_topology. This domain will collapse if cpumask of l2-cache is
> > same as SMT domain
Alexey reports lockdep_assert_irqs_enabled() warnings when stress testing perf,
e.g.,
WARNING: CPU: 0 PID: 1556 at kernel/softirq.c:169
__local_bh_enable_ip+0x258/0x270
CPU: 0 PID: 1556 Comm: syz-executor
NIP: c01ec888 LR: c01ec884 CTR: c0ef0610
REGS: c00022d4f8a0 TR
> > @@ -1386,6 +1421,9 @@ int setup_profiling_timer(unsigned int multiplier)
> >
> > static void fixup_topology(void)
> > {
> > + if (!has_coregroup_support())
> > + powerpc_topology[mc_idx].mask = cpu_bigcore_mask;
> > +
>
> Shouldn't we move this condition after doing the fixup fo
Le 21/07/2020 à 23:37, Ram Pai a écrit :
On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
When a secure memslot is dropped, all the pages backed in the secure device
(aka really backed by secure memory by the Ultravisor) should be paged out
to a normal page. Previously, this was a
On Tue, Jul 21, 2020 at 05:08:14PM +0530, Srikar Dronamraju wrote:
> Lookup the coregroup id from the associativity array.
>
> If unable to detect the coregroup id, fallback on the core id.
> This way, ensure sched_domain degenerates and an extra sched domain is
> not created.
>
> Ideally this fu
Hi Srikar,
On Tue, Jul 21, 2020 at 05:08:13PM +0530, Srikar Dronamraju wrote:
> Add percpu coregroup maps and masks to create coregroup domain.
> If a coregroup doesn't exist, the coregroup domain will be degenerated
> in favour of SMT/CACHE domain.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael
* Gautham R Shenoy [2020-07-22 11:29:25]:
> Hello Srikar,
>
> On Tue, Jul 21, 2020 at 05:08:08PM +0530, Srikar Dronamraju wrote:
> > Enable small core scheduling as soon as we detect that we are in a
> > system that supports thread group. Doing so would avoid a redundant
> > check.
>
> The patc
* Gautham R Shenoy [2020-07-22 11:51:14]:
> Hi Srikar,
>
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 72f16dc0cb26..57468877499a 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1196,6 +1196,7 @@ static bool update_mask_by
Previously iov->vfs_expanded was used for two purposes.
1) To work out how much we need to multiple the per-VF BAR size to figure
out the total space required for the IOV BAR.
2) To indicate that IOV is not usable with this device (vfs_expanded == 0).
We don't really need the field for either
Using single PE BARs to map an SR-IOV BAR is really a choice about what
strategy to use when mapping a BAR. It doesn't make much sense for this to
be a global setting since a device might have one large BAR which needs to
be mapped with single PE windows and another smaller BAR that can be mapped
w
Split up the logic so that we have one branch that handles setting up a
segmented window and another that handles setting up single PE windows for
each VF.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no changes
---
arch/powerpc/platforms/powernv/pci-sriov.c | 57 +
I want to refactor the loop this code is currently inside of. Hoist it on
out.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no change
---
arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++
1 file changed, 20 insertions(+), 11 deletions(-)
diff
Remove the IODA2 PHB checks. We already assume IODA2 in several places so
there's not much point in wrapping most of the setup and teardown process
in an if block.
Signed-off-by: Oliver O'Halloran
---
v2: Added a note that iov->vf_pe_arr is a pointer into the PHB's PE array
rather than someth
Currently the iov->pe_num_map[] does one of two things depending on
whether single PE mode is being used or not. When it is, this contains an
array which maps a vf_index to the corresponding PE number. When single PE
mode is not being used this contains a scalar which is the base PE for the
set of
Rework the PE allocation logic to allow allocating blocks of PEs rather
than individually. We'll use this to allocate contigious blocks of PEs for
the SR-IOVs.
This patch also adds code to pnv_ioda_alloc_pe() and pnv_ioda_reserve_pe() to
use the existing, but unused, phb->pe_alloc_mutex. Currently
The sequence required to use the single PE BAR mode is kinda janky and
requires a little explanation. The API was designed with P7-IOC style
windows where the setup process is something like:
1. Configure the window start / end address
2. Enable the window
3. Map the segments of each window to the
No need for the multi-dimensional arrays, just use a bitmap.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: Fixed license to GPL-2.0-or-later
Added MAX_M64_BARS for the size of the M64 allocation bitmap rather than
open coding 64.
---
arch/powerpc/platforms/
This prevents SR-IOV being used by making the SR-IOV BAR resources
unallocatable. Rename it to reflect what it actually does.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no changes
---
arch/powerpc/platforms/powernv/pci-sriov.c | 11 ++-
1 file changed, 6
SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea
how anyone is supposed to know how it works except through a lot of
stuffering. Write up some docs about the overall story to help out
the next sucker^Wperson who needs to tinker with it.
Signed-off-by: Oliver O'Halloran
Revie
pci-ioda.c is getting a bit unwieldly due to the amount of stuff jammed in
there. The SR-IOV support can be extracted easily enough and is mostly
standalone, so move it into a separate file.
This patch also moves the PowerNV SR-IOV specific fields from pci_dn and
moves them into a platform specifi
We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping,
similar to PHB3. Currently the actual mapping of segments occurs in
pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and
drop the IODA1 specific code paths in the PE setup / teardown.
Signed-off-by: Oliver O
There's an optimisation in the PE setup which skips performing DMA
setup for a PE if we only have bridges in a PE. The assumption being
that only "real" devices will DMA to system memory, which is probably
fair. However, if we start off with only bridge devices in a PE then
add a non-bridge device
Currently we have these two functions:
pnv_pci_ioda2_release_dma_pe(), and
pnv_pci_ioda2_release_pe_dma()
The first is used when tearing down VF PEs and the other is used for normal
devices. There's very little difference between the two though. The latter
(non-VF) will skip a cal
Add a helper to go from a pci_bus structure to the pnv_phb that hosts that
bus. There's a lot of instances of the following pattern:
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
struct pnv_phb *phb = hose->private_data;
Without any other uses of the pci_controller ins
86 matches
Mail list logo
