Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
macro is not masking away the last two bits of the offset per the ISA,
resulting in the generation of 'lwa' instruction instead of the intended
'ld'
On Thu, Mar 14, 2019 at 11:27 AM Michael Ellerman wrote:
>
> Mathieu Malaterre writes:
> > On Sat, Feb 16, 2019 at 3:26 AM Masahiro Yamada
> > wrote:
> >>
> >> On Sat, Feb 16, 2019 at 1:11 AM Mathieu Malaterre wrote:
> >> >
> >> > On Fri, Feb 15, 2019 at 10:41 AM Masahiro Yamada
> >> > wrote:
Mark,
On Fri, Mar 15, 2019 at 3:08 PM Mark Cave-Ayland
wrote:
>
> Hi all,
>
> I've just done a git pull and rebuilt master on my Mac Mini G4 in order to
> test
> Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on
> boot :(
Ouch :(
> My last working git checkout was
On 02/05/2019 10:10 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit :
/*
* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -205,20 +208,46 @@ transfer_to_handler_cont:
mflrr9
lwz
On Fri, Mar 15, 2019 at 11:36:04AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 10:12, Andy Shevchenko wrote:
>
> >> Part II will be about moving the mmio range from mapbase and
> >> mapsize (which are used quite inconsistently) to a struct resource
> >> and using helpers for
On 15.03.19 19:11, Andy Shevchenko wrote:
>> The actual goal is generalizing the whole iomem handling, so individual
>> usually just need to call some helpers that do most of the things.
>> Finally, I also wanted to have all io region information consolidated
>> in struct resource.
>
> That's
On 13/03/19 09:02, Cédric Le Goater wrote:
> The 'destroy' method is currently used to destroy all devices when the
> VM is destroyed after the vCPUs have been freed.
>
> This new KVM ioctl exposes the same KVM device method. It acts as a
> software reset of the VM to 'destroy' selected devices
On Fri, Mar 15, 2019 at 8:44 PM Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 19:11, Andy Shevchenko wrote:
> OTOH, the name, IMHO, is a bit misleading. Any chance of ever changing
> it to a more clear name (eg. devm_request_and_ioremap_resource()) ?
Compare iomap vs. ioREmap.
--
On 15.03.19 15:26, Greg KH wrote:
> On Fri, Mar 15, 2019 at 10:06:16AM +0100, Enrico Weigelt, metux IT consult
> wrote:
>> On 14.03.19 23:52, Greg KH wrote:
>>> On Thu, Mar 14, 2019 at 11:33:40PM +0100, Enrico Weigelt, metux IT consult
>>> wrote:
Use the safer devm versions of memory
Hello,
On the POWER9 processor, the XIVE interrupt controller can control
interrupt sources using MMIOs to trigger events, to EOI or to turn off
the sources. Priority management and interrupt acknowledgment is also
controlled by MMIO in the CPU presenter sub-engine.
PowerNV/baremetal Linux runs
These controls will be used by the H_INT_SET_QUEUE_CONFIG and
H_INT_GET_QUEUE_CONFIG hcalls from QEMU to configure the underlying
Event Queue in the XIVE IC. They will also be used to restore the
configuration of the XIVE EQs and to capture the internal run-time
state of the EQs. Both 'get' and
This control is to be used by the H_INT_RESET hcall from QEMU. Its
purpose is to clear all configuration of the sources and EQs. This is
necessary in case of a kexec (for a kdump kernel for instance) to make
sure that no remaining configuration is left from the previous boot
setup so that the new
Some KVM devices will want to handle special mappings related to the
underlying HW. For instance, the XIVE interrupt controller of the
POWER9 processor has MMIO pages for thread interrupt management and
for interrupt source control that need to be exposed to the guest when
the OS has the required
Full support for the XIVE native exploitation mode is now available,
advertise the capability KVM_CAP_PPC_IRQ_XIVE for guests running on
PowerNV KVM Hypervisors only. Support for nested guests (pseries KVM
Hypervisor) is not yet available. XIVE should also have been activated
which is default
The XIVE KVM device maintains a list of interrupt sources for the VM
which are allocated in the pool of generic interrupts (IPIs) of the
main XIVE IC controller. These are used for the CPU IPIs as well as
for virtual device interrupts. The IRQ number space is defined by
QEMU.
The XIVE device
This is the basic framework for the new KVM device supporting the XIVE
native exploitation mode. The user interface exposes a new KVM device
to be created by QEMU, only available when running on a L0 hypervisor
only. Support for nested guests is not available yet.
The XIVE device reuses the
Each source is associated with an Event State Buffer (ESB) with a
even/odd pair of pages which provides commands to manage the source:
to trigger, to EOI, to turn off the source for instance.
The custom VM fault handler will deduce the guest IRQ number from the
offset of the fault, and the ESB
When migration of a VM is initiated, a first copy of the RAM is
transferred to the destination before the VM is stopped, but there is
no guarantee that the EQ pages in which the event notifications are
queued have not been modified.
To make sure migration will capture a consistent memory state,
When the VM boots, the CAS negotiation process determines which
interrupt mode to use and invokes a machine reset. At that time, the
previous KVM interrupt device is 'destroyed' before the chosen one is
created. Upon destruction, the vCPU interrupt presenters using the KVM
device should be cleared
The state of the thread interrupt management registers needs to be
collected for migration. These registers are cached under the
'xive_saved_state.w01' field of the VCPU when the VPCU context is
pulled from the HW thread. An OPAL call retrieves the backup of the
IPB register in the underlying XIVE
This control will be used by the H_INT_SET_SOURCE_CONFIG hcall from
QEMU to configure the target of a source and also to restore the
configuration of a source when migrating the VM.
The XIVE source interrupt structure is extended with the value of the
Effective Interrupt Source Number. The EISN
The user interface exposes a new capability KVM_CAP_PPC_IRQ_XIVE to
let QEMU connect the vCPU presenters to the XIVE KVM device if
required. The capability is not advertised for now as the full support
for the XIVE native exploitation mode is not yet available. When this
is case, the capability
This control will be used by the H_INT_SYNC hcall from QEMU to flush
event notifications on the XIVE IC owning the source.
Signed-off-by: Cédric Le Goater
---
Changes since v2 :
- fixed locking on source block
arch/powerpc/include/uapi/asm/kvm.h| 1 +
On Fri, Mar 15, 2019 at 12:12:45PM +0100, Laurent Vivier wrote:
> Another way to avoid the nodes overlapping for the offline nodes at
> startup is to ensure the default values don't define a distance that
> merge all offline nodes into node 0.
>
> A powerpc specific patch can workaround the
The 'destroy' method is currently used to destroy all devices when the
VM is destroyed after the vCPUs have been freed.
This new KVM ioctl exposes the same KVM device method. It acts as a
software reset of the VM to 'destroy' selected devices when necessary
and perform the required cleanups on
On 03/15/2019 03:51 PM, Naveen N. Rao wrote:
> Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
> was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
> macro is not masking away the last two bits of the offset per the ISA,
> resulting in the generation of
Here is an attempt to isolate NVLink interconnects between GPU to
let them be passed through individually.
At the moment I mostly wonder about the sanity of the appoach.
Please comment. Thanks.
Alexey Kardashevskiy (2):
vfio_pci: Allow device specific error handlers
vfio-pci-nvlink2:
On 15.03.19 10:04, Andy Shevchenko wrote:
> On Fri, Mar 15, 2019 at 12:41 AM Enrico Weigelt, metux IT consult
> wrote:
>>
>> Instead of fetching out data from a struct resource for passing
>> it to devm_ioremap(), directly use devm_ioremap_resource()
>
> I don't see any advantage of this change.
PCI device drivers can define own pci_error_handlers which are called
on errors or before/after reset. The VFIO PCI driver defines one as well.
This adds a vfio_pci_error_handlers struct for VFIO PCI which is a wrapper
on top of vfio_err_handlers. At the moment it defines reset_done() -
this hook
The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
(on POWER9) NVLinks. In addition to that, GPUs themselves have direct
peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
platform puts all interconnected GPUs to the same IOMMU group.
However the user may
On Fri, Mar 15, 2019 at 12:41 AM Enrico Weigelt, metux IT consult
wrote:
>
> Instead of fetching out data from a struct resource for passing
> it to devm_ioremap(), directly use devm_ioremap_resource()
I don't see any advantage of this change.
See also below.
> ---
On Fri, Mar 15, 2019 at 12:40 AM Enrico Weigelt, metux IT consult
wrote:
> here's v2 of my serial cleanups queue - part I:
>
> essentially using helpers to code more compact and switching to
> devm_*() functions for mmio management.
>
> Part II will be about moving the mmio range from mapbase
On 14.03.19 23:52, Greg KH wrote:
> On Thu, Mar 14, 2019 at 11:33:40PM +0100, Enrico Weigelt, metux IT consult
> wrote:
>> Use the safer devm versions of memory mapping functions.
>
> What is "safer" about them?
Garbage collection :)
Several drivers didn't seem to clean up properly (maybe
Hello Enrico,
On Thu, Mar 14, 2019 at 11:34:09PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Use the safer devm versions of memory mapping functions.
In which aspect is devm_ioremap safer than ioremap?
The only upside I'm aware of is that the memory is automatically
unmapped on device
On Fri, Mar 15, 2019 at 12:37 AM Enrico Weigelt, metux IT consult
wrote:
>
> Use the safer devm versions of memory mapping functions.
If you are going to use devm_*_free(), what's the point to have this
change from the beginning?
P.S. Disregard that this is untested series...
> ---
On Fri, Mar 15, 2019 at 11:12 AM Andy Shevchenko
wrote:
> On Fri, Mar 15, 2019 at 12:40 AM Enrico Weigelt, metux IT consult
> wrote:
>
> > here's v2 of my serial cleanups queue - part I:
> >
> > essentially using helpers to code more compact and switching to
> > devm_*() functions for mmio
This enables support for synchronous DAX fault on powerpc
The generic changes are added as part of
commit b6fb293f2497 ("mm: Define MAP_SYNC and VM_SYNC flags")
Without this, mmap returns EOPNOTSUPP for MAP_SYNC with MAP_SHARED_VALIDATE
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR
On Fri, Mar 15, 2019 at 08:12:47PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 15:26, Greg KH wrote:
> > Yes, there are lots of drivers for devices that are never unloaded or
> > removed from the system. The fact that no one has reported any problems
> > with them means that
The support for XIVE native exploitation mode in Linux/KVM needs a
couple more OPAL calls to get and set the state of the XIVE internal
structures being used by a sPAPR guest.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
---
Changes since v2:
- remove extra OPAL call
On 15/03/2019 13:25, Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 12:12:45PM +0100, Laurent Vivier wrote:
>
>> Another way to avoid the nodes overlapping for the offline nodes at
>> startup is to ensure the default values don't define a distance that
>> merge all offline nodes into node 0.
>>
Segher Boessenkool wrote:
Hi!
On Wed, Mar 13, 2019 at 12:54:16PM +0200, Yauheni Kaliuta wrote:
This is because of the handling of the +2 offset.
The low two bits of instructions with primary opcodes 58 and 62 are part
of the opcode, not the offset. These instructions can not have offsets
The KVM XICS-over-XIVE device and the proposed KVM XIVE native device
implement an IRQ space for the guest using the generic IPI interrupts
of the XIVE IC controller. These interrupts are allocated at the OPAL
level and "mapped" into the guest IRQ number space in the range 0-0x1FFF.
Interrupt
On Wed, 13 Mar 2019 15:15:21 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> The use of offsets is required only in the frontend, so alter
> the IRQ API to only work with IRQ IDs in the backend.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/misc/ocxl/afu_irq.c | 31
Hi all,
I've just done a git pull and rebuilt master on my Mac Mini G4 in order to test
Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on boot
:(
My last working git checkout was somewhere around the 5.0-rc stage, so I
suspect it's
something that's been merged for 5.1.
Michael,
Are you able to get this merged before 5.1-rc1 comes out ?
Thanks
Christophe
Le 08/03/2019 à 17:06, Christophe Leroy a écrit :
Le 08/03/2019 à 17:03, Segher Boessenkool a écrit :
On Fri, Mar 08, 2019 at 07:05:22AM +, Christophe Leroy wrote:
Not only the 603 but all 6xx need
Each thread has an associated Thread Interrupt Management context
composed of a set of registers. These registers let the thread handle
priority management and interrupt acknowledgment. The most important
are :
- Interrupt Pending Buffer (IPB)
- Current Processor Priority (CPPR)
On 15.03.19 10:12, Andy Shevchenko wrote:
>> Part II will be about moving the mmio range from mapbase and
>> mapsize (which are used quite inconsistently) to a struct resource
>> and using helpers for that. But this one isn't finished yet.
>> (if somebody likes to have a look at it, I can send
On 04/03/2019 20:59, Laurent Vivier wrote:
> When we hotplug a CPU in a memoryless/cpuless node,
> the kernel crashes when it rebuilds the sched_domains data.
>
> I reproduce this problem on POWER and with a pseries VM, with the following
> QEMU parameters:
>
> -machine pseries -enable-kvm -m
On Fri, Mar 15, 2019 at 10:06:16AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 14.03.19 23:52, Greg KH wrote:
> > On Thu, Mar 14, 2019 at 11:33:40PM +0100, Enrico Weigelt, metux IT consult
> > wrote:
> >> Use the safer devm versions of memory mapping functions.
> >
> > What is "safer"
49 matches
Mail list logo
