Excerpts from Daniel Axtens's message of February 19, 2021 4:03 pm:
> Hi Nick,
>
>> +maybe_skip:
>> +cmpwi r12,0x200
>> +beq 1f
>> +cmpwi r12,0x300
>> +beq 1f
>> +cmpwi r12,0x380
>> +beq 1f
>> +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>> +/* XXX: cbe stuff
Excerpts from Fabiano Rosas's message of February 13, 2021 6:33 am:
> Nicholas Piggin writes:
>
>> Move the GUEST_MODE_SKIP logic into KVM code. This is quite a KVM
>> internal detail that has no real need to be in common handlers.
>
> LGTM,
>
>>
>> (XXX: Need to confirm CBE handlers etc)
>
>
Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm:
> Hi Nicholas:
>
> I met some problem for this patch, like this:
>
> kva = vmalloc(3*1024k);
>
> remap_vmalloc_range(xxx, kva, xxx)
>
> It failed because that the check for page_count(page) is null so return, it
> break the so
Almost all logic is moved to C, by introducing a new in_guest mode that
selects and branches very early in the interrupt handler to the P9 exit
code.
The remaining assembly is only about 160 lines of low level stack setup,
with VCPU vs host register save and restore, plus a small shim to the
legac
Switching the MMU from radix<->radix mode is tricky particularly as the
MMU can remain enabled and requires a certain sequence of SPR updates.
Move these together into their own functions.
This also includes the radix TLB check / flush because it's tied in to
MMU switching due to tlbiel getting LP
This sets up the same calling convention from interrupt entry to
KVM interrupt handler for system calls as exists for other interrupt
types.
This is a better API, it uses a save area rather than SPR, and it has
more registers free to use. Using a single common API helps maintain
it, and it becomes
This is not used by PR KVM.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_64_entry.S | 3 ---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 +++-
arch/powerpc/kvm/book3s_segment.S | 7 +++
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/
Like the earlier patch for hcalls, KVM interrupt entry requires a
different calling convention than the Linux interrupt handlers
set up. Move the code that converts from one to the other into KVM.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 126 -
System calls / hcalls have a different calling convention than
other interrupts, so there is code in the KVMTEST to massage these
into the same form as other interrupt handlers.
Move this work into the KVM hcall handler. This means teaching KVM
a little more about the low level interrupt handler s
Add a separate hcall entry point. This can be used to deal with the
different calling convention.
Reviewed-by: Fabiano Rosas
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
arch/powerpc/kvm/book3s_64_entry.S | 6 +-
2 files changed, 7 insertions(+), 3 del
Move the GUEST_MODE_SKIP logic into KVM code. This is quite a KVM
internal detail that has no real need to be in common handlers.
Also add a comment explaining why this this thing exists.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 60 --
ar
Rather than bifurcate the call depending on whether or not HV is
possible, and have the HV entry test for PR, just make a single
common point which does the demultiplexing. This makes it simpler
to add another type of exit handler.
Reviewed-by: Fabiano Rosas
Signed-off-by: Nicholas Piggin
---
a
The va argument is not used in the function or set by its asm caller,
so remove it to be safe.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/kvm_ppc.h | 3 +--
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/
Rather than add the ME bit to the MSR when the guest is entered, make
it clear that the hypervisor does not allow the guest to clear the bit.
The ME addition is kept in the code for now, but a future patch will
warn if it's not present.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s
The code being executed in KVM_GUEST_MODE_SKIP is hypervisor code with
MSR[IR]=0, so the faults of concern are the d-side ones caused by access
to guest context by the hypervisor.
Instruction breakpoint interrupts are not a concern here. It's unlikely
any good would come of causing breaks in this
Cell does not support KVM.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 39cbea495154..5d0ad3b38e90 100644
--- a/arch/powerpc/kern
This has a lot more implemented, things tidied up, and more things split
out. It's also implemented on top of powerpc next and kvm next which
have a few prerequisite patches (mainly removing EXSLB).
I've got a bunch more things after this including implementing HPT
guests with radix host in the "n
Hi Nick,
> +maybe_skip:
> + cmpwi r12,0x200
> + beq 1f
> + cmpwi r12,0x300
> + beq 1f
> + cmpwi r12,0x380
> + beq 1f
> +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> + /* XXX: cbe stuff? instruction breakpoint? */
> + cmpwi r12,0xe02
> + beq 2f
Hi Nick,
> +++ b/arch/powerpc/kvm/book3s_64_entry.S
> @@ -0,0 +1,34 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * We come here from the first-level interrupt handlers.
> + */
> +.global kvmppc_interrupt
> +.balign IFETCH_ALIGN_BYTES
> +kvmppc
Hi Nicholas:
I met some problem for this patch, like this:
kva = vmalloc(3*1024k);
remap_vmalloc_range(xxx, kva, xxx)
It failed because that the check for page_count(page) is null so return, it
break the some logic for current modules.
because the new huge page is not valid for composed page.
On Thu, Feb 11, 2021 at 5:21 PM Tian Tao wrote:
>
> the module_platform_driver will call platform_driver_register.
> and It will set the .owner to THIS_MODULE
>
> Signed-off-by: Tian Tao
Acked-by: Shengjiu Wang
On 2/18/21 5:13 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
On 2/18/21 4:07 PM, Mimi Zohar wrote:
Hi Mimi,
On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote:
of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
a new device tree object th
Michael Ellerman writes:
> When we enabled STRICT_KERNEL_RWX we received some reports of boot
> failures when using the Hash MMU and running under phyp. The crashes
> are intermittent, and often exhibit as a completely unresponsive
> system, or possibly an oops.
>
> One example, which was caught
Michael Ellerman writes:
> Pull the loop calling hpte_updateboltedpp() out of
> hash__change_memory_range() into a helper function. We need it to be a
> separate function for the next patch.
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/mm/book3s64/hash_pgtable.c | 23 +++
Lakshmi Ramasubramanian writes:
> On 2/18/21 4:07 PM, Mimi Zohar wrote:
>
> Hi Mimi,
>
>> On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote:
>>> of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
>>> a new device tree object that includes architecture specific da
On 2/18/21 4:07 PM, Mimi Zohar wrote:
Hi Mimi,
On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote:
of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
a new device tree object that includes architecture specific data
for kexec system call. This should be defined
On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote:
> of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
> a new device tree object that includes architecture specific data
> for kexec system call. This should be defined only if the architecture
> being built defines
Rob Herring writes:
> On Thu, Feb 18, 2021 at 5:34 AM Stephen Rothwell
> wrote:
>> On Thu, 18 Feb 2021 21:44:37 +1100 Michael Ellerman
>> wrote:
>> >
>> > I think it just needs this?
>> >
>> > diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>> > index 87e34611f93d..0492c
Daniel Axtens writes:
> Michael Ellerman writes:
>
>> The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes
>> the key in bits 9-13, but currently we always set those bits to zero.
>>
>> In the past that hasn't been a problem because we always used key 0
>> for the kernel, and upda
of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
a new device tree object that includes architecture specific data
for kexec system call. This should be defined only if the architecture
being built defines kexec architecture structure "struct kimage_arch".
Define a new boolean
Hi all,
On Thu, 18 Feb 2021 07:52:52 -0600 Rob Herring wrote:
>
> On Thu, Feb 18, 2021 at 5:34 AM Stephen Rothwell
> wrote:
> >
> > On Thu, 18 Feb 2021 21:44:37 +1100 Michael Ellerman
> > wrote:
> > >
> > > I think it just needs this?
> > >
> > > diff --git a/arch/powerpc/kexec/elf_64.c b/a
On Thu, Feb 18, 2021 at 11:30:58PM +1100, Michael Ellerman wrote:
> lkp reported a build error in fsp2.o:
>
> CC arch/powerpc/platforms/44x/fsp2.o
> {standard input}:577: Error: unsupported relocation against base
>
> Which comes from:
>
> pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OP
On Thu, Feb 18, 2021 at 5:34 AM Stephen Rothwell wrote:
>
> Hi Michael,
>
> On Thu, 18 Feb 2021 21:44:37 +1100 Michael Ellerman
> wrote:
> >
> > I think it just needs this?
> >
> > diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> > index 87e34611f93d..0492ca6003f3 100644
On 16/02/2021 04:20, Alexey Kardashevskiy wrote:
The IOMMU table is divided into pools for concurrent mappings and each
pool has a separate spinlock. When taking the ownership of an IOMMU group
to pass through a device to a VM, we lock these spinlocks which triggers
a false negative warning in
lkp reported a build error in fsp2.o:
CC arch/powerpc/platforms/44x/fsp2.o
{standard input}:577: Error: unsupported relocation against base
Which comes from:
pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OPB_GESR0));
Where our mfdcr() macro is stringifying "base + PLB4OPB_GESR0", and
pa
Hi Michael,
On Thu, 18 Feb 2021 21:44:37 +1100 Michael Ellerman wrote:
>
> I think it just needs this?
>
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index 87e34611f93d..0492ca6003f3 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@
"Christopher M. Riedl" writes:
> On Thu Feb 11, 2021 at 11:21 PM CST, Daniel Axtens wrote:
...
>>
>> My only concern here was whether it was valid to access
>> if (__get_user(msr, &uc->uc_mcontext.gp_regs[PT_MSR]))
>> if CONFIG_PPC_TRANSACTIONAL_MEM was not defined, but I didn't think of
>> any ob
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the devicetree tree got a conflict in:
>
> arch/powerpc/kexec/elf_64.c
>
> between commit:
>
> 2377c92e37fe ("powerpc/kexec_file: fix FDT size estimation for kdump
> kernel")
>
> from the powerpc tree and commit:
>
> 130b2d5
38 matches
Mail list logo
