On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
but better squash it.
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Signed-off-by: Oliver O'Halloran
> ---
> arch/powerpc/platforms/powernv/pci.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci.c
> b/arch/powerpc/platforms/powernv/pci.c
>
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
but honestly can be squashed into 31/46 or/and 33/46 or other similar
patches.
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 6 ++
> 1 file changed,
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Use the helper to look up the pnv_ioda_pe for the device we're configuring DMA
> for. In the VF case there's no need set pdn->pe_number since nothing looks at
> it any more.
>
> Signed-off-by: Oliver O'Halloran
R
e_number,
> - pe->pe_number,
> OPAL_REMOVE_PE_FROM_DOMAIN);
> - /* XXX What to do in case of error ? */
May be print a warning, like a few lines below (in the code, not in the
patch). Not important though if gcc d
}
>
> + /*
> + * Walk the bridges up to the root. Along the way mark this PE as
> + * downstream of the bridge PE(s) so that errors upstream errors
Too many "errors" in "errors upstream errors".
Otherwise
Reviewed-b
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Move the SR-IOV into a platform specific structure. I'm sure stashing all the
> SR-IOV state in pci_dn seemed like a good idea at the time, but it results in
> a
> lot of powernv specifics being leaked out of the platform directory.
>
> Moving
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> When we scan an empty slot the PHB gets an Unsupported Request from the
> downstream bridge when there's no device present at that BDFN. Some older
> PHBs (p7-IOC) don't allow further config space accesses while the PE is
> frozen, so clear it
(!pnv_eeh_pre_cfg_check(edev))
> return PCIBIOS_DEVICE_NOT_FOUND;
>
> - ret = pnv_pci_cfg_write(pdn, where, size, val);
> + ret = pnv_pci_cfg_write(phb, bdfn, where, size, val);
>
> if (!(phb->flags & PNV_PHB_FLAG_EEH))
>
On 25/11/2019 15:26, Oliver O'Halloran wrote:
> On Mon, Nov 25, 2019 at 2:27 PM Alexey Kardashevskiy wrote:
>>
>>
>>
>> On 20/11/2019 12:28, Oliver O'Halloran wrote:
>>> Have the PowerNV EEH backend allocate the eeh_dev if needed rather than
>>
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Despite the name this function is generic PowerNV PCI code rather than
> anything
> EEH specific. Convert to take a phb and bdfn rather than a pci_dn.
>
> Signed-off-by: Oliver O'Halloran
> ---
> arch/powerpc/platforms/powernv/pci.c | 32
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Squash another usage in preperation for making the config accessors pci_dn.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> We might want to move this into eeh-powernv.c
> ---
> a
tream port bus into a single PE since
> they're a single failure domain. That seems to have been broken by
> this patch, but whatever.
Not clear at all where/how this got broken, pointers would help,
preferably as a comment in the code.
Apart from that,
Reviewed-by: Alexey Kardashevskiy
Th
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Have the PowerNV EEH backend allocate the eeh_dev if needed rather than using
> the one attached to the pci_dn.
So that pci_dn attached one is leaked then?
> This gets us most of the way towards decoupling
> pci_dn from the PowerNV EEH code.
>
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Use the pnv_eeh_find_edev() helper to look up the eeh_dev for a device
> rather than doing it via the pci_dn.
This is not what the patch does. I struggle to see what is that thing
really.
>
> Signed-off-by: Oliver O'Halloran
> ---
>
static struct eeh_dev *pnv_eeh_probe_pdev(struct
> pci_dev *pdev)
>* Broadcom Shiner 4-ports 1G NICs (14e4:168a)
>* Broadcom Shiner 2-ports 10G NICs (14e4:168e)
>*/
> - if ((pdn->vendor_id == PCI_VENDOR_ID_BROADCOM &&
This very much l
nv.c | 67 ++--
I like this diffstat :)
Reviewed-by: Alexey Kardashevskiy
> 1 file changed, 4 insertions(+), 63 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
> b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index a974822c5097..b7
id, );
> if (rc != OPAL_SUCCESS) {
> @@ -937,15 +931,13 @@ static int pnv_tce_iommu_bus_notifier(struct
> notifier_block *nb,
> struct pci_dev *pdev;
> struct pci_dn *pdn;
> struct pnv_ioda_pe *pe;
> - struct pci_controller *hose;
> struct pnv_phb *phb;
>
> switch (action) {
> case BUS_NOTIFY_ADD_DEVICE:
> pdev = to_pci_dev(dev);
> pdn = pci_get_pdn(pdev);
> - hose = pci_bus_to_host(pdev->bus);
> - phb = hose->private_data;
> + phb = pci_bus_to_pnvhb(pdev->bus);
>
> WARN_ON_ONCE(!phb);
> if (!pdn || pdn->pe_number == IODA_INVALID_PE || !phb)
> diff --git a/arch/powerpc/platforms/powernv/pci.h
> b/arch/powerpc/platforms/powernv/pci.h
> index a343f3c8e65c..be435a810d19 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -247,4 +247,14 @@ extern void pnv_pci_setup_iommu_table(struct iommu_table
> *tbl,
> void *tce_mem, u64 tce_size,
> u64 dma_offset, unsigned int page_shift);
>
> +static inline struct pnv_phb *pci_bus_to_pnvhb(struct pci_bus *bus)
> +{
> + struct pci_controller *hose = bus->sysdata;
> +
> + if (hose)
> + return hose->private_data;
And since I am commenting on this, usually it is the other way around,
like "if (!hose) return NULL" but I do not insist.
Reviewed-by: Alexey Kardashevskiy
> +
> + return NULL;
> +}
> +
> #endif /* __POWERNV_PCI_H */
>
--
Alexey
return NULL;
> +
> + /*
> + * FIXME: Doing a tree-traversal followed by a list traversal
> + * on every config access is dumb. Not much dumber than the pci_dn
> + * tree traversal we did before, but still quite dumb.
Reviewed-by: Alexey Kardashevskiy
Alt
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Neaten things up a bit and remove a pci_dn use.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
but it also could be merged into some bigger patch, it is hardly useful
on its own.
> ---
> arch/po
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Use the pnv_eeh_{read|write}_config() functions that take an edev rather
> than a pci_dn. This allows us to remove most of the explict uses of pci_dn
> in the PowerNV EEH backend and localises them into a few functions which we
> can fix later.
Remove the call to eeh_add_device_early() in the powernv code to squash
> another pci_dn usage.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/eeh-powernv.c | 5 +
> 1 file changed, 1 insertion(+), 4 de
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> The EEH core has a concept of "early probe" and "late probe." When the
> EEH_PROBE_MODE_DEVTREE flag is set (i.e pseries) we call the eeh_ops->probe()
> function in eeh_add_device_early() so the eeh_dev state is initialised based
> on
> the
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> We use the pci_dn to retrieve the domain, bus, device, and function numbers
> for
> an EEH device. We now have that in the eeh_dev so covert the various printk()s
> we have around the place to source that information from the eeh_dev.
>
>
EH
> support.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
09/46, 10/46 and 11/46 can be actually merged into one patch. Oh, well,
may half of 11/46 without s/pdn->phb/edev->controller/.
> ---
> arch/powerpc/include/asm/eeh.h |
nd
> it's just arithmatic.
>
> We need this here because the functions to remove a VF are slightly
> different to those which remove a physical PCI device.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> The current process for configuring the IODA PEs for normal PCI devices is
> abit stupid.
This phrase should go.
> After assigning MMIO resources for the devices on a bus the
> actual PE asignment occurs when pcibios_setup_bridge() is called
r */
> + struct pnv_ioda_pe *pe = pnv_ioda_get_pe(pdev);
> + pe->pdev = pdev;
> +
> + WARN_ON(!(pe->flags & PNV_IODA_PE_VF));
return;
> + } else if (pdev->is_physfn) {
> + pnv_pci_ioda_fixup_iov_resources(pdev);
and ope
loran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 4 +---
> arch/powerpc/platforms/powernv/pci.h | 1 -
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/power
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> These functions are only used from pci-ioda.c. Move them in there and remove
> the prototypes from the header files.
Make them static then, or am I missing the point?
With that fixed,
Reviewed-by: Alexey Kardashevskiy
Also, pci-
t set the callback in the
> pci_controller_ops.
True.
Reviewed-by: Alexey Kardashevskiy
>
> Signed-off-by: Oliver O'Halloran
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Rather than using the pdn->pe_number for a device as an index into the
> IODA PE array we can use the reverse map. This maps the RID (i.e. bdfn)
> to the PE number associated with it. Firmware maintains a copy of the
> rmap which is used by the
y the driver, or the Linux IOV core.
> Given the above, just delete the code. It's broken, it's mis-leading,
> and it's getting in the way of doing useful cleanups.
There is still a prototype for this in arch/powerpc/include/asm/eeh.h,
and pci_dn::mps as well.
With the history of this ex
On 11/11/2019 15:28, Andrew Donnellan wrote:
> On 11/11/19 3:17 pm, Alexey Kardashevskiy wrote:
>> What driver do you expect to work with this in the guest?
>> arch/powerpc/platforms/powernv/ocxl.c is a powernv-tied driver which
>> calls into OPAL so it won't work o
On 25/10/2019 00:28, christophe lombard wrote:
> This patch adds new IOCTL commands for VFIO PCI driver to support
> configuration and management for OpenCAPI devices, which have been passed
> through from host to QEMU VFIO.
So far we managed to keep all IBM POWER specific inside the IOMMU
On 25/10/2019 00:28, christophe lombard wrote:
> This series adds support for the OpenCAPI devices for vfio pci.
You can pass any PCI device via vfio already, what is missing today to
make it fully working?
For example, for nvlink gpus it was coherent memory and ATSD which we
needed to
On 07/11/2019 04:01, Ram Pai wrote:
> On Wed, Nov 06, 2019 at 12:58:50PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 05/11/2019 08:28, Ram Pai wrote:
>>> The hypervisor needs to access the contents of the page holding the TCE
>>> entries while settin
On 07/11/2019 05:06, Michael S. Tsirkin wrote:
> On Wed, Nov 06, 2019 at 12:59:50PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 05/11/2019 08:28, Ram Pai wrote:
>>> This patch series enables IOMMU support for pseries Secure VMs.
>>>
>&g
On 05/11/2019 08:28, Ram Pai wrote:
> This patch series enables IOMMU support for pseries Secure VMs.
>
>
> Tested using QEMU command line option:
>
> "-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4,
> iommu_platform=on,disable-modern=off,disable-legacy=on"
> and
>
> "-device
On 05/11/2019 08:28, Ram Pai wrote:
> The hypervisor needs to access the contents of the page holding the TCE
> entries while setting up the TCE entries in the IOMMU's TCE table. For
> SecureVMs, since this page is encrypted, the hypervisor cannot access
> valid entries. Share the page with the
On 25/10/2019 04:12, Sergey Miroshnichenko wrote:
> Add a check for the UNSET resource flag to skip the released BARs
Where/why does it crash exactly? It is not extremely clear from the code.
Thanks,
>
> CC: Alexey Kardashevskiy
> CC: Oliver O'Halloran
> CC: Sam Bobrof
On 25/10/2019 04:45, Segher Boessenkool wrote:
> On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 23/10/2019 22:21, Segher Boessenkool wrote:
>>> On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
>>>>
On 24/10/2019 12:31, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
>> On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
>>> When booting under OF the zImage expects the initrd address and size to be
>>> passe
On 23/10/2019 22:21, Segher Boessenkool wrote:
> On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
>> When booting under OF the zImage expects the initrd address and size to be
>> passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU)
>> currently doesn't do
> Cc: sta...@vger.kernel.org
> Cc: Alexey Kardashevskiy
> Signed-off-by: Oliver O'Halloran
> ---
> First noticed here:
> https://unix.stackexchange.com/questions/547023/linux-kernel-on-ppc64le-vmlinux-equivalent-in-arch-powerpc-boot
> ---
> arch/powerpc/boot/devtree.c | 21
:
> $ for i in `seq 1 7` ; do chcpu -d $i ; done ;
> $ taskset -c 0 qemu-system-ppc64 -smp 8,threads=8 \
>-M pseries,accel=kvm,kvm-type=HV -m 1G -nographic -vga none \
>-kernel vmlinux -initrd initrd.cpio.xz
>
> Fix by making sure r0 is 0 before storing i
-by: Oliver O'Halloran
Tested-by: Alexey Kardashevskiy
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/include/asm/pci.h| 1 -
> arch/powerpc/kernel/pci-common.c | 25 -
> arch/powerpc/kernel/pci-hotplug.c | 1 -
> arch/powerpc/kernel/pci_o
t;
> Signed-off-by: Shawn Anastasio
Tested-by: Alexey Kardashevskiy
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/kernel/pci-common.c | 25 +
> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c
y justification for either of these is a comment in eeh_rmv_device()
> suggesting that pdn->pe_number *must* be set to IODA_INVALID_PE in order
> for the VF to be scanned. However, this comment appears to have no basis in
> reality so just delete it.
>
> Signed-off-by: Oliver O'Halloran
On 25/09/2019 21:05, Michael Ellerman wrote:
> On Tue, 2019-09-17 at 00:46:04 UTC, Alistair Popple wrote:
>> Commit 388cc6e133132 ("KVM: PPC: Book3S HV: Support POWER6
>> compatibility mode on POWER7") introduced new macros defining the PCR
>> bits. When used from assembly files these
On 28/09/2019 04:33, Shawn Anastasio wrote:
> On 9/9/19 2:59 AM, Alexey Kardashevskiy wrote:
>>
>>
>> On 06/09/2019 05:13, Shawn Anastasio wrote:
>>> Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
>>> pcibios_bus_add_device().
On 27/09/2019 03:15, Frederic Barrat wrote:
>
>
> Le 26/09/2019 à 18:44, Andrew Donnellan a écrit :
>> On 9/9/19 5:45 pm, Frederic Barrat wrote:
>>> Taking a reference on the pci_dev structure was required with initial
>>> commit 184cd4a3b962 ("powerpc/powernv: PCI support for p7IOC under
>>>
On 24/09/2019 16:39, Frederic Barrat wrote:
>
>
> Le 24/09/2019 à 06:24, Alexey Kardashevskiy a écrit :
>> Hi Fred,
>>
>> what is this made against of? It does not apply on the master. Thanks,
>
> It applies on v5.3. And I can see there's a conflict with
Hi Fred,
what is this made against of? It does not apply on the master. Thanks,
On 10/09/2019 01:45, Frederic Barrat wrote:
> This is the linux part of the work to use the PCI hotplug framework to
> control an opencapi card so that it can be reset and re-read after
> flashing a new FPGA image.
S_ALL) ? "all " : "",
> + (pe->flags & PNV_IODA_PE_MASTER) ? "master " : "",
> + (pe->flags & PNV_IODA_PE_SLAVE) ? "slave " : "",
> + (pe->flags & PNV_IODA_P
On 12/09/2019 15:29, Oliver O'Halloran wrote:
> Use the pnv_phb structure as the private data pointer for the debugfs
> files. This lets us delete some code and an open-coded use of
> hose->private_data.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Al
On 06/09/2019 05:13, Shawn Anastasio wrote:
> Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
> pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU
> setup occurs after the device has been registered in sysfs, which is a
> requirement for IOMMU
On 05/09/2019 14:22, Shawn Anastasio wrote:
On pseries QEMU guests, IOMMU setup for hotplugged PCI devices is currently
broken for all but the first device on a given bus. The culprit is an ordering
issue in the pseries hotplug path (via pci_rescan_bus()) which results in IOMMU
group
behavioral change.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 17 ++
arch/powerpc/kernel/iommu.c | 27 +++
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++
3 files changed, 56 insertions(+)
diff --
As now we have xchg_no_kill/tce_kill, these are not used anymore so
remove them.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 10 -
arch/powerpc/kernel/iommu.c | 26 +---
arch/powerpc/platforms/powernv/pci-ioda.c | 50
-by: Alexey Kardashevskiy
---
Changes:
v3:
* new to the series and it fixes compile error from v2
---
arch/powerpc/platforms/pseries/iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index
Invalidating a TCE cache entry for each updated TCE is quite expensive.
This makes use of the new iommu_table_ops::xchg_no_kill()/tce_kill()
callbacks to bring down the time spent in mapping a huge guest DMA window.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c
Invalidating a TCE cache entry for each updated TCE is quite expensive.
This makes use of the new iommu_table_ops::xchg_no_kill()/tce_kill()
callbacks to bring down the time spent in mapping a huge guest DMA window;
roughly 20s to 10s for each guest's 100GB of DMA space.
Signed-off-by: Alexey
ease comment. Thanks.
Alexey Kardashevskiy (5):
powerpc/powernv/ioda: Split out TCE invalidation from TCE updates
KVM: PPC: Book3S: Invalidate multiple TCEs at once
vfio/spapr_tce: Invalidate multiple TCEs at once
powerpc/pseries/iommu: Switch to xchg_no_kill
powerpc/powernv/ioda: Remove obso
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v2:
* fixed a bug with incorrect
addr0&(OF_PCI_ADDR0_SPACE_MMIO32|OF_PCI_ADDR0_SPACE_MMIO64)
- defined OF_PCI_ADDR0_SPACE_MASK instead
* moved the comment out of function body
* cut-n-pasted address space donotions
---
arch/powerpc/kernel/pci_
As now we have xchg_no_kill/tce_kill, these are not used anymore so
remove them.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 10 -
arch/powerpc/kernel/iommu.c | 26 +---
arch/powerpc/platforms/powernv/pci-ioda.c | 50
Invalidating a TCE cache entry for each updated TCE is quite expensive.
This makes use of the new iommu_table_ops::xchg_no_kill()/tce_kill()
callbacks to bring down the time spent in mapping a huge guest DMA window.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c
Invalidating a TCE cache entry for each updated TCE is quite expensive.
This makes use of the new iommu_table_ops::xchg_no_kill()/tce_kill()
callbacks to bring down the time spent in mapping a huge guest DMA window;
roughly 20s to 10s for each guest's 100GB of DMA space.
Signed-off-by: Alexey
tree :)
This is based on sha1
42ac26d253eb Santosh Sivaraj "powerpc: add machine check safe copy_to_user".
Please comment. Thanks.
Alexey Kardashevskiy (4):
powerpc/powernv/ioda: Split out TCE invalidation from TCE updates
KVM: PPC: Invalidate multiple TCEs at once
vfio
behavioral change.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 17 ++
arch/powerpc/kernel/iommu.c | 27 +++
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++
3 files changed, 56 insertions(+)
diff --
uot;)
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kvm/book3s_64_vio.c| 6 --
arch/powerpc/kvm/book3s_64_vio_hv.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index e99a14798ab0..c4b
While at this, this fixes incorrect early returns in KVM's
H_PUT_TCE_INDIRECT handlers which skips unlocking locks:
both kvmppc_h_put_tce_indirect and kvmppc_rm_h_put_tce_indirect used
to return H_PARAMETER instead of jumping to unlock_exit.
Signed-off-by: Alexey Kardashevskiy
---
This cam
another error handling case.
Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
Signed-off-by: Alexey Kardashevskiy
---
The bug is there since 2157e7b82f3b but it would not appear in practice
before 0bd971676e68, hence that "Fixes". Or it still should b
On 23/07/2019 21:46, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
>> Mapping ~5.000.000 TCEs currently takes about 40s; this is the amount
>> required for a 300GB VM with 64k IOMMU page size. Anything bigger than
>> this produces RCU stall warnings.
>
dma_set_mask() which is a sleepable context.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/pseries/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 889dc2e44b89..2b8de822272f 100644
On 19/07/2019 22:25, Christoph Hellwig wrote:
> On Fri, Jul 19, 2019 at 06:23:59PM +1000, Alexey Kardashevskiy wrote:
>> It is getting there and I still do not see why "swiotlb=force" should not
>> work if chosed in the cmdline.
>
> Ok, makes sense. But th
is supported and use it if it is.
This removes few checks as QEMU might decide not to keen RTAS around at
all (might be the case for secure VMs).
Note that kexec still checks for the linux,rtas-xxx properties which has
to be fixed.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/rtas.h
quot;.
Please comment. Thanks.
Alexey Kardashevskiy (2):
powerpc/pseries: Call RTAS directly
powerpc/pseries: Kexec style ibm,client-architecture-support support
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/kernel/prom_init.c | 12 ++---
arch/powerpc/kernel/rtas.c | 47 +
t interface services.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/prom_init.c | 12 ++
arch/powerpc/kernel/setup_64.c | 41 +
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kern
On 19/07/2019 18:05, Christoph Hellwig wrote:
On Fri, Jul 19, 2019 at 06:00:25PM +1000, Alexey Kardashevskiy wrote:
But shouldn't we force usage of the direct ops in that case as the
IOMMU is not neededed at all?
We do, for mappings, but not unmappings and syncing.
Well, I mean
On 19/07/2019 17:53, Christoph Hellwig wrote:
On Fri, Jul 19, 2019 at 05:52:37PM +1000, Alexey Kardashevskiy wrote:
On 19/07/2019 17:10, Christoph Hellwig wrote:
Hey Alexey,
what is the use case for the above commit? Shouldn't we handle all
addressing limits using the iommu?
Our
On 19/07/2019 17:10, Christoph Hellwig wrote:
Hey Alexey,
what is the use case for the above commit? Shouldn't we handle all
addressing limits using the iommu?
Our secure VMs is the use case, when only a fraction of system memory is
available for DMA.
--
Alexey
On 19/07/2019 07:28, Thiago Jung Bauermann wrote:
Hello Segher,
Thanks for your review and suggestions!
Segher Boessenkool writes:
(Sorry to hijack your reply).
On Thu, Jul 18, 2019 at 06:11:48PM +1000, Alexey Kardashevskiy wrote:
On 13/07/2019 16:00, Thiago Jung Bauermann wrote
On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
From: Ram Pai
These functions are used when the guest wants to grant the hypervisor
access to certain pages.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/ultravisor-api.h | 2 ++
On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
From: Ram Pai
Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure
mode. Add "svm=" command line option to turn on switching to secure mode.
Signed-off-by: Ram Pai
[ andmike: Generate an RTAS os-term hcall when the
At the moment we create a small window only for 32bit devices, the window
maps 0..2GB of the PCI space only. For other devices we either use
a sketchy bypass or hardware bypass but the former can only work if
the amount of RAM is no bigger than the device's DMA mask and the latter
requires devices
ret_from_kernel_thread+0x5c/0x70
}
===
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Alistair Popple
---
Changes:
v4:
* added lockdep output to the commit log to justify ATOMIC in alloc_pages_node
v2:
* added __GFP_NOWARN to alloc_pages_node
---
arch/powerpc/platforms/powernv/pc
-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
This minor thing helped me debugging next 2 patches so it can help
somebody else too.
---
arch/powerpc/kernel/dma-iommu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc
.
This is based on sha1
a2b6f26c264e Christophe Leroy "powerpc/module64: Use symbolic instructions
names.".
Please comment. Thanks.
Alexey Kardashevskiy (4):
powerpc/powernv/ioda: Fix race in TCE level allocation
powerpc/iommu: Allow bypass-only for DMA
powerpc/powernv/ioda2: Allocate
from the same page of TCEs.
This adds cmpxchg to handle the race. Note that once TCE is non-zero,
it cannot become zero again.
CC: sta...@vger.kernel.org # v4.19+
Fixes: a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels on
demand")
Signed-off-by: Alexey Kardashevskiy
---
the current priority
to 0xff which effectively unmasks interrupts in a current CPU.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/sysdev/xive/common.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index
necessary infrastructure to allow platform to deal with it.
The next patch implements it for XIVE.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/irq.c | 9 ++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git
Now 2 patches.
v3 is here: https://patchwork.ozlabs.org/patch/1133106/
This is based on sha1
a2b6f26c264e Christophe Leroy "powerpc/module64: Use symbolic instructions
names.".
Please comment. Thanks.
Alexey Kardashevskiy (2):
powerpc: Add handler for orphaned interrupts
po
want to fix this one for everyone?
Either way, the patch is correct. I'm glad to know it was not my "
powerpc/ioda2: Yet another attempt to allow DMA masks between 32 and 59"
which broke it :)
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/Kconfig | 1 +
arch/po
On 17/07/2019 15:00, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues
-by: Alexey Kardashevskiy
Reviewed-by: Cédric Le Goater
---
Changes:
v3:
* added a comment above xive_orphan_irq()
v2:
* added ppc_md.orphan_irq
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/irq.c | 9 ++---
arch/powerpc/sysdev/xive/common.c | 18
On 16/07/2019 18:59, Cédric Le Goater wrote:
On 15/07/2019 09:11, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown
On 13/07/2019 01:28, Christoph Hellwig wrote:
On Fri, Jul 12, 2019 at 07:45:05PM +1000, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40
On 13/07/2019 01:20, Christoph Hellwig wrote:
This skips the 32bit DMA setup check if the bypass is can be selected.
That sentence does not parse. I think you need to dop the "can be"
based on the actual patch.
"the 32bit DMA setup check" is
"if (!(tbl = get_iommu_table_base(dev)))".
I
-by: Alexey Kardashevskiy
---
Changes:
v2:
* added ppc_md.orphan_irq
---
Found it on P9 system with:
- a host with 8 cpus online
- a boot disk on ahci with its msix on cpu#0
- a guest with 2xGPUs + 6xNVLink + 4 cpus
- GPU#0 from the guest is bound to the same cpu#0.
Killing a guest killed ahci
501 - 600 of 2596 matches
Mail list logo
