Re: [PATCH kernel 9/9] KVM: PPC: Add in-kernel acceleration for VFIO

On 09/12/16 04:55, Alex Williamson wrote: > On Thu, 8 Dec 2016 19:19:56 +1100 > Alexey Kardashevskiy wrote: > >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT >> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO >> without passing them to

[PATCH v2] cxl: prevent read/write to AFU config space while AFU not configured

During EEH recovery, we deconfigure all AFUs whilst leaving the corresponding vPHB and virtual PCI device in place. If something attempts to interact with the AFU's PCI config space (e.g. running lspci) after the AFU has been deconfigured and before it's reconfigured,

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

On 12/08/2016 01:06 AM, Johannes Thumshirn wrote: > On Wed, Dec 07, 2016 at 05:31:26PM -0600, Tyrel Datwyler wrote: >> The first byte of each CRQ entry is used to indicate whether an entry is >> a valid response or free for the VIOS to use. After processing a >> response the driver sets the valid

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

On 12/08/2016 03:29 PM, Paolo Bonzini wrote: > > > On 08/12/2016 00:31, Tyrel Datwyler wrote: >> The first byte of each CRQ entry is used to indicate whether an entry is >> a valid response or free for the VIOS to use. After processing a >> response the driver sets the valid byte to zero to

Re: [PATCH 3/3] powerpc: enable support for GCC plugins

On 09/12/16 05:06, Kees Cook wrote: i don't think that this is the right approach. there's a general and a special issue here, both of which need different handling. the general problem is to detect problems related to gcc plugin headers and notify the users about solutions. emitting various

Re: [PATCH v2] PCI: designware: add host_init error handling

Hi Srinivas, On 12/07/2016 07:32 PM, Srinivas Kandagatla wrote: > This patch add support to return value from host_init() callback from drivers, > so that the designware libary can handle or pass it to proper place. Issue > with > void return type is that errors or error handling within

[PATCHv2 1/4] pseries: Add hypercall wrappers for hash page table resizing

This adds the hypercall numbers and wrapper functions for the hash page table resizing hypercalls. These are experimental "platform specific" values for now, until we have a formal PAPR update. It also adds a new firmware feature flag to track the presence of the HPT resizing calls.

[PATCHv2 2/4] pseries: Add support for hash table resizing

This adds support for using experimental hypercalls to change the size of the main hash page table while running as a PAPR guest. For now these hypercalls are only in experimental qemu versions. The interface is two part: first H_RESIZE_HPT_PREPARE is used to allocate and prepare the new hash

[PATCHv2 4/4] pseries: Automatically resize HPT for memory hot add/remove

We've now implemented code in the pseries platform to use the new PAPR interface to allow resizing the hash page table (HPT) at runtime. This patch uses that interface to automatically attempt to resize the HPT when memory is hot added or removed. This tries to always keep the HPT at a

[PATCHv2 3/4] pseries: Advertise HPT resizing support via CAS

The hypervisor needs to know a guest is capable of using the HPT resizing PAPR extension in order to make full advantage of it for memory hotplug. If the hypervisor knows the guest is HPT resize aware, it can size the initial HPT based on the initial guest RAM size, relying on the guest to resize

[PATCHv2 0/4] Hash Page Table resizing for PAPR guests

This series implements the guest side of a PAPR ACR which allows a POWER guest's Hashed Page Table (HPT) to be resized at runtime. This is useful when a guest has a very large theoretical maximum RAM, but is likely to only ever be expanded to a modest amount of RAM in practice. Without resizing

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

On 08/12/2016 00:31, Tyrel Datwyler wrote: > The first byte of each CRQ entry is used to indicate whether an entry is > a valid response or free for the VIOS to use. After processing a > response the driver sets the valid byte to zero to indicate the entry is > now free to be reused. Add a

Re: [PATCH 1/2] ibmvscsi: add vscsi hosts to global list_head

> "Tyrel" == Tyrel Datwyler writes: Tyrel> Add each vscsi host adatper to a new global list_head named Tyrel> ibmvscsi_head. There is no functional change. This is meant Tyrel> primarily as a convience for locating adatpers from within the Tyrel> debugger or crash

Re: [PATCH] powerpc: Fix LPCR_VRMASD definition

On Thu, Dec 08, 2016 at 11:29:30AM +0800, Jia He wrote: > Fixes: a4b349540a ("powerpc/mm: Cleanup LPCR defines") > Signed-off-by: Jia He Acked-by: Paul Mackerras

