On Mon, Jun 29, 2015 at 12:44:27PM +0200, Andrew Jones wrote:
> On Mon, Jun 29, 2015 at 12:28:32PM +0200, Christoffer Dall wrote:
> > On Thu, Jun 25, 2015 at 06:12:18PM +0200, Andrew Jones wrote:
> > > spinlock torture tests made it clear that checking mmu_enabled()
> > > every time we call spin_lo
On Mon, Jun 29, 2015 at 12:28:32PM +0200, Christoffer Dall wrote:
> On Thu, Jun 25, 2015 at 06:12:18PM +0200, Andrew Jones wrote:
> > spinlock torture tests made it clear that checking mmu_enabled()
> > every time we call spin_lock is a bad idea.
>
> why a bad idea? Does it break, is it slow?
Ju
On Thu, Jun 25, 2015 at 06:12:18PM +0200, Andrew Jones wrote:
> spinlock torture tests made it clear that checking mmu_enabled()
> every time we call spin_lock is a bad idea.
why a bad idea? Does it break, is it slow?
> As most tests will
> want the MMU enabled the entire time, then just hard co
On Thu, Jun 25, 2015 at 06:23:48PM +0200, Paolo Bonzini wrote:
>
>
> On 25/06/2015 18:12, Andrew Jones wrote:
> > spinlock torture tests made it clear that checking mmu_enabled()
> > every time we call spin_lock is a bad idea. As most tests will
> > want the MMU enabled the entire time, then just
On 25/06/2015 18:12, Andrew Jones wrote:
> spinlock torture tests made it clear that checking mmu_enabled()
> every time we call spin_lock is a bad idea. As most tests will
> want the MMU enabled the entire time, then just hard code
> mmu_enabled() to true. Tests that want to play with the MMU ca
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then just hard code
mmu_enabled() to true. Tests that want to play with the MMU can
be compiled with CONFIG_MAY_DISABLE_MMU to get th
