All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	marc zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH kvm-unit-tests] arm: fix crash when caches are off
Date: Thu, 30 Oct 2014 16:59:59 +0100	[thread overview]
Message-ID: <20141030155959.GA9562@hawk.usersys.redhat.com> (raw)
In-Reply-To: <20140926075115.GB15736@cbox>

On Fri, Sep 26, 2014 at 09:51:15AM +0200, Christoffer Dall wrote:
> On Tue, Sep 16, 2014 at 08:57:31AM -0400, Andrew Jones wrote:
> > 
> > 
> > ----- Original Message -----
> > > Il 16/09/2014 14:43, Andrew Jones ha scritto:
> > > > I don't think we need to worry about this case. AFAIU, enabling the
> > > > caches for a particular cpu shouldn't require any synchronization.
> > > > So we should be able to do
> > > > 
> > > >     enable caches
> > > >     spin_lock
> > > >     start other processors
> > > >     spin_unlock
> > > 
> > > Ok, I'll test and apply your patch then.
> > > 
> > > Once you change the code to enable caches, please consider hanging on
> > > spin_lock with caches disabled.
> > 
> > Unfortunately I can't do that without changing spin_lock into a wrapper
> > function. Early setup code calls functions that use spin_locks, e.g.
> > puts(), and we won't want to move the cache enablement into early setup
> > code, as that should be left for unit tests to turn on off as they wish.
> > Thus we either need to be able to change the spin_lock implementation
> > dynamically, or just leave the test/return as is.
> > 
> My take on this whole thing is that we're doing something fundamentally
> wrong.  I think what we should do is to always enable the MMU for
> running actual tests, bringing up multiple CPUs etc.  We could have an
> early_printf() that doesn't use the spinlock.  I think this will just be
> a more stable setup.
> 
> Do we have clear ideas of which kinds of tests it would make sense to
> run without the MMU turned on?  If we can be more concrete on this
> subject, perhaps a special path (or build) that doesn't enable the MMU
> for running the aforementioned test cases could be added.
> 

Finally carving out kvm-unit-tests time again and fixed this properly.
A series is on the list "[kvm-unit-tests PATCH 0/6] arm: enable MMU".

drew

  reply	other threads:[~2014-10-30 16:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16  2:06 [PATCH kvm-unit-tests] arm: fix crash when caches are off Andrew Jones
2014-09-16  8:14 ` Paolo Bonzini
2014-09-16 12:12   ` Andrew Jones
2014-09-16 12:28     ` Paolo Bonzini
2014-09-16 12:43       ` Andrew Jones
2014-09-16 12:47         ` Paolo Bonzini
2014-09-16 12:51           ` Andrew Jones
2014-09-16 14:38             ` Andrew Jones
2014-09-16 18:04               ` Andrew Jones
2014-09-16 12:57           ` Andrew Jones
2014-09-26  7:51             ` Christoffer Dall
2014-10-30 15:59               ` Andrew Jones [this message]
2014-09-16 12:48         ` Andrew Jones
2014-09-18 10:36 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141030155959.GA9562@hawk.usersys.redhat.com \
    --to=drjones@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.