Re: [PATCH] powerpc/mm: Fixup wrong LPCR_VRMASD value

On Thu, Dec 08, 2016 at 09:12:13AM +0530, Aneesh Kumar K.V wrote: > In commit a4b349540a26af ("powerpc/mm: Cleanup LPCR defines") we updated > LPCR_VRMASD wrongly as below. > > -#define LPCR_VRMASD (0x1ful << (63-16)) > +#define LPCR_VRMASD_SH 47 > +#define LPCR_VRMASD

Re: [PATCH] powerpc/mm: Fixup wrong LPCR_VRMASD value

On Thu, Dec 08, 2016 at 09:12:13AM +0530, Aneesh Kumar K.V wrote: > In commit a4b349540a26af ("powerpc/mm: Cleanup LPCR defines") we updated > LPCR_VRMASD wrongly as below. > > -#define LPCR_VRMASD (0x1ful << (63-16)) > +#define LPCR_VRMASD_SH 47 > +#define LPCR_VRMASD

Re: [PATCH 4/6] pseries: Add support for hash table resizing

Hi David, [auto build test ERROR on v4.9-rc8] [cannot apply to powerpc/next kvm/linux-next kvm-ppc/kvm-ppc-next next-20161208] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/David-Gibson

Re: [PATCH v3 04/15] livepatch/x86: add TIF_PATCH_PENDING thread flag

On Thu, Dec 8, 2016 at 10:08 AM, Josh Poimboeuf wrote: > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > per-task consistency model for x86_64. The bit getting set indicates > the thread has a pending patch which needs to be applied when the thread >

[PATCH v3 15/15] livepatch: allow removal of a disabled patch

From: Miroslav Benes Currently we do not allow patch module to unload since there is no method to determine if a task is still running in the patched code. The consistency model gives us the way because when the unpatching finishes we know that all tasks were marked as safe to

[PATCH v3 14/15] livepatch: add /proc//patch_state

Expose the per-task patch state value so users can determine which tasks are holding up completion of a patching operation. Signed-off-by: Josh Poimboeuf --- Documentation/filesystems/proc.txt | 18 ++ fs/proc/base.c | 15 +++

[PATCH v3 13/15] livepatch: change to a per-task consistency model

Change livepatch to use a basic per-task consistency model. This is the foundation which will eventually enable us to patch those ~10% of security patches which change function or data semantics. This is the biggest remaining piece needed to make livepatch more generally useful. This code stems

[PATCH v3 12/15] livepatch: store function sizes

For the consistency model we'll need to know the sizes of the old and new functions to determine if they're on the stacks of any tasks. Signed-off-by: Josh Poimboeuf --- include/linux/livepatch.h | 3 +++ kernel/livepatch/core.c | 16 2 files changed, 19

[PATCH v3 11/15] livepatch: use kstrtobool() in enabled_store()

The sysfs enabled value is a boolean, so kstrtobool() is a better fit for parsing the input string since it does the range checking for us. Suggested-by: Petr Mladek Signed-off-by: Josh Poimboeuf --- kernel/livepatch/core.c | 11 --- 1 file

[PATCH v3 10/15] livepatch: move patching functions into patch.c

Move functions related to the actual patching of functions and objects into a new patch.c file. Signed-off-by: Josh Poimboeuf --- kernel/livepatch/Makefile | 2 +- kernel/livepatch/core.c | 202 +-- kernel/livepatch/patch.c | 213

[PATCH v3 09/15] livepatch: remove unnecessary object loaded check

klp_patch_object()'s callers already ensure that the object is loaded, so its call to klp_is_object_loaded() is unnecessary. This will also make it possible to move the patching code into a separate file. Signed-off-by: Josh Poimboeuf --- kernel/livepatch/core.c | 3 --- 1

[PATCH v3 03/15] livepatch: temporary stubs for klp_patch_pending() and klp_update_patch_state()

Create temporary stubs for klp_patch_pending() and klp_update_patch_state() so we can add TIF_PATCH_PENDING to different architectures in separate patches without breaking build bisectability. Signed-off-by: Josh Poimboeuf --- include/linux/livepatch.h | 7 ++-

[PATCH v3 08/15] livepatch: separate enabled and patched states

