Hi all,
On Mon, 25 Feb 2019 17:42:48 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
This was actually the akpm tree.
--
Cheers,
Stephen Rothwell
pgp1M_ZXESUtL.pgp
Description: OpenPGP digital signature
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/irq.c
between commit:
c8e409a33cf8 ("powerpc/irq: use memblock functions returning virtual address")
and other patches in the powerpc tree
from the powerpc tree and patch:
"powerpc: use memb
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/setup_64.c
between commits:
c8e409a33cf8 ("powerpc/irq: use memblock functions returning virtual address")
d608898abc74 ("powerpc: clean stack pointers naming")
from the powerpc tree and comm
On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> The associated HW interrupt source is simply allocated at the OPAL/HW
> level and then MASKED. KVM only needs to know about its type: LSI or
> MSI.
I think it would be helpful to explain to the reader here that with
XIVE, all inte
On Fri, Feb 22, 2019 at 12:28:38PM +0100, Cédric Le Goater wrote:
> 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 "mapp
On Fri, Feb 22, 2019 at 12:28:40PM +0100, Cédric Le Goater wrote:
> 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 destruct
On Fri, Feb 22, 2019 at 12:28:39PM +0100, 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 'destr
On Mon, Feb 25, 2019 at 11:35:27AM +1100, David Gibson wrote:
> On Fri, Feb 22, 2019 at 12:28:27PM +0100, Cédric Le Goater wrote:
> > + xc->xive = xive;
> > + xc->vcpu = vcpu;
> > + xc->server_num = cpu;
> > + xc->vp_id = xive->vp_base + cpu;
>
> Hrm. This ties the internal VP id to the u
On Fri, Feb 22, 2019 at 12:28:27PM +0100, Cédric Le Goater wrote:
> The user interface exposes a new capability to let QEMU connect the
> vCPU to the XIVE KVM device if required. The capability is only
> advertised on a PowerNV Hypervisor as support for nested guests
> (pseries KVM Hypervisor) is n
On Fri, Feb 22, 2019 at 12:28:36PM +0100, Cédric Le Goater wrote:
> 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 :
>
> - Int
On Fri, Feb 22, 2019 at 12:28:37PM +0100, Cédric Le Goater wrote:
> 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 wi
On Fri, Feb 22, 2019 at 12:28:35PM +0100, Cédric Le Goater wrote:
> 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 c
On Fri, Feb 22, 2019 at 12:28:34PM +0100, Cédric Le Goater wrote:
> At a VCPU level, the state of the thread interrupt management
> registers needs to be collected. These registers are cached under the
> 'xive_saved_state.w01' field of the VCPU when the VPCU context is
> pulled from the HW thread.
On Fri, Feb 22, 2019 at 12:28:33PM +0100, Cédric Le Goater wrote:
> 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 notification are
> queued have not been mod
On Fri, Feb 22, 2019 at 12:28:32PM +0100, Cédric Le Goater wrote:
> This control will be used by the H_INT_SYNC hcall from QEMU.
>
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/include/uapi/asm/kvm.h| 1 +
> arch/powerpc/kvm/book3s_xive_native.c | 34 ++
On Fri, Feb 22, 2019 at 12:28:31PM +0100, Cédric Le Goater wrote:
> 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 rema
On Fri, Feb 22, 2019 at 12:28:30PM +0100, Cédric Le Goater wrote:
> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
> H_INT_GET_QUEUE_CONFIG hcalls from QEMU. They will also be used to
> restore the configuration of the XIVE EQs in the KVM device and to
> capture the internal runtime
On Fri, Feb 22, 2019 at 12:28:25PM +0100, Cédric Le Goater wrote:
> The support for XIVE native exploitation mode in Linux/KVM needs a
> couple more OPAL calls to configure the sPAPR guest and to get/set the
> state of the XIVE internal structures.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by
On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> The associated HW interrupt source is simply allocated at the OPAL/HW
> level and then MASKED. KVM only needs to know about its type: LSI or
> MSI.
>
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/include/uapi/asm/kvm.h
On Fri, Feb 22, 2019 at 12:28:29PM +0100, Cédric Le Goater wrote:
> This control will be used by the H_INT_SET_SOURCE_CONFIG hcall from
> QEMU and also to restore the configuration of the source in the KVM
> device.
>
> The XIVE internal IRQ structure is extended with the value of the
> Effective
On Fri, Feb 22, 2019 at 12:28:26PM +0100, Cédric Le Goater wrote:
> 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 when running on a L0 hypervisor only. Support
> for nested guest
On Fri, Feb 22, 2019 at 12:28:27PM +0100, Cédric Le Goater wrote:
> The user interface exposes a new capability to let QEMU connect the
> vCPU to the XIVE KVM device if required. The capability is only
> advertised on a PowerNV Hypervisor as support for nested guests
> (pseries KVM Hypervisor) is n
Cédric Le Goater writes:
> The support for XIVE native exploitation mode in Linux/KVM needs a
> couple more OPAL calls to configure the sPAPR guest and to get/set the
> state of the XIVE internal structures.
>
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/include/asm/opal-api.h
There is very low possibility ( < 0.1% ) that channel swap happened
in beginning when multi output/input pin is enabled. The issue is
that hardware can't send data to correct pin in the beginning with
the normal enable flow.
This is hardware issue, but there is no errata, the workaround flow
is th
Thanks, will send v2.
Best regards
Wang shengjiu
>
> Hi Shengjiu.
>
> On Thu, Feb 21, 2019 at 6:53 AM S.j. Wang
> wrote:
> >
> > From: Shengjiu Wang
>
> Better use your nxp.com address as the freescale.com domain is gone for a
> long time.
>
> > There is very low possibility ( < 0.1% ) that
Hi Michael,
On Sun, 24 Feb 2019 22:48:57 +1100 Michael Ellerman wrote:
>
> But do they need SOBs?
I think so, since they modify the code ..
> The DCO says:
>
> By making a contribution to this project, I certify that:
>
> (a) The contribution was created in whole or in part by me and
Stephen Rothwell writes:
> Hi all,
>
> Commit
>
> f68e7927212f ("Revert "powerpc/book3s32: Reorder _PAGE_XXX flags to
> simplify TLB handling"")
>
> is missing a Signed-off-by from its author and committer.
>
> Reverts are commits as well :-)
But do they need SOBs?
The DCO says:
By making a
27 matches
Mail list logo
