Commit e58e263 PPC, KVM, CMA: use general CMA reserved area management
framework in next-20140624 removed arch/powerpc/kvm/book3s_hv_cma.c but
neglected to update the Makefile, thus breaking the build.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
Hi Andrew,
This is in your akpm
On Tue, Jun 24, 2014 at 04:36:47PM +1000, Michael Ellerman wrote:
Commit e58e263 PPC, KVM, CMA: use general CMA reserved area management
framework in next-20140624 removed arch/powerpc/kvm/book3s_hv_cma.c but
neglected to update the Makefile, thus breaking the build.
Signed-off-by: Michael
On Tue, 2014-06-24 at 15:51 +0900, Joonsoo Kim wrote:
On Tue, Jun 24, 2014 at 04:36:47PM +1000, Michael Ellerman wrote:
Commit e58e263 PPC, KVM, CMA: use general CMA reserved area management
framework in next-20140624 removed arch/powerpc/kvm/book3s_hv_cma.c but
neglected to update
I've observed kvmclock being marked as unstable on a modern
single-socket system with a stable TSC and qemu-1.6.2 or qemu-2.0.0.
The culprit was failure in TSC matching because of overflow of
kvm_arch::nr_vcpus_matched_tsc in case there were multiple TSC writes
in a single synchronization cycle.
On Wed, Jun 18, 2014 at 01:51:44PM -0700, Andrew Morton wrote:
On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote:
v2:
- Although this patchset looks very different with v1, the end result,
that is, mm/cma.c is same with v1's one. So I carry Ack to patch
On Mon, Jun 23, 2014 at 1:41 PM, Jidong Xiao jidong.x...@gmail.com wrote:
Hi, All,
I am using a virtual machine in a cloud environment, which means I am
in control of the Guest OS, but have no access to the Host OS. Is
there a simple way to know whether or not the vPMU is enabled or
On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote:
On 17.06.14 13:39, Eric Auger wrote:
Hello,
I have a question related to KVM_IRQFD and KVM_SET_GSI_ROUTING ioctl
relationship.
When reading the KVM API documentation I do not understand there is any
dependency between
https://bugzilla.kernel.org/show_bug.cgi?id=67751
--- Comment #5 from Kashyap Chamarthy kashyap...@gmail.com ---
I just saw this again when I attempt to restart OpenvSwitch with Kernel --
3.16.0-0.rc1.git1.1.fc21.x86_64
-
[ 9695.079715]
[ 9695.080492]
Hi,
I'm currently trying to make vhost-net work on ARM cortexA15 Arndale board.
As irqfd is not yet upstream, I've used irqfd and irq routing patches recently
posted on kvmarm list.
So far I can properly generate irqs to the guest using vgic and irq-routing ,
but as far as I can see virtio
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually fix anything except
the overhead on big endian
On Tue, Jun 17, 2014 at 07:23:44PM -0400, Konrad Rzeszutek Wilk wrote:
Actually in my v11 patch, I subdivided the slowpath into a slowpath for
the pending code and slowerpath for actual queuing. Perhaps, we could
use quickpath and slowpath instead. Anyway, it is a minor detail that we
On Tue, Jun 17, 2014 at 05:07:29PM -0400, Konrad Rzeszutek Wilk wrote:
We are trying to make the fastpath as simple as possible as it may be
inlined. The complexity of the queue spinlock is in the slowpath.
Sure, but then it shouldn't be called slowpath anymore as it is not
slow.
Its
On Wed, May 07, 2014 at 03:55:57PM +0100, Christoffer Dall wrote:
On Wed, May 07, 2014 at 10:00:21AM +0100, Marc Zyngier wrote:
On Tue, May 06 2014 at 7:04:48 pm BST, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Tue, Mar 25, 2014 at 05:08:14PM -0500, Kim Phillips wrote:
Use
On 24.06.14 11:47, Paul Mackerras wrote:
On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote:
On 17.06.14 13:39, Eric Auger wrote:
Hello,
I have a question related to KVM_IRQFD and KVM_SET_GSI_ROUTING ioctl
relationship.
When reading the KVM API documentation I do not understand
On 24/06/14 11:23, Will Deacon wrote:
On Wed, May 07, 2014 at 03:55:57PM +0100, Christoffer Dall wrote:
On Wed, May 07, 2014 at 10:00:21AM +0100, Marc Zyngier wrote:
On Tue, May 06 2014 at 7:04:48 pm BST, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Tue, Mar 25, 2014 at 05:08:14PM
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually
On Wed, Jun 18, 2014 at 01:37:45PM +0200, Paolo Bonzini wrote:
However, I *do* agree with you that it's simpler to just squash this patch
into 01/11.
So I explicitly broke out these optimizations into separate patches so
that we can see them independently and agree they're idempotent wrt the
On 18.06.14 09:15, Mihai Caraman wrote:
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On
For code that doesn't live in modules we can just branch to the real function
names, giving us compatibility with ABIv1 and ABIv2.
Do this for the compiled-in code of HV KVM.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 16
1 file
On 18.06.14 17:45, Mihai Caraman wrote:
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe()
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On
From: Alexey Kardashevskiy
...
So IMHO we should either create new, generic iowrite helpers that don't
do any endian swapping at all or do iowrite32(cpu_to_le32(val)) calls.
I'm one of those people for whom iowrite32(le32_to_cpu(val)) makes sense
I do not understand why @val is
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey
On 06/24/2014 12:40 PM, Alexander Graf wrote:
On 24.06.14 11:47, Paul Mackerras wrote:
On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote:
On 17.06.14 13:39, Eric Auger wrote:
Hello,
I have a question related to KVM_IRQFD and KVM_SET_GSI_ROUTING ioctl
relationship.
When
On 6/23/2014 10:09 PM, Oscar Garcia wrote:
Hello,
I am planning to study a phd for the next year, and I would like to
spend part on my time studying KVM code in order to suggest new
improvements.
I know that this mail list is used by experts related to KVM, I would
like to ask you, what
On 24.06.14 17:05, Eric Auger wrote:
On 06/24/2014 12:40 PM, Alexander Graf wrote:
On 24.06.14 11:47, Paul Mackerras wrote:
On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote:
On 17.06.14 13:39, Eric Auger wrote:
Hello,
I have a question related to KVM_IRQFD and
3.15-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit 7006e2dfda9adfa40251093604db76d7e44263b3 upstream.
Each MIPS KVM guest has its own copy of the KVM exception vector. This
contains the TLB refill
On 06/20/2014 06:15 AM, David Marchand wrote:
Add some notes on the parts needed to use ivshmem devices: more specifically,
explain the purpose of an ivshmem server and the basic concept to use the
ivshmem devices in guests.
Signed-off-by: David Marchand david.march...@6wind.com
---
On 06/24/2014 05:47 PM, Alexander Graf wrote:
On 24.06.14 17:05, Eric Auger wrote:
On 06/24/2014 12:40 PM, Alexander Graf wrote:
On 24.06.14 11:47, Paul Mackerras wrote:
On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote:
On 17.06.14 13:39, Eric Auger wrote:
Hello,
I have a
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit 7006e2dfda9adfa40251093604db76d7e44263b3 upstream.
Each MIPS KVM guest has its own copy of the KVM exception vector. This
contains the TLB refill
On 06/25/2014 12:43 AM, Alex Williamson wrote:
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM,
On Sun, Jun 22, 2014 at 09:02:25PM +0200, Andi Kleen wrote:
First, it's not sufficient to pin the debug store area, you also
have to pin the guest page tables that are used to map the debug
store. But even if you do that, as soon as the guest fork()s, it
will create a new pgd which the
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit 7006e2dfda9adfa40251093604db76d7e44263b3 upstream.
Each MIPS KVM guest has its own copy of the KVM exception vector. This
contains the TLB refill
The patches are pretty straightforward.
Changes:
v3 - v2:
o In patch #2, change the use of kvm_[err|info|debug].
o In patch #3, add err removal in kvm_arch_commit_memory_region().
o In patch #3, revert the changes to kvm_arch_vm_ioctl().
o In patch #7, drop the merge of kvm_arch_vcpu_free() and
From: Deng-Cheng Zhu dengcheng@imgtec.com
The commpage is allocated using kzalloc(), so there's no need of cleaning
the memory of the kvm_mips_commpage struct and its internal mips_coproc.
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
arch/mips/kvm/commpage.c | 3 ---
1 file
From: Deng-Cheng Zhu dengcheng@imgtec.com
The keyword volatile for idx in the TLB functions is unnecessary.
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
arch/mips/kvm/kvm_tlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kvm/kvm_tlb.c
From: Deng-Cheng Zhu dengcheng@imgtec.com
At TLB initialization, the commpage TLB entry is reserved on top of the
existing WIRED entries (the number not necessarily be 0).
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
arch/mips/kvm/mips.c | 2 +-
1 file changed, 1 insertion(+),
From: James Hogan james.ho...@imgtec.com
It's impossible to fall into the error handling of the TLB index after
being masked by (KVM_MIPS_GUEST_TLB_SIZE - 1). Remove the dead code.
Signed-off-by: James Hogan james.ho...@imgtec.com
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
From: Deng-Cheng Zhu dengcheng@imgtec.com
kvm_arch_vcpu_free() is called in 2 code paths:
1) kvm_vm_ioctl()
kvm_vm_ioctl_create_vcpu()
kvm_arch_vcpu_destroy()
kvm_arch_vcpu_free()
2) kvm_put_kvm()
kvm_destroy_vm()
kvm_arch_destroy_vm()
From: Deng-Cheng Zhu dengcheng@imgtec.com
Replace printks with kvm_[err|info|debug].
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
Changes:
v3 - v2:
o Change the use of kvm_[err|info|debug].
arch/mips/kvm/kvm_mips.c | 23 -
arch/mips/kvm/kvm_mips_emul.c | 107
From: Deng-Cheng Zhu dengcheng@imgtec.com
Since all the files are in arch/mips/kvm/, there's no need of the prefixes
kvm_ and kvm_mips_.
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
arch/mips/kvm/Makefile| 8
arch/mips/kvm/{kvm_cb.c =
From: Deng-Cheng Zhu dengcheng@imgtec.com
No logic changes inside.
Signed-off-by: Deng-Cheng Zhu dengcheng@imgtec.com
---
Changes:
v3 - v2:
o Add err removal in kvm_arch_commit_memory_region().
o Revert the changes to kvm_arch_vm_ioctl().
arch/mips/include/asm/kvm_host.h | 2 +-
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of instructions to check
whether it's necessary to trap out from it (like mtmsr, no need to trap if
On 06/19/2014 04:21 AM, Marc Zyngier wrote:
The GIC CPU interface is always 4k aligned. If the host is using
64k pages, it is critical to place the guest's GICC interface at the
same relative alignment as the host's GICV. Failure to do so results
in an impossibility for the guest to deal with
Il 24/06/2014 10:33, Jidong Xiao ha scritto:
I think I have figured out this. According to this patch (as well as
the Intel SDM manual), it looks like pmu is exposed via the cpuid leaf
0xah.
https://github.com/torvalds/linux/commit/a6c06ed1a60aff77b27ba558c315c3fed4e35565
Therefore, in the
On Tue, 2014-06-24 at 12:41 +0200, Alexander Graf wrote:
Is there actually any difference in generated code with this patch
applied and without? I would hope that iowrite..() is inlined and
cancels out the cpu_to_le..() calls that are also inlined?
No, the former uses byteswapping asm, the
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
I do not understand why @val is considered LE here and need to be
converted
to CPU. Really. I truly believe it should be cpu_to_le32().
No. Both are slightly wrong semantically but le32_to_cpu() is less
wrong :-)
iowrite32
On 24 June 2014 20:28, Joel Schopp joel.sch...@amd.com wrote:
On 06/19/2014 04:21 AM, Marc Zyngier wrote:
The GIC CPU interface is always 4k aligned. If the host is using
64k pages, it is critical to place the guest's GICC interface at the
same relative alignment as the host's GICV. Failure
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of instructions to check
whether it's necessary to trap out from
Hi Deng-Cheng,
On Tuesday 24 June 2014 10:31:02 Deng-Cheng Zhu wrote:
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index cd5e4f5..821e7e8 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
-#define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x),
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of
On 25.06.14 01:15, Scott Wood wrote:
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few
On Wed, 2014-06-25 at 01:40 +0200, Alexander Graf wrote:
On 25.06.14 01:15, Scott Wood wrote:
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
The timer interrupt works, but I'm not fully convinced that it's a good
idea for things like MC
https://bugzilla.kernel.org/show_bug.cgi?id=42980
xerofo...@gmail.com changed:
What|Removed |Added
CC||xerofo...@gmail.com
--- Comment #22
On 06/25/2014 07:54 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
I do not understand why @val is considered LE here and need to be
converted
to CPU. Really. I truly believe it should be cpu_to_le32().
No. Both are slightly wrong
On Tue, Jun 24, 2014 at 4:38 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/06/2014 10:33, Jidong Xiao ha scritto:
I think I have figured out this. According to this patch (as well as
the Intel SDM manual), it looks like pmu is exposed via the cpuid leaf
0xah.
On 06/23/2014 10:14 AM, Gavin Shan wrote:
The patch implements one OPAL firmware sysfs file to support PCI error
injection: /sys/firmware/opal/errinjct, which will be used like the
way described as follows.
According to PAPR spec, there are 3 RTAS calls related to error injection:
Is it reasonable to do error injection with CONFIG_IOMMU_API ?
That means if use default config(CONFIG_IOMMU_API = n), we can not do
error injection to pci devices?
Well we can't pass them through either so ...
In any case, this is not a priority. First we need to implement a solid
error
On 06/24/2014 02:36 PM, Benjamin Herrenschmidt wrote:
Is it reasonable to do error injection with CONFIG_IOMMU_API ?
That means if use default config(CONFIG_IOMMU_API = n), we can not do
error injection to pci devices?
Well we can't pass them through either so ...
In any case, this is not a
On Tue, 2014-06-24 at 14:57 +0800, Mike Qiu wrote:
Is that mean *host* side error injection should base on
CONFIG_IOMMU_API ? If it is just host side(no guest, no pass through),
can't we do error inject?
Maybe I misunderstand :)
Ah no, make different patches, we don't want to use IOMMU
On Wed, Jun 18, 2014 at 01:51:44PM -0700, Andrew Morton wrote:
On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote:
v2:
- Although this patchset looks very different with v1, the end result,
that is, mm/cma.c is same with v1's one. So I carry Ack to patch
On 18.06.14 09:15, Mihai Caraman wrote:
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping
For code that doesn't live in modules we can just branch to the real function
names, giving us compatibility with ABIv1 and ABIv2.
Do this for the compiled-in code of HV KVM.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 16
1 file
On 18.06.14 17:45, Mihai Caraman wrote:
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe()
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of instructions to check
whether it's necessary to trap out from it (like mtmsr, no need to trap if
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of instructions to check
whether it's necessary to trap out from
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few instructions with longer streams of
On 25.06.14 01:15, Scott Wood wrote:
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
On Sun, 2014-06-22 at 23:23 +0200, Alexander Graf wrote:
Howdy,
Ben reminded me a while back that we have a nasty race in our KVM PV code.
We replace a few
On Tue, Jun 24, 2014 at 05:00:52PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-24 at 14:57 +0800, Mike Qiu wrote:
Is that mean *host* side error injection should base on
CONFIG_IOMMU_API ? If it is just host side(no guest, no pass through),
can't we do error inject?
Maybe I
On Mon, Jun 23, 2014 at 04:36:44PM +1000, Michael Neuling wrote:
On Mon, 2014-06-23 at 12:14 +1000, Gavin Shan wrote:
The patch implements one OPAL firmware sysfs file to support PCI error
injection: /sys/firmware/opal/errinjct, which will be used like the
way described as follows.
According
On Wed, 2014-06-25 at 01:40 +0200, Alexander Graf wrote:
On 25.06.14 01:15, Scott Wood wrote:
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
The timer interrupt works, but I'm not fully convinced that it's a good
idea for things like MC
On 06/25/2014 08:03 AM, Gavin Shan wrote:
On Tue, Jun 24, 2014 at 05:00:52PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-24 at 14:57 +0800, Mike Qiu wrote:
Is that mean *host* side error injection should base on
CONFIG_IOMMU_API ? If it is just host side(no guest, no pass through),
On Wed, 2014-06-25 at 11:05 +0800, Mike Qiu wrote:
Here maybe /sys/kernel/debug/powerpc/errinjct is better, because
it
will supply PCI_domain_nr in parameters, so no need supply errinjct
for each PCI domain.
Another reason is error inject not only for PCI(in future), so better
not in
Eeh sysfs entry created must be after EEH_ENABLED been set
in eeh_subsystem_flags.
In PowerNV platform, it try to create sysfs entry before
EEH_ENABLED been set, when boot up. So nothing will be
created for eeh in sysfs.
Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
---
On Tue, Jun 24, 2014 at 11:32:07PM -0400, Mike Qiu wrote:
[ cc Richard ]
Eeh sysfs entry created must be after EEH_ENABLED been set
in eeh_subsystem_flags.
In PowerNV platform, it try to create sysfs entry before
EEH_ENABLED been set, when boot up. So nothing will be
created for eeh in sysfs.
80 matches
Mail list logo