Once we have a consistency model, patches and their objects will be enabled and disabled at different times. For example, when a patch is disabled, its loaded objects' funcs can remain registered with ftrace indefinitely until the unpatching operation is complete and they're no longer in use.

[PATCH v3 07/15] livepatch/s390: add TIF_PATCH_PENDING thread flag

From: Miroslav Benes Update a task's patch state when returning from a system call or user space interrupt, or after handling a signal. This greatly increases the chances of a patch operation succeeding. If a task is I/O bound, it can be patched when returning from a system

[PATCH v3 06/15] livepatch/s390: reorganize TIF thread flag bits

From: Jiri Slaby Group the TIF thread flag bits by their inclusion in the _TIF_WORK and _TIF_TRACE macros. Signed-off-by: Jiri Slaby Signed-off-by: Josh Poimboeuf --- arch/s390/include/asm/thread_info.h | 22 ++ 1 file

[PATCH v3 05/15] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

Add the TIF_PATCH_PENDING thread flag to enable the new livepatch per-task consistency model for powerpc. The bit getting set indicates the thread has a pending patch which needs to be applied when the thread exits the kernel. The bit is included in the _TIF_USER_WORK_MASK macro so that

[PATCH v3 04/15] livepatch/x86: add TIF_PATCH_PENDING thread flag

Add the TIF_PATCH_PENDING thread flag to enable the new livepatch per-task consistency model for x86_64. The bit getting set indicates the thread has a pending patch which needs to be applied when the thread exits the kernel. The bit is placed in the _TIF_ALLWORK_MASK macro, which results in

[PATCH v3 02/15] x86/entry: define _TIF_ALLWORK_MASK flags explicitly

The _TIF_ALLWORK_MASK macro automatically includes the least-significant 16 bits of the thread_info flags, which is less than obvious and tends to create confusion and surprises when reading or modifying the code. Define the flags explicitly. Signed-off-by: Josh Poimboeuf

[PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

For live patching and possibly other use cases, a stack trace is only useful if it can be assured that it's completely reliable. Add a new save_stack_trace_tsk_reliable() function to achieve that. Scenarios which indicate that a stack trace may be unreliable: - running task - interrupt stack -

[PATCH v3 00/15] livepatch: hybrid consistency model

Dusting the cobwebs off the consistency model again. This is based on linux-next/master. v1 was posted on 2015-02-09: https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com v2 was posted on 2016-04-28: https://lkml.kernel.org/r/cover.1461875890.git.jpoim...@redhat.com The

Re: [PATCH 3/3] powerpc: enable support for GCC plugins

On Thu, Dec 8, 2016 at 6:42 AM, PaX Team wrote: > On 6 Dec 2016 at 17:28, Andrew Donnellan wrote: > >> Enable support for GCC plugins on powerpc. >> >> Add an additional version check in gcc-plugins-check to advise users to >> upgrade to gcc 5.2+ on powerpc to avoid issues

Re: [PATCH kernel 9/9] KVM: PPC: Add in-kernel acceleration for VFIO

On Thu, 8 Dec 2016 19:19:56 +1100 Alexey Kardashevskiy wrote: > This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT > and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO > without passing them to user space which saves time on switching > to user

Re: [PATCH 3/3] powerpc: enable support for GCC plugins

On 6 Dec 2016 at 17:28, Andrew Donnellan wrote: > Enable support for GCC plugins on powerpc. > > Add an additional version check in gcc-plugins-check to advise users to > upgrade to gcc 5.2+ on powerpc to avoid issues with header files (gcc <= > 4.6) or missing copies of rs6000-cpus.def (4.8 to

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

Reviewed-by: Brian King -- Brian King Power Linux I/O IBM Linux Technology Center

Re: linux-next: build failure in the powerpc allyesconfig build

On Monday, December 5, 2016 4:22:04 PM CET Stephen Rothwell wrote: > Hi all, > > After mergeing everything but Andrew's tree, today's linux-next build > (powerpc allyesconfig) failed like this: > > kallsyms failure: relative symbol value 0xc000 out of range in > relative mode > > I

Re: 4.9.0-rc8 - rcutorture test failure

On Thu, Dec 08, 2016 at 11:54:15AM +0530, Sachin Sant wrote: > RCU Torture test on powerpc fails during its run against latest mainline > (4.9.0-rc8) tree. > > 07:58:25 BUG: rcutorture tests failed ! > 07:58:25 21:31:00 ERROR| child process failed > 07:58:25 21:31:00 INFO | ERROR

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

On Wed, Dec 07, 2016 at 05:31:26PM -0600, Tyrel Datwyler wrote: > The first byte of each CRQ entry is used to indicate whether an entry is > a valid response or free for the VIOS to use. After processing a > response the driver sets the valid byte to zero to indicate the entry is > now free to be

Re: [PATCH 2/2] ibmvscsi: log bad SRP response opcode in hex format

On Wed, Dec 07, 2016 at 04:04:36PM -0600, Tyrel Datwyler wrote: > An unrecogonized or unsupported SRP response has its opcode currently > logged in decimal format. Log it in hex format instead so it can easily > be validated against the SRP specs values which are in hex. > > Signed-off-by: Tyrel

Re: [PATCH 1/2] ibmvscsi: add vscsi hosts to global list_head

On Wed, Dec 07, 2016 at 04:04:35PM -0600, Tyrel Datwyler wrote: > Add each vscsi host adatper to a new global list_head named > ibmvscsi_head. There is no functional change. This is meant primarily > as a convience for locating adatpers from within the debugger or crash > utility. > >

[PATCH kernel 7/9] KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64 permanently

It does not make much sense to have KVM in book3s-64 and not to have IOMMU bits for PCI pass through support as it costs little and allows VFIO to function on book3s KVM. Having IOMMU_API always enabled makes it unnecessary to have a lot of "#ifdef IOMMU_API" in arch/powerpc/kvm/book3s_64_vio*.

[PATCH kernel 6/9] powerpc/powernv/iommu: Add real mode version of iommu_table_ops::exchange()

In real mode, TCE tables are invalidated using special cache-inhibited store instructions which are not available in virtual mode This defines and implements exchange_rm() callback. This does not define set_rm/clear_rm/flush_rm callbacks as there is no user for those - exchange/exchange_rm are

[PATCH kernel 2/9] powerpc/iommu: Cleanup iommu_table disposal

At the moment iommu_table can be disposed by either calling iommu_table_free() directly or it_ops::free(); the only implementation of free() is in IODA2 - pnv_ioda2_table_free() - and it calls iommu_table_free() anyway. As we are going to have reference counting on tables, we need an unified way

[PATCH kernel 9/9] KVM: PPC: Add in-kernel acceleration for VFIO

This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO without passing them to user space which saves time on switching to user space and back. This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM. KVM

[PATCH kernel 8/9] KVM: PPC: Pass kvm* to kvmppc_find_table()

The guest view TCE tables are per KVM anyway (not per VCPU) so pass kvm* there. This will be used in the following patches where we will be attaching VFIO containers to LIOBNs via ioctl() to KVM (rather than to VCPU). Signed-off-by: Alexey Kardashevskiy ---

[PATCH kernel 5/9] KVM: PPC: Use preregistered memory API to access TCE list

VFIO on sPAPR already implements guest memory pre-registration when the entire guest RAM gets pinned. This can be used to translate the physical address of a guest page containing the TCE list from H_PUT_TCE_INDIRECT. This makes use of the pre-registrered memory API to access TCE list pages in

[PATCH kernel 4/9] powerpc/mmu: Add real mode support for IOMMU preregistered memory

This makes mm_iommu_lookup() able to work in realmode by replacing list_for_each_entry_rcu() (which can do debug stuff which can fail in real mode) with list_for_each_entry_lockless(). This adds realmode version of mm_iommu_ua_to_hpa() which adds explicit vmalloc'd-to-linear address conversion.

[PATCH kernel 3/9] powerpc/vfio_spapr_tce: Add reference counting to iommu_table

So far iommu_table obejcts were only used in virtual mode and had a single owner. We are going to change this by implementing in-kernel acceleration of DMA mapping requests. The proposed acceleration will handle requests in real mode and KVM will keep references to tables. This adds a kref to

[PATCH kernel 1/9] KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number

This adds a capability number for in-kernel support for VFIO on SPAPR platform. The capability will tell the user space whether in-kernel handlers of H_PUT_TCE can handle VFIO-targeted requests or not. If not, the user space must not attempt allocating a TCE table in the host kernel via the

[PATCH kernel 0/9] powerpc/kvm/vfio: Enable in-kernel acceleration

This is my current queue of patches to add acceleration of TCE updates in KVM. This is based on the "next" branch of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git I am not doing changelog here as it is 4 months since last respin and I am sure everybody lost the context anyway,