Re: [PATCH 11/13] kvm/powerpc: Handle some PAPR hcalls in the kernel
On 11.05.2011, at 12:45, Paul Mackerras wrote:
This adds the infrastructure for handling PAPR hcalls in the kernel,
either early in the guest exit path while we are still in real mode,
or later once the MMU has been turned back on and we are in the full
kernel context. The advantage of handling hcalls in real mode if
possible is that we avoid two partition switches -- and this will
become more important when we support SMT4 guests, since a partition
switch means we have to pull all of the threads in the core out of
the guest. The disadvantage is that we can only access the kernel
linear mapping, not anything vmalloced or ioremapped, since the MMU
is off.
This also adds code to handle the following hcalls in real mode:
H_ENTER Add an HPTE to the hashed page table
H_REMOVE Remove an HPTE from the hashed page table
H_READRead HPTEs from the hashed page table
H_PROTECT Change the protection bits in an HPTE
H_BULK_REMOVE Remove up to 4 HPTEs from the hashed page table
H_SET_DABRSet the data address breakpoint register
Plus code to handle the following hcalls in the kernel:
H_CEDEIdle the vcpu until an interrupt or H_PROD hcall arrives
H_PRODWake up a ceded vcpu
H_REGISTER_VPA Register a virtual processor area (VPA)
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/hvcall.h |5 +
arch/powerpc/include/asm/kvm_host.h | 11 +
arch/powerpc/include/asm/kvm_ppc.h |1 +
arch/powerpc/kernel/asm-offsets.c |2 +
arch/powerpc/kvm/book3s_64_mmu_hv.c | 342 +++
arch/powerpc/kvm/book3s_hv.c| 170 +++-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 150 +-
arch/powerpc/kvm/powerpc.c |2 +-
8 files changed, 679 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index 8edec71..a226002 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -29,6 +29,10 @@
#define H_LONG_BUSY_ORDER_100_SEC 9905 /* Long busy, hint that 100sec \
is a good time to retry */
#define H_LONG_BUSY_END_RANGE 9905 /* End of long busy range */
+
+/* Hacked in for HV-aware kvm support */
+#define H_TOO_HARD
Not sure I like the name - when is it used? :)
Also, if it's not in the PAPR, the guest should never receive it, right?
+
#define H_HARDWARE-1 /* Hardware error */
#define H_FUNCTION-2 /* Function not supported */
#define H_PRIVILEGE -3 /* Caller not privileged */
@@ -100,6 +104,7 @@
#define H_PAGE_SET_ACTIVE H_PAGE_STATE_CHANGE
#define H_AVPN(1UL(63-32)) /* An avpn is provided
as a sanity test */
#define H_ANDCOND (1UL(63-33))
+#define H_LOCAL (1UL(63-35))
#define H_ICACHE_INVALIDATE (1UL(63-40)) /* icbi, etc. (ignored for IO
pages) */
#define H_ICACHE_SYNCHRONIZE (1UL(63-41)) /* dcbst, icbi, etc (ignored
for IO pages */
#define H_ZERO_PAGE (1UL(63-48)) /* zero the page before mapping
(ignored for IO pages) */
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index ec62365..af6703e 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -59,6 +59,10 @@ struct kvm;
struct kvm_run;
struct kvm_vcpu;
+struct lppaca;
+struct slb_shadow;
+struct dtl;
+
struct kvm_vm_stat {
u32 remote_tlb_flush;
};
@@ -341,7 +345,14 @@ struct kvm_vcpu_arch {
u64 dec_expires;
unsigned long pending_exceptions;
u16 last_cpu;
+ u8 ceded;
+ u8 prodded;
u32 last_inst;
+
+ struct lppaca *vpa;
+ struct slb_shadow *slb_shadow;
+ struct dtl *dtl;
+ struct dtl *dtl_end;
int trap;
struct kvm_vcpu_arch_shared *shared;
unsigned long magic_page_pa; /* phys addr to map the magic page to */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index cd9ad96..b4ee11a 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -116,6 +116,7 @@ extern long kvmppc_prepare_vrma(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
extern void kvmppc_map_vrma(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
+extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
extern int kvmppc_core_init_vm(struct kvm *kvm);
extern void kvmppc_core_destroy_vm(struct kvm *kvm);
extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 49e97fd..fd56f14 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -189,6 +189,7 @@ int main(void)
Re: [PATCH 12/13] kvm/powerpc: Accelerate H_PUT_TCE by implementing it in real mode
On 11.05.2011, at 12:46, Paul Mackerras wrote:
From: David Gibson d...@au1.ibm.com
This improves I/O performance for guests using the PAPR paravirtualization
interface by making the H_PUT_TCE hcall faster, by implementing it in
real mode. H_PUT_TCE is used for updating virtual IOMMU tables, and is
used both for virtual I/O and for real I/O in the PAPR interface.
Since this moves the IOMMU tables into the kernel, we define a new
KVM_CREATE_SPAPR_TCE ioctl to allow qemu to create the tables.
The ioctl returns a file descriptor which can be used to mmap the
newly created table.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm.h |9 +++
arch/powerpc/include/asm/kvm_book3s_64.h |2 +
arch/powerpc/include/asm/kvm_host.h |9 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +
arch/powerpc/kvm/Makefile|3 +-
arch/powerpc/kvm/book3s_64_vio_hv.c | 73 +++
arch/powerpc/kvm/book3s_hv.c | 116 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S |2 +-
arch/powerpc/kvm/powerpc.c | 18 +
include/linux/kvm.h |5 ++
This one definitely needs documentation :).
10 files changed, 236 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_64_vio_hv.c
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 18ea696..a9e641b 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -22,6 +22,9 @@
#include linux/types.h
+/* Select powerpc specific features in linux/kvm.h */
+#define __KVM_HAVE_SPAPR_TCE
+
struct kvm_regs {
__u64 pc;
__u64 cr;
@@ -88,4 +91,10 @@ struct kvm_guest_debug_arch {
#define KVM_INTERRUPT_UNSET -2U
#define KVM_INTERRUPT_SET_LEVEL -3U
+/* for KVM_CAP_SPAPR_TCE */
+struct kvm_create_spapr_tce {
+ __u64 liobn;
+ __u32 window_size;
+};
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 4cadd61..e1a096b 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -25,4 +25,6 @@ static inline struct kvmppc_book3s_shadow_vcpu
*to_svcpu(struct kvm_vcpu *vcpu)
return get_paca()-shadow_vcpu;
}
+#define SPAPR_TCE_SHIFT 12
+
#endif /* __ASM_KVM_BOOK3S_64_H__ */
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af6703e..cda183e 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -144,6 +144,14 @@ struct kvmppc_pginfo {
atomic_t refcnt;
};
+struct kvmppc_spapr_tce_table {
+ struct list_head list;
+ struct kvm *kvm;
+ u64 liobn;
+ u32 window_size;
+ struct page *pages[0];
+};
+
struct kvm_arch {
unsigned long hpt_virt;
unsigned long ram_npages;
@@ -157,6 +165,7 @@ struct kvm_arch {
unsigned long host_sdr1;
int tlbie_lock;
unsigned short last_vcpu[NR_CPUS];
+ struct list_head spapr_tce_tables;
};
struct kvmppc_pte {
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index b4ee11a..de683fa 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -117,6 +117,8 @@ extern long kvmppc_prepare_vrma(struct kvm *kvm,
extern void kvmppc_map_vrma(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
+extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
+ struct kvm_create_spapr_tce *args);
extern int kvmppc_core_init_vm(struct kvm *kvm);
extern void kvmppc_core_destroy_vm(struct kvm *kvm);
extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 37c1a60..8ba062f 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -59,7 +59,8 @@ kvm-book3s_64_hv-objs := \
book3s.o \
book3s_hv.o \
book3s_hv_interrupts.o \
- book3s_64_mmu_hv.o
+ book3s_64_mmu_hv.o \
+ book3s_64_vio_hv.o
kvm-objs-$(CONFIG_KVM_BOOK3S_64_HV) := $(kvm-book3s_64_hv-objs)
kvm-book3s_32-objs := \
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c
b/arch/powerpc/kvm/book3s_64_vio_hv.c
new file mode 100644
index 000..ea0f8c5
--- /dev/null
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY
Re: [PATCH 13/13] kvm/powerpc: Allow book3s_hv guests to use SMT processor modes
On 11.05.2011, at 12:46, Paul Mackerras wrote:
This lifts the restriction that book3s_hv guests can only run one
hardware thread per core, and allows them to use up to 4 threads
per core on POWER7. The host still has to run single-threaded.
This capability is advertised to qemu through a new KVM_CAP_PPC_SMT
capability.
To use this, the host kernel should be booted with all threads
active, and then all the secondary threads should be offlined.
This will put the secondary threads into nap mode. KVM will then
wake them from nap mode and use them for running guest code (while
they are still offline). To wake the secondary threads, we send
them an IPI using a new xics_wake_cpu() function, implemented in
arch/powerpc/sysdev/xics/icp-native.c. In other words, at this stage
we assume that the platform has a XICS interrupt controller and
we are using icp-native.c to drive it. Since the woken thread will
need to acknowledge and clear the IPI, we also export the base
physical address of the XICS registers using kvmppc_set_xics_phys()
for use in the low-level KVM book3s code.
When a vcpu is created, it is assigned to a virtual core (vcore).
The vcore number is obtained by dividing the vcpu number by 4,
since we assume at most 4 threads per core. Thus, if qemu wishes
to run the guest in single-threaded mode, it should make all vcpu
numbers be multiples of 4.
We distinguish three states of a vcpu: runnable (i.e., ready to execute
the guest), blocked (that is, idle), and busy in host. We currently
implement a policy that the vcore can run only when all its threads
are runnable or blocked. This way, if a vcpu needs to execute elsewhere
in the kernel or in qemu, it can do so without being starved of CPU
by the other vcpus.
When a vcore starts to run, it executes in the context of one of the
vcpu threads. The other vcpu threads all go to sleep and stay asleep
until something happens requiring the vcpu thread to return to qemu,
or to wake up to run the vcore (this can happen when another vcpu
thread goes from busy in host state to blocked).
It can happen that a vcpu goes from blocked to runnable state (e.g.
because of an interrupt), and the vcore it belongs to is already
running. In that case it can start to run immediately as long as
the none of the vcpus in the vcore have started to exit the guest.
We send the next free thread in the vcore an IPI to get it to start
to execute the guest. It synchronizes with the other threads via
the vcore-entry_exit_count field to make sure that it doesn't go
into the guest if the other vcpus are exiting by the time that it
is ready to actually enter the guest.
Note that there is no fixed relationship between the hardware thread
number and the vcpu number. Hardware threads are assigned to vcpus
as they become runnable, so we will always use the lower-numbered
hardware threads in preference to higher-numbered threads if not all
the vcpus in the vcore are runnable, regardless of which vcpus are
runnable.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm.h |1 +
arch/powerpc/include/asm/kvm_host.h | 45 +-
arch/powerpc/include/asm/kvm_ppc.h | 13 ++
arch/powerpc/include/asm/paca.h |2 +
arch/powerpc/kernel/asm-offsets.c |6 +
arch/powerpc/kernel/exceptions-64s.S| 31 +++-
arch/powerpc/kernel/idle_power7.S |2 -
arch/powerpc/kvm/Kconfig|2 +-
arch/powerpc/kvm/book3s_hv.c| 266 +--
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 157 ++-
arch/powerpc/sysdev/xics/icp-native.c |7 +
include/linux/kvm.h |3 +
12 files changed, 506 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a9e641b..624c872 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -24,6 +24,7 @@
/* Select powerpc specific features in linux/kvm.h */
#define __KVM_HAVE_SPAPR_TCE
+#define __KVM_HAVE_PPC_SMT
struct kvm_regs {
__u64 pc;
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index cda183e..a2085da 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -25,10 +25,15 @@
#include linux/interrupt.h
#include linux/types.h
#include linux/kvm_types.h
+#include linux/threads.h
+#include linux/spinlock.h
#include linux/kvm_para.h
#include asm/kvm_asm.h
+#include asm/processor.h
-#define KVM_MAX_VCPUS 1
+#define KVM_MAX_VCPUSNR_CPUS
+#define KVM_THREADS_PER_CORE 4
So what if POWER8 (or whatever it will be called) comes along with 8 threads
per core? Would that change the userspace interface?
+#define KVM_MAX_VCORES (KVM_MAX_VCPUS / KVM_THREADS_PER_CORE)
#define KVM_MEMORY_SLOTS 32
/* memory slots that does not
Re: [PATCH 12/13] kvm/powerpc: Accelerate H_PUT_TCE by implementing it in real mode
On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote: On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote: I'm not sure I fully understand how this is supposed to work. If the tables are kept inside the kernel, how does userspace get to know where to DMA to? The guest gets a dma range from the device-tree which is the range of device-side dma addresses it can use that correspond to the table. The guest kernel uses the normal linux iommu space allocator to allocate space in that region and uses H_PUT_TCE to populate the corresponding table entries. This is the same interface that is used for real iommu's with PCI devices btw. I'm still slightly puzzled here :). IIUC the main point of an IOMMU is for the kernel to change where device accesses actually go to. So device DMAs address A, goes through the IOMMU, in reality accesses address B. Now, how do we tell the devices implemented in qemu that they're supposed to DMA to address B instead of A if the mapping table is kept in-kernel? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 12/13] kvm/powerpc: Accelerate H_PUT_TCE by implementing it in real mode
On Tue, 2011-05-17 at 11:31 +0200, Alexander Graf wrote: On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote: On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote: I'm not sure I fully understand how this is supposed to work. If the tables are kept inside the kernel, how does userspace get to know where to DMA to? The guest gets a dma range from the device-tree which is the range of device-side dma addresses it can use that correspond to the table. The guest kernel uses the normal linux iommu space allocator to allocate space in that region and uses H_PUT_TCE to populate the corresponding table entries. This is the same interface that is used for real iommu's with PCI devices btw. I'm still slightly puzzled here :). IIUC the main point of an IOMMU is for the kernel to change where device accesses actually go to. So device DMAs address A, goes through the IOMMU, in reality accesses address B. Right :-) Now, how do we tell the devices implemented in qemu that they're supposed to DMA to address B instead of A if the mapping table is kept in-kernel? Oh, bcs qemu mmaps the table :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 12/13] kvm/powerpc: Accelerate H_PUT_TCE by implementing it in real mode
On 17.05.2011, at 11:35, Benjamin Herrenschmidt wrote: On Tue, 2011-05-17 at 11:31 +0200, Alexander Graf wrote: On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote: On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote: I'm not sure I fully understand how this is supposed to work. If the tables are kept inside the kernel, how does userspace get to know where to DMA to? The guest gets a dma range from the device-tree which is the range of device-side dma addresses it can use that correspond to the table. The guest kernel uses the normal linux iommu space allocator to allocate space in that region and uses H_PUT_TCE to populate the corresponding table entries. This is the same interface that is used for real iommu's with PCI devices btw. I'm still slightly puzzled here :). IIUC the main point of an IOMMU is for the kernel to change where device accesses actually go to. So device DMAs address A, goes through the IOMMU, in reality accesses address B. Right :-) Now, how do we tell the devices implemented in qemu that they're supposed to DMA to address B instead of A if the mapping table is kept in-kernel? Oh, bcs qemu mmaps the table :-) That's the piece to the puzzle I was missing. Please document that interface properly - it needs to be rock stable :) Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
On 11.05.2011, at 12:34, Paul Mackerras wrote: The following series of patches enable KVM to exploit the hardware hypervisor mode on 64-bit Power ISA Book3S machines. At present only POWER7 is supported, but it would be easy to add other processors. Running the KVM host in hypervisor mode means that the guest can use both supervisor mode and user mode. That means that the guest can execute supervisor-privilege instructions and access supervisor- privilege registers. In addition the hardware directs most exceptions to the guest. Thus we don't need to emulate any instructions in the host. Generally, the only times we need to exit the guest are when it does a hypercall or when an external interrupt or host timer (decrementer) interrupt occurs. The focus of this KVM implementation is to run guests that use the PAPR (Power Architecture Platform Requirements) paravirtualization interface, which is the interface supplied by PowerVM on IBM pSeries machines. These patches are against Ben Herrenschmidt's next branch in his tree at git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git. Very nice patches indeed :). Is there any way I can test them? I don't like pulling code that I couldn't run anywhere yet. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode
On 16.05.2011, at 07:58, Paul Mackerras wrote:
On Sun, May 15, 2011 at 11:58:12PM +0200, Alexander Graf wrote:
On 11.05.2011, at 12:44, Paul Mackerras wrote:
+#ifdef CONFIG_KVM_BOOK3S_NONHV
I really liked how you called the .c file _pr - why call it NONHV now?
I agree, CONFIG_KVM_BOOK3S_PR would be better, I'll change it.
diff --git a/arch/powerpc/include/asm/paca.h
b/arch/powerpc/include/asm/paca.h
index 7412676..8dba5f6 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -149,6 +149,16 @@ struct paca_struct {
#ifdef CONFIG_KVM_BOOK3S_HANDLER
/* We use this to store guest state in */
struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+ struct kvm_vcpu *kvm_vcpu;
+ u64 dabr;
+ u64 host_mmcr[3];
+ u32 host_pmc[6];
+ u64 host_purr;
+ u64 host_spurr;
+ u64 host_dscr;
+ u64 dec_expires;
Hrm. I'd say either push those into shadow_vcpu for HV mode or get
rid of the shadow_vcpu reference. I'd probably prefer the former.
These are fields that are pieces of host state that we need to save
and restore across execution of a guest; they don't apply to any
specific guest or vcpu. That's why I didn't put them in shadow_vcpu,
which is specifically for one vcpu in one guest.
Given that book3s_pr copies the shadow_vcpu into and out of the paca,
I thought it best not to add fields to it that are only live while we
are in the guest. True, these fields only exist for book3s_hv, but if
we later on make it possible to select book3s_pr vs. book3s_hv at
runtime, we won't want to be copying these fields into and out of the
paca when book3s_pr is active.
Maybe we need another struct, kvm_host_state or something like that,
to save this sort of state.
Yeah, just put them into a different struct then. I don't want to clutter the
PACA struct with kvm fields all over :).
@@ -65,6 +98,7 @@ config KVM_440
bool KVM support for PowerPC 440 processors
depends on EXPERIMENTAL 44x
select KVM
+ select KVM_MMIO
e500 should also select MMIO, no?
Good point, I'll fix that.
+long kvmppc_alloc_hpt(struct kvm *kvm)
+{
+ unsigned long hpt;
+ unsigned long lpid;
+
+ hpt = __get_free_pages(GFP_KERNEL|__GFP_ZERO|__GFP_REPEAT|__GFP_NOWARN,
+ HPT_ORDER - PAGE_SHIFT);
This would end up failing quite often, no?
In practice it seems to be OK, possibly because the machines we're
testing this on have plenty of memory. Maybe we should get qemu to
allocate the HPT using hugetlbfs so the memory will come from the
reserved page pool. It does need to be physically contiguous and
aligned on a multiple of its size -- that's a hardware requirement.
Yes, I'd certainly prefer to see qemu allocate it. That'd also make things
easier for migration later, as we still have access to the hpt. But then again
- we can't really reuse the mappings there anyways, as they'll all be host
mappings. Phew. Have you given that some thought yet? We can probably just
ignore non-bolted entries - but the bolted ones need to be transferred.
Also, if we have qemu allocate the hpt memory, qemu can modify the mappings and
thus break out. Bleks. It should definitely not be able to write to the hpt
after it's actually being used by kvm.
+ kvm-arch.sdr1 = __pa(hpt) | (HPT_ORDER - 18);
+ kvm-arch.lpid = lpid;
+ kvm-arch.host_sdr1 = mfspr(SPRN_SDR1);
+ kvm-arch.host_lpid = mfspr(SPRN_LPID);
+ kvm-arch.host_lpcr = mfspr(SPRN_LPCR);
How do these correlate with the guest's hv mmu? I'd like to keep the
code clean enough so we can potentially use it for PR mode as well :).
The host SDR1 and LPID are different from the guest's. That is, the
guest has its own HPT which is quite separate from the host's. The
host values could be saved in global variables, though; there's no
real need for each VM to have its own copy, except that doing it this
way simplifies the low-level assembly code a little.
Well, my point is that I tried to separate the MMU implementation for the PR
KVM stuff. What I'd like to see at the end of the day would be a guest hv
implementation file that I could plug into PR kvm and have the MMU rolling by
using the exact same code as the HV code. Only the backend would be different.
Maybe there's some valid technical reason to not do it, but I haven't come
across any yet :).
+ /* First see what page size we have */
+ psize = user_page_size(mem-userspace_addr);
+ /* For now, only allow 16MB pages */
The reason to go for 16MB pages is because of the host mmu code, not
the guest hv mmu. So please at least #ifdef the code to HV so we
document that correlation.
I'm not sure what you mean by that. The reason for going for 16MB
pages initially is for performance (this way the guest can use 16MB
pages for its linear mapping) and to avoid having to deal with the
pages being paged or swapped on the host
Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
On Tue, May 17, 2011 at 11:46:34AM +0200, Alexander Graf wrote: Very nice patches indeed :). Is there any way I can test them? I don't like pulling code that I couldn't run anywhere yet. I can understand that, but unfortunately there are no machines available outside of IBM at this stage that can run this stuff. Do you think that the earlier patches in the series could go in for 2.6.40? Patches 1 to 8 don't require hypervisor mode and can be tested on a G5 or whatever. What would be the path for these patches to get upstream? Would this stuff normally go through Avi's tree? There is a bit of a complication in that they are based on Ben's next branch. Would Avi pull Ben's next branch, or would they go in via Ben's tree? Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/13] kvm/powerpc: Allow book3s_hv guests to use SMT processor modes
On Tue, May 17, 2011 at 10:21:56AM +0200, Alexander Graf wrote: On 11.05.2011, at 12:46, Paul Mackerras wrote: -#define KVM_MAX_VCPUS 1 +#define KVM_MAX_VCPUS NR_CPUS +#define KVM_THREADS_PER_CORE 4 So what if POWER8 (or whatever it will be called) comes along with 8 threads per core? Would that change the userspace interface? The idea is that userspace queries the KVM_CAP_PPC_SMT capability and the value it gets back is the number of vcpus per vcore. It then allocates vcpu numbers based on that. If a CPU came along with more than 4 threads per core then we'd have to change that define in the kernel, but that won't affect the userspace API. + /* wait for secondary threads to get back to nap mode */ + spin_lock(vc-lock); + if (vc-nap_count vc-n_woken) + kvmppc_wait_for_nap(vc); So you're taking the vcore wide lock and wait for other CPUs to set themselves to nap? Not sure I fully understand this. Why would another thread want to go to nap mode when it's 100% busy? It's more about waiting for the other hardware threads to have finished writing their vcpu state to memory. Currently those threads then go to nap mode, but they could in fact poll instead for a bit, so that name is possible a bit misleading, I agree. + cmpwi r12,0x980 + beq 40f + cmpwi r3,0x100 good old use define comment :) Yep, OK. :) Maybe I also missed the point here, but how does this correlate with Linux threads? Is each vcpu running in its own Linux thread? How does the scheduling happen? IIUC the host only sees a single thread per core and then distributes the vcpus to the respective host threads. Each vcpu has its own Linux thread, but while the vcore is running, all but one of them are sleeping. The thing is that since the host is running with each core single-threaded, one Linux thread is enough to run 4 vcpus. So when we decide we can run the vcore, the vcpu thread that discovered that we can now run the vcore takes the responsibility to run it. That involves sending an IPI to the other hardware threads to wake them up and get them to each run a vcpu. Then the vcpu thread that is running the vcore dives into the guest switch code itself. It synchronizes with the other threads and does the partition switch, and then they all enter the guest. We thought about various schemes to cope with the hardware restriction that all hardware threads in a core have to be in the same partition (at least whenever the MMU is on). This is the least messy scheme we could come up with. I'd be happy to discuss the alternatives if you like. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/13] kvm/powerpc: Handle some PAPR hcalls in the kernel
On Tue, May 17, 2011 at 09:54:35AM +0200, Alexander Graf wrote: Not sure I like the name - when is it used? :) When the real-mode hcall handler decides it can't handle the hcall and wants to pass it up. Also, if it's not in the PAPR, the guest should never receive it, right? Right. It's purely an internal value. + /* See if this is something we can handle in real mode */ + cmpwi r12,0xc00 use the define please OK + beq hcall_real_mode This is simply a hcall helper, as the name suggests. So the comment is slightly misleading - it should rather read like Try to handle hypercalls in real mode. Hmmm, OK, that's what it was trying to indicate. I could add try to the name if you like. + cmpdi r3,H_TOO_HARD + beq hcall_real_fallback Ah, very good. Please mark the constant as for internal use only then, as that's certainly fine :). Cool, will do. + li r12,0xc00 use the define please :) OK. Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/13] kvm/powerpc: Allow book3s_hv guests to use SMT processor modes
Am 17.05.2011 um 12:44 schrieb Paul Mackerras pau...@samba.org: On Tue, May 17, 2011 at 10:21:56AM +0200, Alexander Graf wrote: On 11.05.2011, at 12:46, Paul Mackerras wrote: -#define KVM_MAX_VCPUS 1 +#define KVM_MAX_VCPUSNR_CPUS +#define KVM_THREADS_PER_CORE4 So what if POWER8 (or whatever it will be called) comes along with 8 threads per core? Would that change the userspace interface? The idea is that userspace queries the KVM_CAP_PPC_SMT capability and the value it gets back is the number of vcpus per vcore. It then allocates vcpu numbers based on that. If a CPU came along with more than 4 threads per core then we'd have to change that define in the kernel, but that won't affect the userspace API. Ah, I see :). Tht's exactly why documentation is so important - with proper documentation you wouldn't need to explain those things to me :) +/* wait for secondary threads to get back to nap mode */ +spin_lock(vc-lock); +if (vc-nap_count vc-n_woken) +kvmppc_wait_for_nap(vc); So you're taking the vcore wide lock and wait for other CPUs to set themselves to nap? Not sure I fully understand this. Why would another thread want to go to nap mode when it's 100% busy? It's more about waiting for the other hardware threads to have finished writing their vcpu state to memory. Currently those threads then go to nap mode, but they could in fact poll instead for a bit, so that name is possible a bit misleading, I agree. Just so I understand the scheme: One vcpu needs to go to MMU mode in KVM, it then sends IPIs to stop the other threads and finally we return from this wait here? +cmpwir12,0x980 +beq40f +cmpwir3,0x100 good old use define comment :) Yep, OK. :) Maybe I also missed the point here, but how does this correlate with Linux threads? Is each vcpu running in its own Linux thread? How does the scheduling happen? IIUC the host only sees a single thread per core and then distributes the vcpus to the respective host threads. Each vcpu has its own Linux thread, but while the vcore is running, all but one of them are sleeping. The thing is that since the host is running with each core single-threaded, one Linux thread is enough to run 4 vcpus. So when we decide we can run the vcore, the vcpu thread that discovered that we can now run the vcore takes the responsibility to run it. That involves sending an IPI to the other hardware threads to wake them up and get them to each run a vcpu. Then the vcpu thread that is running the vcore dives into the guest switch code itself. It synchronizes with the other threads and does the partition switch, and then they all enter the guest. We thought about various schemes to cope with the hardware restriction that all hardware threads in a core have to be in the same partition (at least whenever the MMU is on). This is the least messy scheme we could come up with. I'd be happy to discuss the alternatives if you like. Oh, I'm certainly fine with the scheme :). I would just like to understand it and see it documented somewhere, as it's slightly unintuitive. Also, this scheme might confuse the host scheduler for a bit, as it might migrate threads to other host CPUs while it would prove beneficial for cache usage to keep them local. But since the scheduler doesn't know about the correlation between the threads, it can't be clever about it. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
Am 17.05.2011 um 13:15 schrieb Paul Mackerras pau...@samba.org: On Tue, May 17, 2011 at 11:46:34AM +0200, Alexander Graf wrote: Very nice patches indeed :). Is there any way I can test them? I don't like pulling code that I couldn't run anywhere yet. I can understand that, but unfortunately there are no machines available outside of IBM at this stage that can run this stuff. Do you think that the earlier patches in the series could go in for 2.6.40? Patches 1 to 8 don't require hypervisor mode and can be tested on a G5 or whatever. Oh, I can and will certainly test if the code breaks pr mode, but that doesn't mean it will do the right thing on HV machines :o. What would be the path for these patches to get upstream? Would this stuff normally go through Avi's tree? There is a bit of a complication in that they are based on Ben's next branch. Would Avi pull Ben's next branch, or would they go in via Ben's tree? Usually the ppc tree gets merged into Avi's tree and goes on from there. When we have interdependencies, we can certainly do it differently though. We can also shove them through Ben's tree this time around, as there are more dependencies on ppc code than KVM code. Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
On 05/17/2011 02:38 PM, Alexander Graf wrote: What would be the path for these patches to get upstream? Would this stuff normally go through Avi's tree? There is a bit of a complication in that they are based on Ben's next branch. Would Avi pull Ben's next branch, or would they go in via Ben's tree? Usually the ppc tree gets merged into Avi's tree and goes on from there. When we have interdependencies, we can certainly do it differently though. We can also shove them through Ben's tree this time around, as there are more dependencies on ppc code than KVM code. Yes, both options are fine. If it goes through kvm.git I can merge Ben's tree (provided it is append-only) and apply the kvm-ppc patches on top. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of
the
way multiple callbacks can be registered. How would:
err = event_x();
if (err == -EACCESS) {
be handled? [...]
The default behavior would be something obvious: to trigger all callbacks
and
use the first non-zero return value.
But how do we know which callback that was from? There's no ordering of what
callbacks are called first.
We do not have to know that - nor do the calling sites care in general. Do you
have some specific usecase in mind where the identity of the callback that
generates a match matters?
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
* Will Drewry w...@chromium.org wrote: This is *far* more generic still yields the same short-term end result as far as your sandboxing is concerned. Almost :/ [...] Hey that's a pretty good result from a subsystem that was not written with your usecase in mind *at all* ;-) [...] I still need to review the code you've pointed out, but, at present, the ftrace hooks occur after the seccomp and syscall auditing hooks. This means that that code is exposed no matter what in this model. To trim the exposed surface to userspace, we really need those early hooks. While I can see both hacky and less hacky approaches around this, it stills strikes me that the seccomp thread flag and early interception are good to reuse. One option might be to allow seccomp to be a secure-syscall event source, but I suspect that lands more on the hack-y side of the fence :) Agreed, there should be no security compromise imposed on your usecase, at all. You could move the event callback sooner into the syscall-entry sequence to make sure it's the highest priority thing to process? There's no semantic dependency on its current location so this can be changed AFAICS. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of
the
way multiple callbacks can be registered. How would:
err = event_x();
if (err == -EACCESS) {
be handled? [...]
The default behavior would be something obvious: to trigger all callbacks
and
use the first non-zero return value.
But how do we know which callback that was from? There's no ordering of
what
callbacks are called first.
We do not have to know that - nor do the calling sites care in general. Do
you
have some specific usecase in mind where the identity of the callback that
generates a match matters?
Maybe I'm confused. I was thinking that these event_*() are what we
currently call trace_*(), but the event_*(), I assume, can return a
value if a call back returns one.
Thus, we now have the ability to dynamically attach function calls to
arbitrary points in the kernel that can have an affect on the code that
called it. Right now, we only have the ability to attach function calls
to these locations that have passive affects (tracing/profiling).
But you say, nor do the calling sites care in general. Then what do
these calling sites do with the return code? Are we limiting these
actions to security only? Or can we have some other feature. I can
envision that we can make the Linux kernel quite dynamic here with self
modifying code. That is, anywhere we have hooks, perhaps we could
replace them with dynamic switches (jump labels). Maybe events would not
be the best use, but they could be a generic one.
Knowing what callback returned the result would be beneficial. Right
now, you are saying if the call back return anything, just abort the
call, not knowing what callback was called.
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame
Ben, Recent 2.6.39-rc kernels behave strangely on the Freescale dual core mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot sequence after mpic: requesting IPIs... When the system comes up, only one core shows in /proc/cpuinfo. Later on, lots of messages appear like the following: INFO: task ksoftirqd/1:9 blocked for more than 120 seconds. I bisected [1] the problem to: commit c56e58537d504706954a06570b4034c04e5b7500 Author: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Tue Mar 8 14:40:04 2011 +1100 powerpc/smp: Create idle threads on demand and properly reset them I don't see from that commit what had gone wrong. Perhaps you can help resolve this? Thanks, Richard 1. I had to patch commit e5462d16 by hand when bisecting, which is a fixup for commit fa3f82c8 and not yet merged in c56e5853. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: book to learn ppc assembly and architecture
thanks. regards, sha From: mi...@neuling.org To: b...@kernel.crashing.org CC: sha_...@hotmail.com; linuxppc-dev@lists.ozlabs.org Subject: Re: book to learn ppc assembly and architecture Date: Tue, 17 May 2011 09:43:35 +1000 In message 1305589123.2781.15.camel@pasglop you wrote: On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote: what is the best book to learn assembly and architecture . Reading the architecture books with a nice cup of tea. http://www.power.org/resources/downloads/PowerISA_V2.06B_V2_PUBLIC.pdf A slightly less steep approach might be to get yourself the programmer manuals of some older powerpc chips, like the freescale PEMs, and then move on to the full ISA True but a well aged Shiraz goes better with them than the cup of tea. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/13] kvm/powerpc: Move guest enter/exit down into subarch-specific code
On Wed, May 11, 2011 at 08:43:31PM +1000, Paul Mackerras wrote:
From 964ee93b2d728e4fb16ae66eaceb6e912bf114ad Mon Sep 17 00:00:00 2001
From: Paul Mackerras pau...@samba.org
Date: Tue, 10 May 2011 22:23:18 +1000
Subject: [PATCH 08/13] kvm/powerpc: Move guest enter/exit down into
subarch-specific code
Instead of doing the kvm_guest_enter/exit() and local_irq_dis/enable()
calls in powerpc.c, this moves them down into the subarch-specific
book3s_pr.c and booke.c. This eliminates an extra local_irq_enable()
call in book3s_pr.c, and will be needed for when we do SMT4 guest
support in the book3s hypervisor mode code.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm_ppc.h |1 +
arch/powerpc/kvm/book3s_interrupts.S |2 +-
arch/powerpc/kvm/book3s_pr.c | 12 ++--
arch/powerpc/kvm/booke.c | 13 +
arch/powerpc/kvm/powerpc.c |6 +-
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index f3c218a..3210911 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -42,6 +42,7 @@ enum emulation_result {
EMULATE_AGAIN,/* something went wrong. go again */
};
+extern int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
extern int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
extern char kvmppc_handlers_start[];
extern unsigned long kvmppc_handler_len;
diff --git a/arch/powerpc/kvm/book3s_interrupts.S
b/arch/powerpc/kvm/book3s_interrupts.S
index 2f0bc92..8c5e0e1 100644
--- a/arch/powerpc/kvm/book3s_interrupts.S
+++ b/arch/powerpc/kvm/book3s_interrupts.S
@@ -85,7 +85,7 @@
* r3: kvm_run pointer
* r4: vcpu pointer
*/
-_GLOBAL(__kvmppc_vcpu_entry)
+_GLOBAL(__kvmppc_vcpu_run)
kvm_start_entry:
/* Write correct stack frame */
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 08cedf0..f769915 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -891,8 +891,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
vfree(vcpu_book3s);
}
-extern int __kvmppc_vcpu_entry(struct kvm_run *kvm_run, struct kvm_vcpu
*vcpu);
-int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
+int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
double fpr[32][TS_FPRWIDTH];
@@ -944,14 +943,15 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
/* Remember the MSR with disabled extensions */
ext_msr = current-thread.regs-msr;
- /* XXX we get called with irq disabled - change that! */
- local_irq_enable();
-
/* Preload FPU if it's enabled */
if (vcpu-arch.shared-msr MSR_FP)
kvmppc_handle_ext(vcpu, BOOK3S_INTERRUPT_FP_UNAVAIL, MSR_FP);
- ret = __kvmppc_vcpu_entry(kvm_run, vcpu);
+ kvm_guest_enter();
kvm_guest_enter should run with interrupts disabled.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/13] kvm/powerpc: Move guest enter/exit down into subarch-specific code
On Tue, May 17, 2011 at 03:05:12PM -0300, Marcelo Tosatti wrote: - ret = __kvmppc_vcpu_entry(kvm_run, vcpu); + kvm_guest_enter(); kvm_guest_enter should run with interrupts disabled. Its fine, please ignore message. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
* James Morris jmor...@namei.org wrote: On Tue, 17 May 2011, Ingo Molnar wrote: I'm not sure i get your point. Your example was not complete as described. After an apparently simple specification, you've since added several qualifiers and assumptions, [...] I havent added any qualifiers really (i added examples/description), the opt-in method i mentioned in my first mail should be pretty robust: | Firstly, using the filter code i deny the various link creation syscalls so | that sandboxed code cannot escape for example by creating a symlink to | outside the permitted VFS namespace. (Note: we opt-in to syscalls, that way | new syscalls added by new kernels are denied by defalt. The current symlink | creation syscalls are not opted in to.) [...] and I still doubt that it's complete. I could too claim that i doubt that the SELinux kernel implementation is secure! So how about we both come up with specific examples about how it's not secure, instead of going down the fear-uncertainty-and-doubt road? ;-) A higher level goal would look like Allow a sandbox app access only to approved resources, to contain the effects of flaws in the app, or similar. I see what you mean. I really think that restricting sandboxed code to only open files within a given VFS namespace boundary is the most useful highlevel description here - which is really a subset of a allow a sandbox app access only to an easily approved set of files highlevel concept. There's no to contain ... bit here: *all* of the sandboxed app code is untrusted, so there's no 'remote attacker' and we do not limit our threat to flaws in the app. We want to contain apps to within a small subset of Linux functionality, and we want to do that within regular apps (without having to be superuser), full stop. Note that this includes a threat model (remote attacker taking control of the app) and a general and fully stated strategy for dealing with it. Attacker does not have to be remote - most sandboxing concepts protect against locally installed plugins/apps/applets. In sandboxing the whole app is considered untrusted - not just some flaw in it, abused remotely. From there, you can start to analyze how to implement the goal, at which point you'd start thinking about configuration, assumptions, filesystem access, namespaces, indirect access (e.g. via sockets, rpc, ipc, shared memory, invocation). Sandboxed code generally does not have access to anything fancy like that - if it is added then all possible side effects have to be examined. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: book to learn ppc assembly and architecture
Hi, On Mon, May 16, 2011 at 6:38 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote: what is the best book to learn assembly and architecture . Assuming you have a powerpc compiler available you can use the -S option to produce assembly listings. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame
On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote: Ben, Recent 2.6.39-rc kernels behave strangely on the Freescale dual core mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot sequence after mpic: requesting IPIs... When the system comes up, only one core shows in /proc/cpuinfo. Later on, lots of messages appear like the following: INFO: task ksoftirqd/1:9 blocked for more than 120 seconds. I bisected [1] the problem to: commit c56e58537d504706954a06570b4034c04e5b7500 Author: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Tue Mar 8 14:40:04 2011 +1100 powerpc/smp: Create idle threads on demand and properly reset them I don't see from that commit what had gone wrong. Perhaps you can help resolve this? Hrm, odd. Kumar, care to have a look ? That's what happens when you don't get me HW to test with :-) Cheers, Ben. Thanks, Richard 1. I had to patch commit e5462d16 by hand when bisecting, which is a fixup for commit fa3f82c8 and not yet merged in c56e5853. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/13] powerpc/e500: Save SPEFCSR in flush_spe_to_thread()
From: yu liu yu@freescale.com giveup_spe() saves the SPE state which is protected by MSR[SPE]. However, modifying SPEFSCR does not trap when MSR[SPE]=0. And since SPEFSCR is already saved/restored in _switch(), not all the callers want to save SPEFSCR again. Thus, saving SPEFSCR should not belong to giveup_spe(). This patch moves SPEFSCR saving to flush_spe_to_thread(), and cleans up the caller that needs to save SPEFSCR accordingly. Signed-off-by: Liu Yu yu@freescale.com Signed-off-by: Scott Wood scottw...@freescale.com --- This is a resending of http://patchwork.ozlabs.org/patch/88677/ Kumar, please ack to go via kvm. This is holding up the rest of the SPE patches, which in turn are holding up the MMU patches due to both touching the MSR update code. arch/powerpc/kernel/head_fsl_booke.S |2 -- arch/powerpc/kernel/process.c|1 + arch/powerpc/kernel/traps.c |5 + 3 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 5ecf54c..aede4f8 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -792,8 +792,6 @@ _GLOBAL(giveup_spe) evmwumiaa evr6, evr6, evr6 /* evr6 - ACC = 0 * 0 + ACC */ li r4,THREAD_ACC evstddx evr6, r4, r3/* save off accumulator */ - mfspr r6,SPRN_SPEFSCR - stw r6,THREAD_SPEFSCR(r3) /* save spefscr register value */ beq 1f lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5) lis r3,MSR_SPE@h diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index f74f355..138e7dd 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -213,6 +213,7 @@ void flush_spe_to_thread(struct task_struct *tsk) #ifdef CONFIG_SMP BUG_ON(tsk != current); #endif + tsk-thread.spefscr = mfspr(SPRN_SPEFSCR); giveup_spe(tsk); } preempt_enable(); diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c index 5ddb801..742a0fb 100644 --- a/arch/powerpc/kernel/traps.c +++ b/arch/powerpc/kernel/traps.c @@ -1356,10 +1356,7 @@ void SPEFloatingPointException(struct pt_regs *regs) int code = 0; int err; - preempt_disable(); - if (regs-msr MSR_SPE) - giveup_spe(current); - preempt_enable(); + flush_spe_to_thread(current); spefscr = current-thread.spefscr; fpexc_mode = current-thread.fpexc_mode; -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 02/13] powerpc/e500: SPE register saving: take arbitrary struct offset
Previously, these macros hardcoded THREAD_EVR0 as the base of the save area, relative to the base register passed. This base offset is now passed as a separate macro parameter, allowing reuse with other SPE save areas, such as used by KVM. Signed-off-by: Scott Wood scottw...@freescale.com --- This is a resending of http://www.spinics.net/lists/kvm-ppc/msg02672.html Kumar, please ack to go via kvm. arch/powerpc/include/asm/ppc_asm.h | 28 arch/powerpc/kernel/head_fsl_booke.S |6 +++--- 2 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index 9821006..ba0cd33 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -150,18 +150,22 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR) #define REST_16VSRSU(n,b,base) REST_8VSRSU(n,b,base); REST_8VSRSU(n+8,b,base) #define REST_32VSRSU(n,b,base) REST_16VSRSU(n,b,base); REST_16VSRSU(n+16,b,base) -#define SAVE_EVR(n,s,base) evmergehi s,s,n; stw s,THREAD_EVR0+4*(n)(base) -#define SAVE_2EVRS(n,s,base) SAVE_EVR(n,s,base); SAVE_EVR(n+1,s,base) -#define SAVE_4EVRS(n,s,base) SAVE_2EVRS(n,s,base); SAVE_2EVRS(n+2,s,base) -#define SAVE_8EVRS(n,s,base) SAVE_4EVRS(n,s,base); SAVE_4EVRS(n+4,s,base) -#define SAVE_16EVRS(n,s,base) SAVE_8EVRS(n,s,base); SAVE_8EVRS(n+8,s,base) -#define SAVE_32EVRS(n,s,base) SAVE_16EVRS(n,s,base); SAVE_16EVRS(n+16,s,base) -#define REST_EVR(n,s,base) lwz s,THREAD_EVR0+4*(n)(base); evmergelo n,s,n -#define REST_2EVRS(n,s,base) REST_EVR(n,s,base); REST_EVR(n+1,s,base) -#define REST_4EVRS(n,s,base) REST_2EVRS(n,s,base); REST_2EVRS(n+2,s,base) -#define REST_8EVRS(n,s,base) REST_4EVRS(n,s,base); REST_4EVRS(n+4,s,base) -#define REST_16EVRS(n,s,base) REST_8EVRS(n,s,base); REST_8EVRS(n+8,s,base) -#define REST_32EVRS(n,s,base) REST_16EVRS(n,s,base); REST_16EVRS(n+16,s,base) +/* + * b = base register for addressing, o = base offset from register of 1st EVR + * n = first EVR, s = scratch + */ +#define SAVE_EVR(n,s,b,o) evmergehi s,s,n; stw s,o+4*(n)(b) +#define SAVE_2EVRS(n,s,b,o)SAVE_EVR(n,s,b,o); SAVE_EVR(n+1,s,b,o) +#define SAVE_4EVRS(n,s,b,o)SAVE_2EVRS(n,s,b,o); SAVE_2EVRS(n+2,s,b,o) +#define SAVE_8EVRS(n,s,b,o)SAVE_4EVRS(n,s,b,o); SAVE_4EVRS(n+4,s,b,o) +#define SAVE_16EVRS(n,s,b,o) SAVE_8EVRS(n,s,b,o); SAVE_8EVRS(n+8,s,b,o) +#define SAVE_32EVRS(n,s,b,o) SAVE_16EVRS(n,s,b,o); SAVE_16EVRS(n+16,s,b,o) +#define REST_EVR(n,s,b,o) lwz s,o+4*(n)(b); evmergelo n,s,n +#define REST_2EVRS(n,s,b,o)REST_EVR(n,s,b,o); REST_EVR(n+1,s,b,o) +#define REST_4EVRS(n,s,b,o)REST_2EVRS(n,s,b,o); REST_2EVRS(n+2,s,b,o) +#define REST_8EVRS(n,s,b,o)REST_4EVRS(n,s,b,o); REST_4EVRS(n+4,s,b,o) +#define REST_16EVRS(n,s,b,o) REST_8EVRS(n,s,b,o); REST_8EVRS(n+8,s,b,o) +#define REST_32EVRS(n,s,b,o) REST_16EVRS(n,s,b,o); REST_16EVRS(n+16,s,b,o) /* Macros to adjust thread priority for hardware multithreading */ #define HMT_VERY_LOW or 31,31,31# very low priority diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index aede4f8..fe37dd0 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -656,7 +656,7 @@ load_up_spe: cmpi0,r4,0 beq 1f addir4,r4,THREAD/* want THREAD of last_task_used_spe */ - SAVE_32EVRS(0,r10,r4) + SAVE_32EVRS(0,r10,r4,THREAD_EVR0) evxor evr10, evr10, evr10 /* clear out evr10 */ evmwumiaa evr10, evr10, evr10 /* evr10 - ACC = 0 * 0 + ACC */ li r5,THREAD_ACC @@ -676,7 +676,7 @@ load_up_spe: stw r4,THREAD_USED_SPE(r5) evlddx evr4,r10,r5 evmra evr4,evr4 - REST_32EVRS(0,r10,r5) + REST_32EVRS(0,r10,r5,THREAD_EVR0) #ifndef CONFIG_SMP subir4,r5,THREAD stw r4,last_task_used_spe@l(r3) @@ -787,7 +787,7 @@ _GLOBAL(giveup_spe) addir3,r3,THREAD/* want THREAD of task */ lwz r5,PT_REGS(r3) cmpi0,r5,0 - SAVE_32EVRS(0, r4, r3) + SAVE_32EVRS(0, r4, r3, THREAD_EVR0) evxor evr6, evr6, evr6/* clear out evr6 */ evmwumiaa evr6, evr6, evr6 /* evr6 - ACC = 0 * 0 + ACC */ li r4,THREAD_ACC -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
On Tue, 2011-05-17 at 22:15 -0600, Matthew Wilcox wrote:
On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
The following code seems to be there in
/usr/src/linux/arch/x86/include/asm/io.h.
This is not going to work.
static inline void writeq(__u64 val, volatile void __iomem *addr)
{
writel(val, addr);
writel(val 32, addr+4);
}
So with this code turned on in the kernel, there is going to be race
condition
where multiple cpus can be writing to the request descriptor at the same
time.
Meaning this could happen:
(A) CPU A doest 32bit write
(B) CPU B does 32 bit write
(C) CPU A does 32 bit write
(D) CPU B does 32 bit write
We need the 64 bit completed in one access pci memory write, else spin
lock is required.
Since it's going to be difficult to know which writeq was implemented in
the kernel,
the driver is going to have to always acquire a spin lock each time we do
64bit write.
Cc: sta...@kernle.org
Signed-off-by: Kashyap Desai kashyap.de...@lsi.com
---
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index efa0255..5778334 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1558,7 +1558,6 @@ mpt2sas_base_free_smid(struct MPT2SAS_ADAPTER *ioc,
u16 smid)
* care of 32 bit environment where its not quarenteed to send the
entire word
* in one transfer.
*/
-#ifndef writeq
Why not make this #ifndef CONFIG_64BIT? You know that all 64 bit
systems have writeq implemented correctly; you suspect 32 bit systems
don't.
James
James, This issue was observed on PPC64 system. So what you have suggested
will not solve this issue.
If we are sure that writeq() is atomic across all architecture, we can use
it safely. As we have seen issue on ppc64, we are not confident to use
writeq call.
So have you told the powerpc people that they have a broken writeq?
I'm just in the process of finding them now on IRC so I can demand an
explanation: this is a really serious API problem because writeq is
supposed to be atomic on 64 bit.
And why do you obfuscate your report by talking about i386 when it's
really about powerpc64?
James
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
The following code seems to be there in
/usr/src/linux/arch/x86/include/asm/io.h.
This is not going to work.
static inline void writeq(__u64 val, volatile void __iomem *addr)
{
writel(val, addr);
writel(val 32, addr+4);
}
So with this code turned on in the kernel, there is going to be race
condition
where multiple cpus can be writing to the request descriptor at the same
time.
Meaning this could happen:
(A) CPU A doest 32bit write
(B) CPU B does 32 bit write
(C) CPU A does 32 bit write
(D) CPU B does 32 bit write
We need the 64 bit completed in one access pci memory write, else spin lock
is required.
Since it's going to be difficult to know which writeq was implemented in
the kernel,
the driver is going to have to always acquire a spin lock each time we do
64bit write.
Cc: sta...@kernle.org
Signed-off-by: Kashyap Desai kashyap.de...@lsi.com
---
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index efa0255..5778334 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1558,7 +1558,6 @@ mpt2sas_base_free_smid(struct MPT2SAS_ADAPTER *ioc,
u16 smid)
* care of 32 bit environment where its not quarenteed to send the entire
word
* in one transfer.
*/
-#ifndef writeq
Why not make this #ifndef CONFIG_64BIT? You know that all 64 bit
systems have writeq implemented correctly; you suspect 32 bit systems
don't.
James
James, This issue was observed on PPC64 system. So what you have suggested
will not solve this issue.
If we are sure that writeq() is atomic across all architecture, we can use it
safely. As we have seen issue on ppc64, we are not confident to use
writeq call.
So have you told the powerpc people that they have a broken writeq?
And why do you obfuscate your report by talking about i386 when it's
really about powerpc64?
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
Cc: sta...@kernle.org Signed-off-by: Kashyap Desai kashyap.de...@lsi.com --- diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c index efa0255..5778334 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.c +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c @@ -1558,7 +1558,6 @@ mpt2sas_base_free_smid(struct MPT2SAS_ADAPTER *ioc, u16 smid) * care of 32 bit environment where its not quarenteed to send the entire word * in one transfer. */ -#ifndef writeq Why not make this #ifndef CONFIG_64BIT? You know that all 64 bit systems have writeq implemented correctly; you suspect 32 bit systems don't. James James, This issue was observed on PPC64 system. So what you have suggested will not solve this issue. If we are sure that writeq() is atomic across all architecture, we can use it safely. As we have seen issue on ppc64, we are not confident to use writeq call. So have you told the powerpc people that they have a broken writeq? And why do you obfuscate your report by talking about i386 when it's really about powerpc64? Well, our writeq isn't supposed to be broken :-) It's defined as an std instruction (and ld for readq) so that's perfectly atomic ... provided your access is aligned. Is it ? Cheers, Be ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
