On 07/16/2013 01:27 AM, Scott Wood wrote:
On 07/14/2013 09:20:00 PM, tiejun.chen wrote:
On 07/13/2013 07:05 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:
[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consis
On 07/15/2013 10:47 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
What about SOFT_IRQ_DISABLE? This is close to name
hard_irq_disable() :) And
then remove all DISABLE_INTS as well?
Or RECONCILE_IRQ_STATE...
But sounds this doesn't imply this key poin
On 07/14/2013 12:13 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-12 at 12:54 +0800, tiejun.chen wrote:
Is the following fine?
powerpc: to access local paca after hard irq disabled
We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
> What about SOFT_IRQ_DISABLE? This is close to name
> hard_irq_disable() :) And
> then remove all DISABLE_INTS as well?
Or RECONCILE_IRQ_STATE...
Ben.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a m
On 07/13/2013 01:50 AM, Scott Wood wrote:
On 07/11/2013 10:22:28 PM, tiejun.chen wrote:
If so, why not to remove directly hard_irq_disable() inside
kvmppc_handle_exit() by reverting that commit, "kvm/ppc/booke64: Fix lazy ee
handling in kvmppc_handle_exit()"?
Then we can use SOFT_DISABLE_INTS()
On 07/13/2013 07:05 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:
[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being *hard* disabled.
I can sort of see the logic in it, but it's co
On Fri, 2013-07-12 at 12:54 +0800, tiejun.chen wrote:
> Is the following fine?
>
> powerpc: to access local paca after hard irq disabled
>
> We can access paca directly after hard interrupt disabled, and
> this can avoid accessing wrong paca when using get_paca() in
> preempt case.
>
> Signed-of
On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:
>
> [1] SOFT_DISABLE_INTS seems an odd name for something that updates the
> software state to be consistent with interrupts being *hard* disabled.
> I can sort of see the logic in it, but it's confusing when first
> encountered. From th
On 07/12/2013 11:57 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-12 at 10:13 +0800, tiejun.chen wrote:
#define hard_irq_disable()do {\
u8 _was_enabled = get_paca()->soft_enabled; \
Current problem I met is issued from the above line.
__hard_irq_
On Fri, 2013-07-12 at 10:13 +0800, tiejun.chen wrote:
> > #define hard_irq_disable()do {\
> > u8 _was_enabled = get_paca()->soft_enabled; \
>
> Current problem I met is issued from the above line.
>
> > __hard_irq_disable(); \
> >
On 07/12/2013 12:36 AM, Scott Wood wrote:
On 07/11/2013 11:30:41 AM, Alexander Graf wrote:
On 11.07.2013, at 18:18, Scott Wood wrote:
> On 07/11/2013 08:07:30 AM, Alexander Graf wrote:
>> get_paca() warns when we're preemptible. We're only not preemptible when
either preempt is disabled or irq
On 07/12/2013 08:19 AM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-11 at 15:07 +0200, Alexander Graf wrote:
Ok, let me quickly explain the problem.
We are leaving host context, switching slowly into guest context.
During that transition we call get_paca() indirectly (apparently by
another ca
On Thu, 2013-07-11 at 11:18 -0500, Scott Wood wrote:
>
> If we set IRQs as soft-disabled prior to calling hard_irq_disable(),
> then hard_irq_disable() will fail to call trace_hardirqs_off().
Sure because setting them as soft-disabled will have done it.
However by doing so, you also create the
On Thu, 2013-07-11 at 15:07 +0200, Alexander Graf wrote:
> Ok, let me quickly explain the problem.
>
> We are leaving host context, switching slowly into guest context.
> During that transition we call get_paca() indirectly (apparently by
> another call to hard_disable() which sounds bogus, but th
On 11.07.2013, at 14:54, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 14:47 +0200, Alexander Graf wrote:
>>> Yes of course, that's what we call "soft disabled" :-) It's even the
>>> whole point of doing lazy disable...
>>
>> Meh. Of course it's soft_enabled = 1; hard_enabled = 0.
>
> T
On Thu, 2013-07-11 at 14:47 +0200, Alexander Graf wrote:
> > Yes of course, that's what we call "soft disabled" :-) It's even the
> > whole point of doing lazy disable...
>
> Meh. Of course it's soft_enabled = 1; hard_enabled = 0.
That doesn't happen in "normal" C code. It happens under very spec
On 11.07.2013, at 14:28, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-11 at 11:49 +0200, Alexander Graf wrote:
>> Ben, is soft_enabled == 0; hard_enabled == 1 a valid combination that
>> may ever occur?
>
> Yes of course, that's what we call "soft disabled" :-) It's even the
> whole point of
On Thu, 2013-07-11 at 11:49 +0200, Alexander Graf wrote:
> Ben, is soft_enabled == 0; hard_enabled == 1 a valid combination that
> may ever occur?
Yes of course, that's what we call "soft disabled" :-) It's even the
whole point of doing lazy disable...
Ben.
--
To unsubscribe from this list: sen
On 11.07.2013, at 04:48, tiejun.chen wrote:
> On 07/10/2013 05:49 PM, Alexander Graf wrote:
>>
>> On 10.07.2013, at 08:02, Tiejun Chen wrote:
>>
>>> We should ensure the preemption cannot occur while calling get_paca()
>>> insdide hard_irq_disable(), otherwise the paca_struct may be the
>>> wro
On 07/11/2013 03:15 AM, Scott Wood wrote:
On 07/10/2013 01:02:19 AM, Tiejun Chen wrote:
We should ensure the preemption cannot occur while calling get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. And btw, we may update timing stats in this case.
On 07/10/2013 05:49 PM, Alexander Graf wrote:
On 10.07.2013, at 08:02, Tiejun Chen wrote:
We should ensure the preemption cannot occur while calling get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. And btw, we may update timing stats in this cas
On 07/10/2013 01:02:19 AM, Tiejun Chen wrote:
We should ensure the preemption cannot occur while calling get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. And btw, we may update timing stats in this
case.
The soft-ee mechanism depends on accessi
On 10.07.2013, at 08:02, Tiejun Chen wrote:
> We should ensure the preemption cannot occur while calling get_paca()
> insdide hard_irq_disable(), otherwise the paca_struct may be the
> wrong one just after. And btw, we may update timing stats in this case.
>
> Signed-off-by: Tiejun Chen
> ---
>
We should ensure the preemption cannot occur while calling get_paca()
insdide hard_irq_disable(), otherwise the paca_struct may be the
wrong one just after. And btw, we may update timing stats in this case.
Signed-off-by: Tiejun Chen
---
arch/powerpc/kvm/booke.c |2 ++
1 file changed, 2 inse
24 matches
Mail list logo
