[Top][All Lists]

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

Re: [Qemu-ppc] Regression in ppc-softmmu when running HelenOS

From: Alexander Graf
Subject: Re: [Qemu-ppc] Regression in ppc-softmmu when running HelenOS
Date: Mon, 12 Mar 2012 17:56:35 +0100

On 12.03.2012, at 17:26, Mark Cave-Ayland wrote:

> On 12/03/12 11:40, Alexander Graf wrote:
>>> Hello,
>>> resending the bug report to qemu-ppc@ to get the potentially interested
>>> people hooked:
>>> https://bugs.launchpad.net/qemu/+bug/942299
>>> The following commit introduced some change due to which HelenOS no
>>> longer boots to command line:
>> Could you please add printf's in that code path before and after the patch 
>> and compare which bits are different in MSR? Maybe we screw up on 
>> maintaining MSR_RI during interrupt delivery?
>> Alex
> I haven't managed to get as far as I liked on this to date (mainly as there 
> was another bug preventing VGA in git master from PPC working), but I did 
> manage to at least get HelenOS to boot with the (incomplete) attached patch 
> against git master. I don't believe this is necessarily the full solution 
> since I find the booted image is quite console lethargic (and can lose/return 
> incorrect keypresses).
> The reason I hadn't updated the bug was because I still wasn't sure if this 
> was part of the QEMU performance regression I noticed when comparing old/new 
> versions of HelenOS or simply because the flag handling for calculating 
> new_msr is still incomplete. Some searching revealed the  link 
> http://www.systemcomputing.org/ppc/ppc4.htm which seems to indicate that the 
> MSR modification upon entry to the interrupt routine could be different to 
> the list of always-zeroed flags removed by the mask (which is what pointed me 
> in this direction in the first place).
> Anyway, I include the patch as discussion point - don't forget that you need 
> to boot QEMU with the openbios-ppc image from 0.11 stable branch if you 
> currently wish to test this.

Well, I really dislike the negative logic in this. If we want to take bits from 
the old MSR into the new one, let's rather explicitly copy them over, rather 
than unmasking random bits on an interrupt. That makes the code a lot more 


reply via email to

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