All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 4/6] openpic: don't crash on a register access without a CPU context
Date: Fri, 14 Dec 2012 15:42:55 -0600	[thread overview]
Message-ID: <1355521375.4740.6@snotra> (raw)
In-Reply-To: <B20683A9-43C9-4D0A-8C8B-ACD759B6AD90@suse.de> (from agraf@suse.de on Fri Dec 14 06:35:12 2012)

On 12/14/2012 06:35:12 AM, Alexander Graf wrote:
> 
> On 14.12.2012, at 03:12, Scott Wood wrote:
> 
> > If we access a register via the QEMU memory inspection commands  
> (e.g.
> > "xp") rather than from guest code, we won't have a CPU context.
> > Gracefully fail to access the register in that case, rather than
> > crashing.
> 
> Can't we set cpu_single_env in the debug memory access case? I'm not  
> sure this is the only device with that problem, and by always having  
> cpu_single_env available we would completely get rid of the whole bug  
> category.

So, how would we go about doing this?  cpu_single_env is declared as  
thread-local storage.  Even if there's some way to deliberately inspect  
a different thread's local storage, I don't see how you'd get it to  
work automatically without changing all those drivers (and are there  
really that many that care about the CPU?) -- and we might break other  
places that already check whether cpu_single_env is NULL.

FWIW, hw/pc.c does pretty much the same thing as this patch in  
cpu_get_current_apic().

-Scott

  parent reply	other threads:[~2012-12-14 21:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14  2:11 [Qemu-devel] [PATCH 0/6] openpic: first batch of cleanups and minor fixes Scott Wood
2012-12-14  2:11 ` [Qemu-devel] [PATCH 1/6] openpic: symbolicize some magic numbers Scott Wood
2012-12-14  2:12 ` [Qemu-devel] [PATCH 2/6] openpic: remove pcsr (CPU sensitivity register) Scott Wood
2012-12-14  2:12 ` [Qemu-devel] [PATCH 3/6] openpic: support large vectors on FSL mpic Scott Wood
2012-12-14  2:12 ` [Qemu-devel] [PATCH 4/6] openpic: don't crash on a register access without a CPU context Scott Wood
2012-12-14 12:35   ` Alexander Graf
2012-12-14 18:18     ` Scott Wood
2012-12-14 18:20       ` Alexander Graf
2012-12-14 21:42     ` Scott Wood [this message]
2012-12-14 21:58       ` Alexander Graf
2012-12-15  8:48         ` [Qemu-devel] [Qemu-ppc] " Blue Swirl
2012-12-14  2:12 ` [Qemu-devel] [PATCH 5/6] openpic: BRR1 is not a CPU-specific register Scott Wood
2012-12-14  2:12 ` [Qemu-devel] [PATCH 6/6] openpic: s/opp->nb_irqs -1/opp->nb_cpus - 1/ Scott Wood
2012-12-14 12:37 ` [Qemu-devel] [PATCH 0/6] openpic: first batch of cleanups and minor fixes Alexander Graf

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=1355521375.4740.6@snotra \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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.