On Fri, Dec 14, 2012 at 9:58 PM, Alexander Graf <ag...@suse.de> wrote: > > On 14.12.2012, at 22:42, Scott Wood wrote: > >> 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(). > > Ok, convinced :). Patch applied to ppc-next. Thanks ;)
The long term fix for both openpic and LAPIC is to introduce a CPU specific address space and then instantiate a device for each CPU. The memory inspection commands probably need to specify the CPU. > > > Alex > >
