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 IO
On Wed, Jun 18, 2014 at 01:51:44PM -0700, Andrew Morton wrote:
> On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim 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 6-7.
> >
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 last_
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
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 16
1 file changed, 8 inser
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() caller
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
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 it
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
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 inst
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?
>>
>> Ma
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.
>>
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 l
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),
c
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
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
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 3
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 sys
On Wed, Jun 25, 2014 at 03:33:12PM +1000, Gavin Shan wrote:
>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_ENABL
On Wed, Jun 25, 2014 at 02:23:53PM +0800, Wei Yang wrote:
>On Wed, Jun 25, 2014 at 03:33:12PM +1000, Gavin Shan wrote:
>>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.
>>>
>>>I
18 matches
Mail list logo
