On Wed, 2013-05-08 at 19:35 -0500, Scott Wood wrote:
Sigh, and then there's this:
#ifdef CONFIG_PPC64
/* lazy EE magic */
hard_irq_disable();
if (lazy_irq_pending()) {
/* Got an interrupt in between, try again */
On Wed, 2013-05-08 at 19:35 -0500, Scott Wood wrote:
Sigh, and then there's this:
#ifdef CONFIG_PPC64
/* lazy EE magic */
hard_irq_disable();
if (lazy_irq_pending()) {
/* Got an interrupt in between, try again */
On 05/07/2013 11:32 AM, Scott Wood wrote:
booke64 was not maintaing consistent lazy ee state when exiting the
One typo ;-)
s/maintaing/maintaining
guest, leading to warnings and worse.
booke32 was less affected due to the absence of lazy ee, but it was
still feeding bad information into
On Tue, 2013-05-07 at 13:58 -0500, Scott Wood wrote:
This will have to wait until book3s_hv disables interrupts as well. If
this does eventually happen, then the
local_irq_enable()/kvmppc_lazy_ee_enable() should also probably go into
kvmppc_prepare_to_enter() -- though that could cause
On Tue, 2013-05-07 at 13:58 -0500, Scott Wood wrote:
This will have to wait until book3s_hv disables interrupts as well. If
this does eventually happen, then the
local_irq_enable()/kvmppc_lazy_ee_enable() should also probably go into
kvmppc_prepare_to_enter() -- though that could cause
booke64 was not maintaing consistent lazy ee state when exiting the
guest, leading to warnings and worse.
booke32 was less affected due to the absence of lazy ee, but it was
still feeding bad information into trace_hardirqs_off/on -- we don't
want guest execution to be seen as an IRQs off
On Mon, 2013-05-06 at 22:32 -0500, Scott Wood wrote:
+ hard_irq_disable();
+ trace_hardirqs_off();
I still think hard_irq_disable() should be fixed to do the right thing
here :-)
I'll do that standalone patch here and give it a spin.
Cheers,
Ben.
--
To unsubscribe from this
booke64 was not maintaing consistent lazy ee state when exiting the
guest, leading to warnings and worse.
booke32 was less affected due to the absence of lazy ee, but it was
still feeding bad information into trace_hardirqs_off/on -- we don't
want guest execution to be seen as an IRQs off
On Mon, 2013-05-06 at 22:32 -0500, Scott Wood wrote:
+ hard_irq_disable();
+ trace_hardirqs_off();
I still think hard_irq_disable() should be fixed to do the right thing
here :-)
I'll do that standalone patch here and give it a spin.
Cheers,
Ben.
--
To unsubscribe from this