On Mon, Mar 7, 2016 at 6:56 PM, Gavin Shan wrote:
> On Tue, Mar 01, 2016 at 08:40:12PM -0600, Rob Herring wrote:
>>On Thu, Feb 18, 2016 at 9:16 PM, Gavin Shan wrote:
>>> On Wed, Feb 17, 2016 at 08:59:53AM -0600, Rob Herring wrote:
On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan
wrote:
>
On Thu, 17 Mar 2016 19:28:34 +0800
Yongji Xie wrote:
> On 2016/3/17 0:30, Alex Williamson wrote:
> > On Mon, 7 Mar 2016 15:48:35 +0800
> > Yongji Xie wrote:
> >
> >> When vfio passthrough a PCI device of which MMIO BARs
> >> are smaller than PAGE_SIZE, guest will not handle the
> >> mmio acce
If ppc_rtas() is called with args.nargs == 16 and args.nret == 0, args.rets
is set to point to &args.args[16], which is beyond the end of the args.args
array. This results in a minor read overrun of the array when we check the
first return code (which, per PAPR, is a required output of all RTAS cal
On Fri, Mar 18, 2016 at 01:50:42PM +1100, Alexey Kardashevskiy wrote:
> Upcoming in-kernel VFIO acceleration needs different handling in real
> and virtual modes which makes it hard to support both modes in
> the same handler.
>
> This creates a copy of kvmppc_rm_h_stuff_tce and kvmppc_rm_h_put_tc
The domain/PHB field of PCI addresses has its value obtained from a
global variable, incremented each time a new domain (represented by
struct pci_controller) is added on the system. The domain addition
process happens during boot or due to PCI device hotplug.
As recent kernels are using predictab
Excerpts from andrew.donnellan's message of 2016-03-18 15:01:21 +1100:
> Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for
> userspace access")
It doesn't fix that since there was no cxl kernel API support at the
time, so this wasn't a regression - just something we missed wh
> IMO, we should ditch the module parameter altogether and never treat
> timebase sync failure as fatal, and leave that up to any applications
> actually need it to check.
I agree with this this.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.o
On Thu, Mar 17, 2016 at 02:33:50PM -0700, Joe Perches wrote:
> On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> > 2016-03-17 Joe Perches :
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches wrote:
> > > []
> > > > > It's a name
Hi,
2016-03-17 Gustavo Padovan :
> From: Gustavo Padovan
>
> to_user_ptr() is a local macro defined by signal_32.c, rename it to
> __to_user_ptr() as now we will have a global to_user_ptr() defined by
> kernel.h that has a different meaning from this one.
>
> Cc: Benjamin Herrenschmidt
> Cc:
On Thursday 17 March 2016 12:01:01 Rob Herring wrote:
> On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote:
> > >> This makes the driver non-portable. Better identify the specific
> > >> workarounds based on the compatible string for this device, or add a
> > >> boolean DT property for the
On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches wrote:
> On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
>> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches wrote:
>> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> > > 2016-03-17 Gustavo Padovan :
>> > > > 2016-03-17 Joe Perches :
>>
On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> 2016-03-17 Gustavo Padovan :
> > 2016-03-17 Joe Perches :
> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > >
> > > > This function had copies in 3 different files. Unify them in
> > > > kernel.h.
> > > This is only us
On Wed, Mar 16, 2016 at 02:59:38PM +0100, Arnd Bergmann wrote:
> On Wednesday 16 March 2016 13:12:36 Andy Shevchenko wrote:
> >
> > > I've also sent a patch that fixes the link error on ARM and that should
> > > work on all other architectures too.
> >
> > In case of avr32 signalfd_read() fails.
On Wed, 9 Mar 2016 17:29:00 Alexey Kardashevskiy wrote:
> NPU PHB TCE Kill register is exactly the same as in the rest of POWER8
> so let's reuse the existing code for NPU. The only bit missing is
> a helper to reset the entire TCE cache so this moves such a helper
> from NPU code and renames it.
>
Thanks for fixing Alexey!
On Wed, 9 Mar 2016 17:29:01 Alexey Kardashevskiy wrote:
> This uses the page size from iommu_table instead of hard-coded 4K.
> This should cause no change in behavior.
>
> While we are here, move bits around to prepare for further rework
> which will define and use iommu
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 tab
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.
Signed-off-b
At present KVM on powerpc always reports KVM_CAP_PPC_ALLOC_HTAB as enabled.
However, the ioctl() it advertises (KVM_PPC_ALLOCATE_HTAB) only actually
works on KVM HV. On KVM PR it will fail with ENOTTY.
qemu already has a workaround for this, so it's not breaking things in
practice, but it would b
This is an implementation of the kernel parts of the PAPR hashed page
table (HPT) resizing extension.
It contains a complete guest-side implementation - or as complete as
it can be until we have a final PAPR change.
It also contains a draft host side implementation for KVM HV (the KVM
PR and TCG
Currently, the powerpc kvm_arch structure contains a number of variables
tracking the state of the guest's hashed page table (HPT) in KVM HV. This
patch gathers them all together into a single kvm_hpt_info substructure.
This makes life more convenient for the upcoming HPT resizing
implementation.
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 reasonable
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
This adds a new powerpc-specific KVM_CAP_SPAPR_RESIZE_HPT capability to
advertise whether KVM is capable of handling the PAPR extensions for
resizing the hashed page table during guest runtime.
At present, HPT resizing is possible with KVM PR without kernel
modification, since the HPT is managed w
Currently the kvm_hpt_info structure stores the hashed page table's order,
and also the number of HPTEs it contains and a mask for its size. The
last two can be easily derived from the order, so remove them and just
calculate them as necessary with a couple of helper inlines.
Signed-off-by: David
The difference between kvm_alloc_hpt() and kvmppc_alloc_hpt() is not at
all obvious from the name. In practice kvmppc_alloc_hpt() allocates an HPT
by whatever means, and clals kvm_alloc_hpt() which will attempt to allocate
it with CMA only.
To make this less confusing, rename kvm_alloc_hpt() to k
Currently, kvmppc_alloc_hpt() both allocates a new hashed page table (HPT)
and sets it up as the active page table for a VM. For the upcoming HPT
resize implementation we're going to want to allocate HPTs separately from
activating them.
So, split the allocation itself out into kvmppc_allocate_hp
The KVM_PPC_ALLOCATE_HTAB ioctl() is used to set the size of hashed page
table (HPT) that userspace expects a guest VM to have, and is also used to
clear that HPT when necessary (e.g. guest reboot).
At present, once the ioctl() is called for the first time, the HPT size can
never be changed therea
The kvm_unmap_rmapp() function, called from certain MMU notifiers, is used
to force all guest mappings of a particular host page to be set ABSENT, and
removed from the reverse mappings.
For HPT resizing, we will have some cases where we want to set just a
single guest HPTE ABSENT and remove its re
This patch adds a stub (always failing) implementation of the hypercalls
for the HPT resizing PAPR extension.
For now we include a hack which makes it safe for qemu to call ENABLE_HCALL
on these hypercalls, although it will have no effect. That should go away
once the PAPR change is formalized an
This adds code to initialize an HPT resize operation, and complete its
prepare phase, including allocating and clearing a tentative new HPT. It
also includes corresponding code to free things afterwards.
Signed-off-by: David Gibson
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 19 ++
This updates the KVM_CAP_SPAPR_RESIZE_HPT capability to advertise the
presence of in-kernel HPT resizing on KVM HV. In fact the HPT resizing
isn't fully implemented, but this allows us to experiment with what's
there.
Signed-off-by: David Gibson
---
arch/powerpc/kvm/powerpc.c | 5 -
1 file
This adds an outline (not yet working) of an implementation for the HPT
resizing PAPR extension. Specifically it adds the work function which will
handle preparation for the resize, and synchronization between this, the
the HPT resizing hypercalls, the guest page fault path and guest HPT update
pa
This adds code for the "guts" of an HPT resize operation: rehashing
HPTEs from the current HPT into the new resized HPT, and switching the
guest over to the new HPT.
This is performed by the H_RESIZE_HPT_COMMIT hypercall. The guest is
prevented from running during this operation, to simplify
sync
On Wed, 16 Mar 2016 16:55:50 David Gibson wrote:
> On Wed, Mar 09, 2016 at 05:29:02PM +1100, Alexey Kardashevskiy wrote:
> > NPU devices are quite specific, in fact they represent side DMA channel
> > of a GPU device. The GPU/NPU driver never actually configures DMA
> > for NPU devices, instead it
On 18/03/16 17:30, Ian Munsie wrote:
Excerpts from andrew.donnellan's message of 2016-03-18 15:01:21 +1100:
Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for
userspace access")
It doesn't fix that since there was no cxl kernel API support at the
time, so this wasn't a reg
On Wed, Mar 09, 2016 at 05:29:04PM +1100, Alexey Kardashevskiy wrote:
> NPU devices have their own TVT which means they are isolated and can be
> passed to the userspace via VFIO. The first step is to create an IOMMU
> group and attach devices there so does the patch.
>
> This adds a helper to npu
On Mon, Mar 21, 2016 at 02:53:07PM +1100, David Gibson wrote:
> This is an implementation of the kernel parts of the PAPR hashed page
> table (HPT) resizing extension.
>
> It contains a complete guest-side implementation - or as complete as
> it can be until we have a final PAPR change.
>
> It al
On Wed, 9 Mar 2016 17:29:03 Alexey Kardashevskiy wrote:
> The pnv_ioda_pe struct keeps an array of peers. At the moment it is only
> used to link GPU and NPU for 2 purposes:
>
> 1. Access NPU _quickly_ when configuring DMA for GPU - this was addressed
> in the previos patch by removing use of it a
38 matches
Mail list logo
