On Wed, 3 Oct 2018 07:49:44 +0200
Christophe LEROY wrote:
> Le 03/10/2018 à 07:02, Nicholas Piggin a écrit :
> > On Mon, 1 Oct 2018 12:30:21 + (UTC)
> > Christophe Leroy wrote:
> >
> >> This patch cleans the powerpc kernel before activating
> >> CONFIG_THREAD_INFO_IN_TASK:
> >> - The
Le 03/10/2018 à 07:34, Nicholas Piggin a écrit :
On Mon, 1 Oct 2018 12:30:25 + (UTC)
Christophe Leroy wrote:
thread_info is not anymore in the stack, so the entire stack
can now be used.
Nice.
In the meantime, all pointers to the stacks are not anymore
pointers to thread_info so
On Wed, 3 Oct 2018 07:47:05 +0200
Christophe LEROY wrote:
> Le 03/10/2018 à 07:30, Nicholas Piggin a écrit :
> > On Mon, 1 Oct 2018 12:30:23 + (UTC)
> > Christophe Leroy wrote:
> >
> >> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> >> moves the thread_info into task_struct.
>
Le 03/10/2018 à 07:02, Nicholas Piggin a écrit :
On Mon, 1 Oct 2018 12:30:21 + (UTC)
Christophe Leroy wrote:
This patch cleans the powerpc kernel before activating
CONFIG_THREAD_INFO_IN_TASK:
- The purpose of the pointer given to call_do_softirq() and
call_do_irq() is to point the new
Le 03/10/2018 à 07:30, Nicholas Piggin a écrit :
On Mon, 1 Oct 2018 12:30:23 + (UTC)
Christophe Leroy wrote:
This patch activates CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects
On Mon, 1 Oct 2018 12:30:31 + (UTC)
Christophe Leroy wrote:
> CURRENT_THREAD_INFO() now uses the PACA to retrieve 'current' pointer,
> it doesn't use 'sp' anymore.
Can you remove this too now? I think it will be clearer what's going on
and easier to read once everyone remembers current is
Le 03/10/2018 à 05:20, Michael Ellerman a écrit :
Andreas Schwab writes:
On Sep 14 2018, Michael Neuling wrote:
This stops us from doing code patching in init sections after they've
been freed.
This breaks booting on PowerBook6,7, crashing very early.
Crud, sorry.
My CI setup tests
On Mon, 1 Oct 2018 12:30:27 + (UTC)
Christophe Leroy wrote:
> The table of pointers 'current_set' has been used for retrieving
> the stack and current. They used to be thread_info pointers as
> they were pointing to the stack and current was taken from the
> 'task' field of the thread_info.
On Tue, Oct 02, 2018 at 09:31:21PM +1000, Paul Mackerras wrote:
> From: Suraj Jitindar Singh
>
> Consider a normal (L1) guest running under the main hypervisor (L0),
> and then a nested guest (L2) running under the L1 guest which is acting
> as a nested hypervisor. L0 has page tables to map the
On Mon, 1 Oct 2018 12:30:25 + (UTC)
Christophe Leroy wrote:
> thread_info is not anymore in the stack, so the entire stack
> can now be used.
Nice.
>
> In the meantime, all pointers to the stacks are not anymore
> pointers to thread_info so this patch changes them to void*
Wasn't this
On Mon, 1 Oct 2018 12:30:23 + (UTC)
Christophe Leroy wrote:
> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
>
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of
On Tue, Oct 02, 2018 at 09:31:17PM +1000, Paul Mackerras wrote:
> This adds a new hypercall, H_ENTER_NESTED, which is used by a nested
> hypervisor to enter one of its nested guests. The hypercall supplies
> register values in two structs. Those values are copied by the level 0
> (L0) hypervisor
On Tue, Oct 02, 2018 at 09:31:16PM +1000, Paul Mackerras wrote:
> This starts the process of adding the code to support nested HV-style
> virtualization. It defines a new H_SET_PARTITION_TABLE hypercall which
> a nested hypervisor can use to set the base address and size of a
> partition table in
On Tue, Oct 02, 2018 at 09:31:20PM +1000, Paul Mackerras wrote:
> From: Suraj Jitindar Singh
>
> A HEAI (hypervisor emulation assistance interrupt) occurs when a
> hypervisor resource or instruction is used in a privileged but
> non-hypervisor state and the LPCR_EVIRT bit is set in LPCR. When
>
On Tue, Oct 02, 2018 at 06:00:16PM +1000, Paul Mackerras wrote:
> On Tue, Oct 02, 2018 at 05:00:09PM +1000, David Gibson wrote:
> > On Fri, Sep 28, 2018 at 07:45:49PM +1000, Paul Mackerras wrote:
> > > This adds a new hypercall, H_ENTER_NESTED, which is used by a nested
> > > hypervisor to enter
On Mon, 1 Oct 2018 12:30:21 + (UTC)
Christophe Leroy wrote:
> This patch cleans the powerpc kernel before activating
> CONFIG_THREAD_INFO_IN_TASK:
> - The purpose of the pointer given to call_do_softirq() and
> call_do_irq() is to point the new stack ==> change it to void*
> - Don't use
On Mon, 1 Oct 2018 12:30:19 + (UTC)
Christophe Leroy wrote:
> When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
> includes asm/current.h. This generates a circular dependency.
> To avoid that, asm/processor.h shall not be included in mmu-hash.h
>
> In order to do that, this patch
Raz writes:
> Hello
>
> I want to learn about powerpc architecture, mainly hypervisor and
> partioning. I download the books (1,2, and 3 ) but I feel it lacks
> a lot of information. Are there other books ?
The ISA describes how the CPU works to allow you to implement a
hypervisor, but it
On Wed, 3 Oct 2018 10:29:57 +1000
Anton Blanchard wrote:
> When analysing sources of OS jitter, I noticed that doorbells cannot be
> traced.
>
> Signed-off-by: Anton Blanchard
Acked-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/trace.h | 16
>
Andreas Schwab writes:
> On Sep 14 2018, Michael Neuling wrote:
>
>> This stops us from doing code patching in init sections after they've
>> been freed.
>
> This breaks booting on PowerBook6,7, crashing very early.
Crud, sorry.
My CI setup tests with the mac99 qemu model, but that boots
> >
> > We also support 4K page sizes on PPC. If I am not mistaken this means every
> > ATSD
> > would invalidate the entire GPU TLB for a the given PID on those systems.
> > Could
> > we change the above check to `if (size <= PAGE_64K)` to avoid this?
>
> PPC supports 4K pages but the GPU ATS
On Tue, 2018-10-02 at 23:35 +0200, Andreas Schwab wrote:
> On Sep 14 2018, Michael Neuling wrote:
>
> > This stops us from doing code patching in init sections after they've
> > been freed.
>
> This breaks booting on PowerBook6,7, crashing very early.
Sorry, Can you try?
Thanks for the review. Comments below.
On Tue, 2 Oct 2018, Alistair Popple wrote:
> Thanks Mark,
>
> Looks like some worthwhile improvments to be had. I've added a couple of
> comments inline below.
>
> > +#define PAGE_64K (64UL * 1024) +#define PAGE_2M (2UL * 1024 * 1024)
> > +#define
> >
Michael Bringmann writes:
> powerpc/drmem: Export many of the functions of DRMEM to parse
> "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug
> operations and for Post Migration events.
This isn't a criticism of your patch, but I think the drmem.c code
should be moved into
When analysing sources of OS jitter, I noticed that doorbells cannot be
traced.
Signed-off-by: Anton Blanchard
---
arch/powerpc/include/asm/trace.h | 16
arch/powerpc/kernel/dbell.c | 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/powerpc/include/asm/trace.h
This fixes a crash on powerpc32 when using global data during early init
without relocating its address.
Fixes: 51c3c62b58 (powerpc: Avoid code patching freed init sections)
Signed-off-by: Andreas Schwab
---
arch/powerpc/lib/code-patching.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Sep 14 2018, Michael Neuling wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
This breaks booting on PowerBook6,7, crashing very early.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73
On 10/01/2018 06:00 AM, Michael Bringmann wrote:
> migration/memory: This patch adds code that recognizes changes to
> the associativity of memory blocks described by the device-tree
> properties in order to drive equivalent 'hotplug' operations to
> update local and general kernel data structures
On 10/01/2018 05:59 AM, Michael Bringmann wrote:
> migration/memory: This patch adds a new pseries hotplug action
> for CPU and memory operations, PSERIES_HP_ELOG_ACTION_READD_MULTIPLE.
> This is a variant of the READD operation which performs the action
> upon multiple instances of the resource
On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote:
> Hi Bjorn and others,
>
> Triggered by Christoph's patches, I had another go at converting
> all of the remaining pci host bridge implementations to be based
> on pci_alloc_host_bridge and a separate registration function.
>
> This
On 10/01/2018 05:59 AM, Michael Bringmann wrote:
> powerpc/drmem: Export many of the functions of DRMEM to parse
> "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug
> operations and for Post Migration events.
>
> Also modify the DRMEM initialization code to allow it to,
>
> * Be
On Tue, Oct 2, 2018 at 1:08 AM Madalin-cristian Bucur
wrote:
>
> > -Original Message-
> > From: Li Yang [mailto:leoyang...@nxp.com]
> > Sent: Tuesday, October 2, 2018 12:50 AM
> > To: Madalin-cristian Bucur
> > Cc: Roy Pledge ; Claudiu Manoil
> > ; Catalin Marinas ; Scott
> > Wood ;
On 10/02/2018 11:13 AM, Michael Bringmann wrote:
>
>
> On 10/02/2018 11:04 AM, Michal Hocko wrote:
>> On Tue 02-10-18 10:14:49, Michael Bringmann wrote:
>>> On 10/02/2018 09:59 AM, Michal Hocko wrote:
On Tue 02-10-18 09:51:40, Michael Bringmann wrote:
[...]
> When the device-tree
On Tue, Oct 2, 2018 at 1:29 AM Madalin-cristian Bucur
wrote:
>
> > -Original Message-
> > From: Li Yang [mailto:leoyang...@nxp.com]
> > Sent: Tuesday, October 2, 2018 1:30 AM
> > To: Madalin-cristian Bucur
> > Cc: Roy Pledge ; Claudiu Manoil
> > ; Catalin Marinas ; Scott
> > Wood ;
On 10/01/2018 01:56 PM, Michael Bringmann wrote:
> The PPC mobility code may receive RTAS requests to perform PRRN
> topology changes at any time, including during LPAR migration
> operations. In some configurations where the affinity of CPUs
> or memory is being changed on that platform, the
On 10/02/2018 11:04 AM, Michal Hocko wrote:
> On Tue 02-10-18 10:14:49, Michael Bringmann wrote:
>> On 10/02/2018 09:59 AM, Michal Hocko wrote:
>>> On Tue 02-10-18 09:51:40, Michael Bringmann wrote:
>>> [...]
When the device-tree affinity attributes have changed for memory,
the 'nid'
On Tue 02-10-18 10:14:49, Michael Bringmann wrote:
> On 10/02/2018 09:59 AM, Michal Hocko wrote:
> > On Tue 02-10-18 09:51:40, Michael Bringmann wrote:
> > [...]
> >> When the device-tree affinity attributes have changed for memory,
> >> the 'nid' affinity calculated points to a different node for
When removing memory we need to remove the memory from the node
it was added to instead of looking up the node it should be in
in the device tree.
During testing we have seen scenarios where the affinity for a
LMB changes due to a partition migration or PRRN event. In these
cases the node the LMB
On 02/10/2018 15:47, Michal Hocko wrote:
> On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
>> On 01/10/2018 10:40, Michal Hocko wrote:
>>> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
>>> [...]
>>>
>>> I haven't read the patch itself but I just wanted to note one thing
>>> about this part
On 10/02/2018 09:59 AM, Michal Hocko wrote:
> On Tue 02-10-18 09:51:40, Michael Bringmann wrote:
> [...]
>> When the device-tree affinity attributes have changed for memory,
>> the 'nid' affinity calculated points to a different node for the
>> memory block than the one used to install it,
On Tue 02-10-18 09:51:40, Michael Bringmann wrote:
[...]
> When the device-tree affinity attributes have changed for memory,
> the 'nid' affinity calculated points to a different node for the
> memory block than the one used to install it, previously on the
> source system. The newly calculated
See below.
On 10/01/2018 06:20 PM, Tyrel Datwyler wrote:
> On 10/01/2018 01:27 PM, Michal Hocko wrote:
>> On Mon 01-10-18 13:56:25, Michael Bringmann wrote:
>>> In some LPAR migration scenarios, device-tree modifications are
>>> made to the affinity of the memory in the system. For instance,
>>>
This adds CONFIG_DEBUG_VM checks to ensure:
- The kernel stack is in the SLB after it's flushed and bolted.
- We don't insert an SLB for an address that is aleady in the SLB.
- The kernel SLB miss handler does not take an SLB miss.
Signed-off-by: Nicholas Piggin
---
slb_flush_and_rebolt is misleading, it is called in virtual mode, so
it can not possibly change the stack, so it should not be touching the
shadow area. And since vmalloc is no longer bolted, it should not
change any bolted mappings at all.
Change the name to slb_flush_and_restore_bolted, and
Fixes: 5e46e29e6a97 ("powerpc/64s/hash: convert SLB miss handlers to C")
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/slb.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index
slb_setup_new_exec and preload_new_slb_context run with interrupts
and preemption enabled, which can be corrupted by re-entrant interrupt
or process touching SLB preload cache or SLB allocator.
Hard disable interrupts over these regions.
Fixes: 5e46e29e6a97 ("powerpc/64s/hash: convert SLB miss
In several places, more care has to be taken to prevent compiler or
CPU re-ordering of memory accesses into critical sections that must
not take SLB faults. Barriers are explained in the comments.
Fixes: 5e46e29e6a97 ("powerpc/64s/hash: convert SLB miss handlers to C")
Fixes: 89ca4e126a3f
slb_setup_new_exec and preload_new_slb_context assumed if an address
missed the preload cache, then it would not be in the SLB and could
be added. This is wrong if the preload cache has started to overflow.
This can cause SLB multi-hits on user addresses.
That assumption came from an earlier
PPR is the odd register out when it comes to interrupt handling,
it is saved in current->thread.ppr while all others are saved on
the stack.
The difficulty with this is that accessing thread.ppr can cause a
SLB fault, but the SLB fault handler implementation in C change had
assumed the normal
struct pt_regs is part of the user ABI and also the fundametal
structure for saving registers at interrupt.
The generic kernel code makes it difficult to completely decouple
these, but it's easy enough to add additional space required to save
more registers. Create a struct int_stack with struct
This reverts commit 8fed04d0f6aedf99b3d811ba58d38bb7f938a47a.
There are a number of problems with this patch, there are minor bugs
like vmalloc_sllp update no longer being picked up into pacas, but
more fundamentally the SLB flush can not be broadcast out to other
CPUs because it must be done in
This is another spin of the fixes. Also painfully re-discovered
that we need https://patchwork.ozlabs.org/patch/962327/, as it
prevents POWER8 NUMA from booting (initial stack SLB for the
!0 node CPUs gets cleared by the initial TLB flush without it,
and the SLB handler now uses the stack...)
On Fri, Sep 28, 2018 at 4:01 PM Li Yang wrote:
>
> On Fri, Sep 28, 2018 at 3:07 PM Rob Herring wrote:
> >
> > On Thu, Sep 27, 2018 at 5:25 PM Li Yang wrote:
> > >
> > > Hi Rob and Grant,
> > >
> > > Various device tree specs are recommending to include all the
> > > potential compatible strings
Shuah Khan writes:
> On 09/27/2018 10:52 PM, Michael Ellerman wrote:
>> [ + linuxppc-dev ]
>>
>> Anders Roxell writes:
>>> If the kernel headers aren't installed we can't build all the tests.
>>> Add a new make target rule 'khdr' in the file lib.mk to generate the
>>> kernel headers and that
On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
> On 01/10/2018 10:40, Michal Hocko wrote:
> > On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> > [...]
> >
> > I haven't read the patch itself but I just wanted to note one thing
> > about this part
> >
> >> For paravirtualized devices it
This adds code to call the H_TLB_INVALIDATE hypercall when running as
a guest, in the cases where we need to invalidate TLBs (or other MMU
caches) as part of managing the mappings for a nested guest. Calling
H_TLB_INVALIDATE is an alternative to doing the tlbie instruction and
having it be
With this, userspace can enable a KVM-HV guest to run nested guests
under it.
Signed-off-by: Paul Mackerras
---
Documentation/virtual/kvm/api.txt | 14 ++
arch/powerpc/include/asm/kvm_ppc.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 17 +
This adds a list of valid shadow PTEs for each nested guest to
the 'radix' file for the guest in debugfs. This can be useful for
debugging.
Reviewed-by: David Gibson
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/kvm_book3s_64.h | 1 +
arch/powerpc/kvm/book3s_64_mmu_radix.c |
From: Suraj Jitindar Singh
The hcall H_ENTER_NESTED takes as the two parameters the address in
L1 guest memory of a hv_regs struct and a pt_regs struct which the
L1 guest would like to use to run a L2 guest and in which are returned
the exit state of the L2 guest. For efficiency, these are in
With this, the KVM-HV module can be loaded in a guest running under
KVM-HV, and if the hypervisor supports nested virtualization, this
guest can now act as a nested hypervisor and run nested guests.
This also adds some checks to inform userspace that HPT guests are not
supported by nested
From: Suraj Jitindar Singh
restore_hv_regs() is used to copy the hv_regs L1 wants to set to run the
nested (L2) guest into the vcpu structure. We need to sanitise these
values to ensure we don't let the L1 guest hypervisor do things we don't
want it to.
We don't let data address watchpoints or
This adds a one-reg register identifier which can be used to read and
set the virtual PTCR for the guest. This register identifies the
address and size of the virtual partition table for the guest, which
contains information about the nested guests under this guest.
Migrating this value is the
When running as a nested hypervisor, this avoids reading hypervisor
privileged registers (specifically HFSCR, LPIDR and LPCR) at startup;
instead reasonable default values are used. This also avoids writing
LPIDR in the single-vcpu entry/exit path.
Also, this removes the check for CPU_FTR_HVMODE
From: Suraj Jitindar Singh
This is only done at level 0, since only level 0 knows which physical
CPU a vcpu is running on. This does for nested guests what L0 already
did for its own guests, which is to flush the TLB on a pCPU when it
goes to run a vCPU there, and there is another vCPU in the
From: Suraj Jitindar Singh
When running a nested (L2) guest the guest (L1) hypervisor will use
hypervisor privileged tlb invalidation instructions (to manage the
partition scoped page tables) which will result in hypervisor
emulation assistance interrupts. We emulate these instructions on behalf
From: Suraj Jitindar Singh
When a host (L0) page which is mapped into a (L1) guest is in turn
mapped through to a nested (L2) guest we keep a reverse mapping (rmap)
so that these mappings can be retrieved later.
Whenever we create an entry in a shadow_pgtable for a nested guest we
create a
From: Suraj Jitindar Singh
Consider a normal (L1) guest running under the main hypervisor (L0),
and then a nested guest (L2) running under the L1 guest which is acting
as a nested hypervisor. L0 has page tables to map the address space for
L1 providing the translation from L1 real address -> L0
From: Suraj Jitindar Singh
A HEAI (hypervisor emulation assistance interrupt) occurs when a
hypervisor resource or instruction is used in a privileged but
non-hypervisor state and the LPCR_EVIRT bit is set in LPCR. When
this occurs bit 45 is set in HSRR1. Detect the occurrence of this,
and if
When we are running as a nested hypervisor, we use a hypercall to
enter the guest rather than code in book3s_hv_rmhandlers.S. This means
that the hypercall handlers listed in hcall_real_table never get called.
There are some hypercalls that are handled there and not in
kvmppc_pseries_do_hcall(),
This adds a new hypercall, H_ENTER_NESTED, which is used by a nested
hypervisor to enter one of its nested guests. The hypercall supplies
register values in two structs. Those values are copied by the level 0
(L0) hypervisor (the one which is running in hypervisor mode) into the
vcpu struct of
This adds code to call the H_IPI and H_EOI hypercalls when we are
running as a nested hypervisor (i.e. without the CPU_FTR_HVMODE cpu
feature) and we would otherwise access the XICS interrupt controller
directly or via an OPAL call.
Reviewed-by: David Gibson
Signed-off-by: Paul Mackerras
---
This starts the process of adding the code to support nested HV-style
virtualization. It defines a new H_SET_PARTITION_TABLE hypercall which
a nested hypervisor can use to set the base address and size of a
partition table in its memory (analogous to the PTCR register).
On the host (level 0
kvmppc_unmap_pte() does a sequence of operations that are open-coded in
kvm_unmap_radix(). This extends kvmppc_unmap_pte() a little so that it
can be used by kvm_unmap_radix(), and makes kvm_unmap_radix() call it.
Reviewed-by: David Gibson
Signed-off-by: Paul Mackerras
---
From: Suraj Jitindar Singh
The radix page fault handler accounts for all cases, including just
needing to insert a pte. This breaks it up into separate functions for
the two main cases; setting rc and inserting a pte.
This allows us to make the setting of rc and inserting of a pte
generic for
From: Suraj Jitindar Singh
When destroying a VM we return the LPID to the pool, however we never
zero the partition table entry. This is instead done when we reallocate
the LPID.
Zero the partition table entry on VM teardown before returning the LPID
to the pool. This means if we were running
From: Suraj Jitindar Singh
kvmppc_mmu_radix_xlate() is used to translate an effective address
through the process tables. The process table and partition tables have
identical layout. Exploit this fact to make the kvmppc_mmu_radix_xlate()
function able to translate either an effective address
When the 'regs' field was added to struct kvm_vcpu_arch, the code
was changed to use several of the fields inside regs (e.g., gpr, lr,
etc.) but not the ccr field, because the ccr field in struct pt_regs
is 64 bits on 64-bit platforms, but the cr field in kvm_vcpu_arch is
only 32 bits. This
Currently the code for handling hypervisor instruction page faults
passes 0 for the flags indicating the type of fault, which is OK in
the usual case that the page is not mapped in the partition-scoped
page tables. However, there are other causes for hypervisor
instruction page faults, such as
This adds a file called 'radix' in the debugfs directory for the
guest, which when read gives all of the valid leaf PTEs in the
partition-scoped radix tree for a radix guest, in human-readable
format. It is analogous to the existing 'htab' file which dumps
the HPT entries for a HPT guest.
This creates an alternative guest entry/exit path which is used for
radix guests on POWER9 systems when we have indep_threads_mode=Y. In
these circumstances there is exactly one vcpu per vcore and there is
no coordination required between vcpus or vcores; the vcpu can enter
the guest without
Currently kvmppc_handle_exit_hv() is called with the vcore lock held
because it is called within a for_each_runnable_thread loop.
However, we already unlock the vcore within kvmppc_handle_exit_hv()
under certain circumstances, and this is safe because (a) any vcpus
that become runnable and are
This adds a parameter to __kvmppc_save_tm and __kvmppc_restore_tm
which allows the caller to indicate whether it wants the nonvolatile
register state to be preserved across the call, as required by the C
calling conventions. This parameter being non-zero also causes the
MSR bits that enable TM,
This streamlines the first part of the code that handles a hypervisor
interrupt that occurred in the guest. With this, all of the real-mode
handling that occurs is done before the "guest_exit_cont" label; once
we get to that label we are committed to exiting to host virtual mode.
Thus the machine
This pulls out the assembler code that is responsible for saving and
restoring the PMU state for the host and guest into separate functions
so they can be used from an alternate entry path. The calling
convention is made compatible with C.
Reviewed-by: David Gibson
Signed-off-by: Paul Mackerras
This removes code that clears the external interrupt pending bit in
the pending_exceptions bitmap. This is left over from an earlier
iteration of the code where this bit was set when an escalation
interrupt arrived in order to wake the vcpu from cede. Currently
we set the vcpu->arch.irq_pending
This is based on a patch by Suraj Jitindar Singh.
This moves the code in book3s_hv_rmhandlers.S that generates an
external, decrementer or privileged doorbell interrupt just before
entering the guest to C code in book3s_hv_builtin.c. This is to
make future maintenance and modification easier.
Currently we use two bits in the vcpu pending_exceptions bitmap to
indicate that an external interrupt is pending for the guest, one
for "one-shot" interrupts that are cleared when delivered, and one
for interrupts that persist until cleared by an explicit action of
the OS (e.g. an acknowledge to
This patch series implements nested virtualization in the KVM-HV
module for radix guests on POWER9 systems. Unlike PR KVM, nested
guests are able to run in supervisor mode, meaning that performance is
much better than with PR KVM, and is very close to the performance of
a non-nested guests for
When doing nested virtualization, it is only necessary to do the
transactional memory hypervisor assist at level 0, that is, when
we are in hypervisor mode. Nested hypervisors can just use the TM
facilities as architected. Therefore we should clear the
CPU_FTR_P9_TM_HV_ASSIST bit when we are not
> > Add BUS_ATTR_WO macro to make it easier to add attributes without
> > auditing the mode settings. Also, use the newly added macro where
> > appropriate.
> >
> > Signed-off-by: Ioana Ciornei
> > ---
> > arch/powerpc/platforms/pseries/ibmebus.c | 12
> > drivers/block/rbd.c
On Tue, Oct 02, 2018 at 09:59:29AM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 03:51:21 -0500
> Segher Boessenkool wrote:
> > And that is required by the ABI!
> >
> > """
> > 2.2.2.4. Protected Zone
> >
> > The 288 bytes below the stack pointer are available as volatile program
> >
On Tue, Oct 02, 2018 at 04:01:52PM +1000, David Gibson wrote:
> On Fri, Sep 28, 2018 at 07:45:48PM +1000, Paul Mackerras wrote:
> > This starts the process of adding the code to support nested HV-style
> > virtualization. It defines a new H_SET_PARTITION_TABLE hypercall which
> > a nested
On Tue, Oct 02, 2018 at 05:00:09PM +1000, David Gibson wrote:
> On Fri, Sep 28, 2018 at 07:45:49PM +1000, Paul Mackerras wrote:
> > This adds a new hypercall, H_ENTER_NESTED, which is used by a nested
> > hypervisor to enter one of its nested guests. The hypercall supplies
> > register values in
Thanks, this looks good to me.
Reviewed-by: Alistair Popple
On Thursday, 27 September 2018 4:23:09 PM AEST Mark Hairgrove wrote:
> There are two types of ATSDs issued to the NPU: invalidates targeting a
> specific virtual address and invalidates targeting the whole address
> space. In both
On Fri, Sep 28, 2018 at 07:45:50PM +1000, Paul Mackerras wrote:
> This adds code to call the H_IPI and H_EOI hypercalls when we are
> running as a nested hypervisor (i.e. without the CPU_FTR_HVMODE cpu
> feature) and we would otherwise access the XICS interrupt controller
> directly or via an OPAL
Looks good to me, thanks!
Reviewed-by: Alistair Popple
On Thursday, 27 September 2018 4:23:11 PM AEST Mark Hairgrove wrote:
> This threshold is no longer used now that all invalidates issue a single
> ATSD to each active NPU.
>
> Signed-off-by: Mark Hairgrove
> ---
>
Thanks Mark,
Looks like some worthwhile improvments to be had. I've added a couple of
comments inline below.
> +#define PAGE_64K (64UL * 1024) +#define PAGE_2M (2UL * 1024 * 1024) +#define
> PAGE_1G (1UL * 1024 * 1024 * 1024)
include/linux/sizes.h includes definitions for SZ_64K, SZ_2M, SZ_1G,
On Fri, Sep 28, 2018 at 07:45:49PM +1000, Paul Mackerras wrote:
> This adds a new hypercall, H_ENTER_NESTED, which is used by a nested
> hypervisor to enter one of its nested guests. The hypercall supplies
> register values in two structs. Those values are copied by the level 0
> (L0) hypervisor
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Tuesday, October 2, 2018 1:30 AM
> To: Madalin-cristian Bucur
> Cc: Roy Pledge ; Claudiu Manoil
> ; Catalin Marinas ; Scott
> Wood ; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE ; linuxppc-dev
> ; lkml
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Tuesday, October 2, 2018 12:50 AM
> To: Madalin-cristian Bucur
> Cc: Roy Pledge ; Claudiu Manoil
> ; Catalin Marinas ; Scott
> Wood ; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE ; linuxppc-dev
> ; lkml
1 - 100 of 104 matches
Mail list logo
