Under qemu-system-sparc, I found a problem with OBP's psr commands.
On an real SS-20, I get:
ok .psr
CWP: 4 ET: 1 PS: 1 S: 1 PIL: f EF: 1 EC: 0 ICC: nZvc VER: 0
IMPL: 4
ok %psr .
40401fe4
But with qemu, it all shows up as 0, such as:
ok .psr
CWP: 0 ET: 0 PS: 0 S
> > > Ah the problem is that we have not qdevified mac io bus. Since first to
> > > ide disks are automatically attached to mac-io bus device paths for them
> > > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > > will generate correct device paths for them:
> > >
> > >
On Sat, 2010-12-11 at 18:06 +0200, Gleb Natapov wrote:
> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table
> on
> page 10 that defines how pci class code should be translated into OF
> name. This is what my patch is using. pci-ata does not look spec
> compliant (or is there more
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
CC: Alexander Graf
Signed-off-by: Blue Swirl
---
hw/vga.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index b5c8741..c632fd7 100644
--- a/hw/vg
Thanks, applied all.
On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov wrote:
> Forget to save a couple of buffers before sending version 7 :(
>
> Anthony, Blue can this be applied now?
>
> Gleb Natapov (16):
> Introduce fw_name field to DeviceInfo structure.
> Introduce new BusInfo callback get_fw
2010/12/11 Gleb Natapov :
> On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
>> On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote:
>> > >> What should we do with
>> > >> at...@600 vs dr...@1?
>> > > There is no available IDE OF b
2010/12/11 Gleb Natapov :
> On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote:
>> >> What should we do with
>> >> at...@600 vs dr...@1?
>> > There is no available IDE OF binding spec, so I when with the way
>> > OpenBIOS reports ata on qemu-x
On Sat, Dec 11, 2010 at 07:06:04PM +, Blue Swirl wrote:
> 2010/12/11 Gleb Natapov :
> > On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> >> On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote:
> >> > >> What should we do with
Thanks, applied.
On Wed, Dec 8, 2010 at 2:59 PM, Bernhard Kohl wrote:
> The device shall set its default hardware state after each reset.
> This includes that the timer is stopped which is especially important
> if the guest does a reboot independantly of a watchdog bite. I moved
> the initializa
Thanks, applied.
On Fri, Dec 3, 2010 at 11:05 AM, Tristan Gingold wrote:
> Minor clean-up in isa-bus.c. Using hw_error is more consistent.
> There is a difference however: hw_error dumps the cpu state.
>
> Signed-off-by: Tristan Gingold
> ---
> hw/isa-bus.c | 11 ---
> 1 files change
On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote:
> > >> What should we do with
> > >> at...@600 vs dr...@1?
> > > There is no available IDE OF binding spec, so I when with the
Thanks, applied.
On Wed, Dec 8, 2010 at 11:05 AM, Alexander Graf wrote:
> The way mmio endianness is currently implemented is horrifying.
>
> In the real world, CPUs have an endianness and write out data
> to the memory bus. Instead of RAM, a receiving side here can be
> a device. This device get
On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote:
> >> What should we do with
> >> at...@600 vs dr...@1?
> > There is no available IDE OF binding spec, so I when with the way
> > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in a
On Sat, Dec 11, 2010 at 4:06 PM, Gleb Natapov wrote:
> On Sat, Dec 11, 2010 at 03:13:35PM +, Blue Swirl wrote:
>> On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov wrote:
>> > Forget to save a couple of buffers before sending version 7 :(
>> >
>> > Anthony, Blue can this be applied now?
>>
>> I m
On Sat, Dec 11, 2010 at 03:13:35PM +, Blue Swirl wrote:
> On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov wrote:
> > Forget to save a couple of buffers before sending version 7 :(
> >
> > Anthony, Blue can this be applied now?
>
> I made some more tests, this time with PPC. I modified OpenBIOS
On Sat, Dec 11, 2010 at 3:33 PM, Hans de Goede wrote:
> Hi,
>
> On 12/11/2010 10:43 AM, Blue Swirl wrote:
>>
>> On Tue, Dec 7, 2010 at 10:20 AM, Alon Levy wrote:
>>>
>>> ping.
>>
>> I don't think Anthony's concerns (or mine) have been addressed.
>>
>
> Could you be a bit more verbose please ?
I'
Hi,
On 12/11/2010 10:43 AM, Blue Swirl wrote:
On Tue, Dec 7, 2010 at 10:20 AM, Alon Levy wrote:
ping.
I don't think Anthony's concerns (or mine) have been addressed.
Could you be a bit more verbose please ?
Thanks & Regards,
Hans
On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov wrote:
> Forget to save a couple of buffers before sending version 7 :(
>
> Anthony, Blue can this be applied now?
I made some more tests, this time with PPC. I modified OpenBIOS to
print out the boot device list:
$ qemu-system-ppc -drive if=none,id=
On Sat, Dec 11, 2010 at 2:32 PM, Stefano Bonifazi
wrote:
> -Original Message-
> From: Blue Swirl [mailto:blauwir...@gmail.com]
> Sent: sabato 11 dicembre 2010 14:12
> To: Stefano Bonifazi
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] TCG flow vs dyngen
>
>
>>There's a large buffe
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: venerdì 10 dicembre 2010 22:49
To: Stefano Bonifazi
Subject: Re: [PATCH] fix qruncom compilation problems
>For runcom (without the "q") this wouldn't work, because it runs the code
in vm86 mode. It's possible that
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: sabato 11 dicembre 2010 14:12
To: Stefano Bonifazi
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] TCG flow vs dyngen
>There's a large buffer for generated code, allocated in exec.c. This is filled
>with host co
It's been fixed now, thanks. There seems to be no way to close this
bug, but you can assume, now, that it is closed.
Thanks for your help in tracking it down and fixing it quickly.
** Changed in: qemu
Status: In Progress => Fix Released
--
You received this bug notification because you
Found out how to change the bug's status. I've marked it as fixed.
Thanks again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/671831
Title:
Sparc guest assert error
Status in QEMU:
Fix Release
On Sat, Dec 11, 2010 at 1:03 PM, Stefan Hajnoczi wrote:
> Historically, QEMU code has defined per-file DPRINTF() macros for
> debug logging. A lot of recent patches continue to use this
> technique.
>
> I want to draw attention to tracing support and its advantages over
> DPRINTF(). Tracing is a
On Sat, Dec 11, 2010 at 12:29 PM, Stefano Bonifazi
wrote:
> Thank you very very much! I'd take months for understanding everything
> myself from the source code! :)
>
> On 12/11/2010 12:02 PM, Blue Swirl wrote:
>>
>> On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
>> wrote:
>>>
>>> [..]
>>>
>>
Historically, QEMU code has defined per-file DPRINTF() macros for
debug logging. A lot of recent patches continue to use this
technique.
I want to draw attention to tracing support and its advantages over
DPRINTF(). Tracing is an alternative that solves limitations of the
DPRINTF() approach:
1.
> On Thu, Dec 02, 2010 at 01:12:13PM +0100, Kevin Wolf wrote:
> > > DEFINE_PROP_UINT16("physical_block_size", _state,
> > > \
> > >
> > > _conf.physical_block_size, 512),
> > > \
> > >
> > >
Thank you very very much! I'd take months for understanding everything
myself from the source code! :)
On 12/11/2010 12:02 PM, Blue Swirl wrote:
On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
wrote:
[..]
- So, I think that the technical documentation is now obsolete, isn't it?
At least
On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
wrote:
> Hi all!
> From the technical documentation
> (http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html)
> I read:
>
> The first step is to split each target CPU instruction into fewer simpler
> instruction
On Thu, Dec 9, 2010 at 8:32 PM, David S. Ahern wrote:
>
>
> On 12/09/10 06:05, Gerd Hoffmann wrote:
>>
>> Hi,
>>
>>> New features developed for the kernel are done in a separate git trees.
>>> When a feature is ready for inclusion into the main kernel tree, a pull
>>> request is sent. That workf
On Tue, Dec 7, 2010 at 10:43 AM, Fabien Chouteau wrote:
> On 12/06/2010 06:25 PM, Blue Swirl wrote:
>>
>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteau
>> wrote:
>>>
>>> Signed-off-by: Fabien Chouteau
>>> ---
>>> hw/grlib_irqmp.c | 416
>>> +
On Tue, Dec 7, 2010 at 11:51 AM, Fabien Chouteau wrote:
> On 12/06/2010 07:01 PM, Blue Swirl wrote:
>>
>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteau
>> wrote:
>>>
>>> Signed-off-by: Fabien Chouteau
>>> ---
>>> hw/leon3.c | 6 ++
>>> target-sparc/cpu.h | 1 +
>>>
On Tue, Dec 7, 2010 at 11:40 AM, Fabien Chouteau wrote:
> On 12/06/2010 06:53 PM, Blue Swirl wrote:
>>
>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteau
>> wrote:
>>>
>>> Signed-off-by: Fabien Chouteau
>>> ---
>>> Makefile.target | 5 +-
>>> hw/leon3.c | 310
>>> +
On Tue, Dec 7, 2010 at 10:20 AM, Alon Levy wrote:
> ping.
I don't think Anthony's concerns (or mine) have been addressed.
> Blue Swirl - one patch I forgot is in a later message titled "..v8.1.."
> with the removal of the libcaccard build.
This should be merged with 4/6.
On Tue, Dec 7, 2010 at 10:08 AM, Alexander Graf wrote:
>
> On 06.12.2010, at 19:38, Blue Swirl wrote:
>
>> On Mon, Dec 6, 2010 at 11:12 AM, Alexander Graf wrote:
>>>
>>> On 05.12.2010, at 17:25, Blue Swirl wrote:
>>>
'info tlb' didn't show correct information for PAE mode and
x86_64 lon
35 matches
Mail list logo
