qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/6] openpic: don't crash on a regist


From: Blue Swirl
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/6] openpic: don't crash on a register access without a CPU context
Date: Sat, 15 Dec 2012 08:48:32 +0000

On Fri, Dec 14, 2012 at 9:58 PM, Alexander Graf <address@hidden> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]