[Qemu-devel] [Question]Support of China loogson processor

[Qemu-devel] [Question]Support of China loogson processor

[vt]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi, guys

I saw the architecture code about mips in the qemu and kvm modules, so it is no doubt that mips cpu can be supported.
But I wonder if anyone have used qemu/kvm virtualization with China loongson processor (MIPS architecture) without modification of qemu/kvm code.
All the infomation I have searched in the Internet can't answer my question. 

If anyone have done that before, let me know it will not  be a dead end.

Thanks
Sangfor VT

[-- Attachment #2: Type: text/html, Size: 1561 bytes --]

Re: [Qemu-devel] [Question]Support of China loogson processor

[Rob Landley]

On Mon, Apr 13, 2015 at 6:29 AM, vt <vt@sangfor.com.cn> wrote:
> Hi, guys
>
> I saw the architecture code about mips in the qemu and kvm modules, so it is
> no doubt that mips cpu can be supported.

It looks like the 32 bit one should work fine. I haven't played with
64 bit yet but there's some support for it in the tree, give it a try?

  http://en.wikipedia.org/wiki/Loongson

Heh. The background on the "4 patented instructions" mentioned above
is mips' lawsuit against Lexra many years ago:

  http://landley.net/notes-2009.html#14-12-2009

If you were wondering why mips had a lost decade where most of its
customers switched over to arm, convincing the world you're a patent
troll will do that. But it's been well over a decade and most people
seem to have forgotten now. And china never cared about US
intellectual property infighting anyway...

> But I wonder if anyone have used qemu/kvm virtualization with China loongson
> processor (MIPS architecture) without modification of qemu/kvm code.
> All the infomation I have searched in the Internet can't answer my question.

I have a mips r4k system emulation working fine at:

  http://landley.net/aboriginal/bin/system-image-mips.tar.gz

(That's based off of linux 3.18 I think, I have 3.19 building locally,
4.0 is on the todo list.)

I haven't tried 64 bit yet but:

$ qemu-system-mips64 -cpu ? | grep Loongson
MIPS 'Loongson-2E'
MIPS 'Loongson-2F'

It's apparently there...

Rob

Re: [Qemu-devel] [Question]Support of China loogson processor

[vt]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On 2015/4/15 9:08, Rob Landley  wrote:
> On Mon, Apr 13, 2015 at 6:29 AM, vt <vt@sangfor.com.cn> wrote:
>> Hi, guys
>>
>> I saw the architecture code about mips in the qemu and kvm modules, so it is
>> no doubt that mips cpu can be supported.
>
> It looks like the 32 bit one should work fine. I haven't played with
> 64 bit yet but there's some support for it in the tree, give it a try?
>
>   http://en.wikipedia.org/wiki/Loongson
>
> Heh. The background on the "4 patented instructions" mentioned above
> is mips' lawsuit against Lexra many years ago:
>
>   http://landley.net/notes-2009.html#14-12-2009
>
> If you were wondering why mips had a lost decade where most of its
> customers switched over to arm, convincing the world you're a patent
> troll will do that. But it's been well over a decade and most people
> seem to have forgotten now. And china never cared about US
> intellectual property infighting anyway...
>
>> But I wonder if anyone have used qemu/kvm virtualization with China loongson
>> processor (MIPS architecture) without modification of qemu/kvm code.
>> All the infomation I have searched in the Internet can't answer my question.
>
> I have a mips r4k system emulation working fine at:
>
>   http://landley.net/aboriginal/bin/system-image-mips.tar.gz
>
> (That's based off of linux 3.18 I think, I have 3.19 building locally,
> 4.0 is on the todo list.)
>
> I haven't tried 64 bit yet but:
>
> $ qemu-system-mips64 -cpu ? | grep Loongson
> MIPS 'Loongson-2E'
> MIPS 'Loongson-2F'
>
> It's apparently there...
>
> Rob
>

Rob, Thanks for your help.

Sangfor VT

[-- Attachment #2: Type: text/html, Size: 4137 bytes --]

Re: [Qemu-devel] [Question]Support of China loogson processor

[Andreas Färber]

Am 15.04.2015 um 03:08 schrieb Rob Landley:
> On Mon, Apr 13, 2015 at 6:29 AM, vt <vt@sangfor.com.cn> wrote:
>> I saw the architecture code about mips in the qemu and kvm modules, so it is
>> no doubt that mips cpu can be supported.
> 
> It looks like the 32 bit one should work fine. I haven't played with
> 64 bit yet but there's some support for it in the tree, give it a try?
[...]
>> But I wonder if anyone have used qemu/kvm virtualization with China loongson
>> processor (MIPS architecture) without modification of qemu/kvm code.
>> All the infomation I have searched in the Internet can't answer my question.
> 
> I have a mips r4k system emulation working fine at:
[...]
> I haven't tried 64 bit yet but:
> 
> $ qemu-system-mips64 -cpu ? | grep Loongson
> MIPS 'Loongson-2E'
> MIPS 'Loongson-2F'
> 
> It's apparently there...

Note that the question was about KVM virtualization, not emulation
(unless it was misphrased). CC'ing Leon as MIPS maintainer.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] [Question]Support of China loogson processor

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On 13/04/15 12:29, vt wrote:
> Hi, guys
>  
> I saw the architecture code about mips in the qemu and kvm modules, so it is no doubt that mips cpu can be supported.
> But I wonder if anyone have used qemu/kvm virtualization with China loongson processor (MIPS architecture) without modification of qemu/kvm code.
> All the infomation I have searched in the Internet can't answer my question. 
>  
> If anyone have done that before, let me know it will not  be a dead end.
>  
> Thanks
> Sangfor VT

I haven't attempted it on Loongson yet, but it'd be interesting to see
whether it works. You'd still have to emulate a Malta guest at the
moment. Getting it to work on the Ingenic XBurst cores required a little
effort in the kernel due to slight incompatibilities with the MIPS32r2
spec, so its possible there'll be problems with Loongson too.

I presume Loongson may use highmem, if so you'll want to disable it. I
still need to get those patches sorted out.

Let us know how it goes or if you hit problems!

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Question]Support of China loogson processor

[Leon Alrae]

On 15/04/2015 10:35, James Hogan wrote:
> On 13/04/15 12:29, vt wrote:
>> Hi, guys
>>  
>> I saw the architecture code about mips in the qemu and kvm modules, so it is no doubt that mips cpu can be supported.
>> But I wonder if anyone have used qemu/kvm virtualization with China loongson processor (MIPS architecture) without modification of qemu/kvm code.
>> All the infomation I have searched in the Internet can't answer my question. 
>>  
>> If anyone have done that before, let me know it will not  be a dead end.
>>  
>> Thanks
>> Sangfor VT
> 
> I haven't attempted it on Loongson yet, but it'd be interesting to see
> whether it works. You'd still have to emulate a Malta guest at the
> moment. Getting it to work on the Ingenic XBurst cores required a little
> effort in the kernel due to slight incompatibilities with the MIPS32r2
> spec, so its possible there'll be problems with Loongson too.
> 
> I presume Loongson may use highmem, if so you'll want to disable it. I
> still need to get those patches sorted out.
> 
> Let us know how it goes or if you hit problems!

Since I also haven't had a chance to test Loongson emulation, I thought
I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).

Good news is that I'm able to get to the login prompt using ancient QEMU
v1.0, kernel 2.6.33 (with additional patch from
https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
some old debian image I had handy. However, in any newer version
starting from v1.1.0 of QEMU something goes horribly wrong and it just
segfaults somewhere inside hw/bonito.c quite early during kernel
booting. I haven't looked deeper, but it seems it's not in the best shape...

Leon

Re: [Qemu-devel] [Question]Support of China loogson processor

[Paolo Bonzini]

On 16/04/2015 13:07, Leon Alrae wrote:
> Since I also haven't had a chance to test Loongson emulation, I thought
> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
> 
> Good news is that I'm able to get to the login prompt using ancient QEMU
> v1.0, kernel 2.6.33 (with additional patch from
> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
> some old debian image I had handy. However, in any newer version
> starting from v1.1.0 of QEMU something goes horribly wrong and it just
> segfaults somewhere inside hw/bonito.c quite early during kernel
> booting.

Where exactly?  If it's related to the memory API conversion, it may be
easy to fix.  I can look at a backtrace (or you can just put the Debian
image somewhere I can grab it).

Paolo

> I haven't looked deeper, but it seems it's not in the best shape...

Re: [Qemu-devel] [Question]Support of China loogson processor

[Leon Alrae]

On 16/04/2015 13:02, Paolo Bonzini wrote:
> 
> 
> On 16/04/2015 13:07, Leon Alrae wrote:
>> Since I also haven't had a chance to test Loongson emulation, I thought
>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
>>
>> Good news is that I'm able to get to the login prompt using ancient QEMU
>> v1.0, kernel 2.6.33 (with additional patch from
>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
>> some old debian image I had handy. However, in any newer version
>> starting from v1.1.0 of QEMU something goes horribly wrong and it just
>> segfaults somewhere inside hw/bonito.c quite early during kernel
>> booting.
> 
> Where exactly?  If it's related to the memory API conversion, it may be
> easy to fix.  I can look at a backtrace (or you can just put the Debian
> image somewhere I can grab it).

Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093

Crash occurs during the first access, below there is backtrace from
working and not working case:

Bad:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffefe27700 (LWP 10929)]
0x00005555557a2278 in bonito_readl (opaque=0x5555564fb690, addr=24, size=4) at qemu/hw/bonito.c:299
299             return s->regs[saddr];
(gdb) bt
#0  0x00005555557a2278 in bonito_readl (opaque=0x5555564fb690, addr=24, size=4) at qemu/hw/bonito.c:299
#1  0x00005555557d6e03 in memory_region_read_accessor (opaque=0x5555564fbb60, addr=24, value=0x7fffefe265d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314
#2  0x00005555557d6fa9 in access_with_adjusted_size (addr=24, value=0x7fffefe265d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6daa <memory_region_read_accessor>, opaque=0x5555564fbb60) at qemu/memory.c:359
#3  0x00005555557d9796 in memory_region_dispatch_read1 (mr=0x5555564fbb60, addr=24, size=4) at qemu/memory.c:860
#4  0x00005555557d9886 in memory_region_dispatch_read (mr=0x5555564fbb60, addr=24, size=4) at qemu/memory.c:892
#5  0x00005555557dc306 in io_mem_read (io_index=6, addr=24, size=4) at qemu/memory.c:1492
#6  0x00005555557aed0d in subpage_read (opaque=0x5555564ed790, addr=24, len=4) at qemu/exec.c:3351
#7  0x00005555557d6e03 in memory_region_read_accessor (opaque=0x5555564ed790, addr=280, value=0x7fffefe267d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314
#8  0x00005555557d6fa9 in access_with_adjusted_size (addr=280, value=0x7fffefe267d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6daa <memory_region_read_accessor>, opaque=0x5555564ed790) at qemu/memory.c:359
#9  0x00005555557d9796 in memory_region_dispatch_read1 (mr=0x5555564ed790, addr=280, size=4) at qemu/memory.c:860
#10 0x00005555557d9886 in memory_region_dispatch_read (mr=0x5555564ed790, addr=280, size=4) at qemu/memory.c:892
#11 0x00005555557dc306 in io_mem_read (io_index=7, addr=280, size=4) at qemu/memory.c:1492
#12 0x00005555557f523e in io_readl (physaddr=280, addr=18446744072633712920, retaddr=0x4023335e) at qemu/softmmu_template.h:78
#13 0x00005555557f5335 in __ldl_mmu (addr=18446744072633712920, mmu_idx=0) at qemu/softmmu_template.h:114


Good:

Breakpoint 1, bonito_readl (opaque=0x55555646e450, addr=280, size=4) at qemu/hw/bonito.c:288
288     {
(gdb) bt
#0  bonito_readl (opaque=0x55555646e450, addr=280, size=4) at qemu/hw/bonito.c:288
#1  0x00005555557d6b83 in memory_region_read_accessor (opaque=0x55555646e920, addr=280, value=0x7fffefe265d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314
#2  0x00005555557d6d29 in access_with_adjusted_size (addr=280, value=0x7fffefe265d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6b2a <memory_region_read_accessor>, opaque=0x55555646e920) at qemu/memory.c:359
#3  0x00005555557d9516 in memory_region_dispatch_read1 (mr=0x55555646e920, addr=280, size=4) at qemu/memory.c:860
#4  0x00005555557d9606 in memory_region_dispatch_read (mr=0x55555646e920, addr=280, size=4) at qemu/memory.c:892
#5  0x00005555557dc086 in io_mem_read (io_index=6, addr=280, size=4) at qemu/memory.c:1492
#6  0x00005555557aeba5 in subpage_read (opaque=0x555556543730, addr=280, len=4) at qemu/exec.c:3343
#7  0x00005555557d6b83 in memory_region_read_accessor (opaque=0x555556543730, addr=280, value=0x7fffefe267d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314
#8  0x00005555557d6d29 in access_with_adjusted_size (addr=280, value=0x7fffefe267d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6b2a <memory_region_read_accessor>, opaque=0x555556543730) at qemu/memory.c:359
#9  0x00005555557d9516 in memory_region_dispatch_read1 (mr=0x555556543730, addr=280, size=4) at qemu/memory.c:860
#10 0x00005555557d9606 in memory_region_dispatch_read (mr=0x555556543730, addr=280, size=4) at qemu/memory.c:892
#11 0x00005555557dc086 in io_mem_read (io_index=7, addr=280, size=4) at qemu/memory.c:1492
#12 0x00005555557f4fbe in io_readl (physaddr=280, addr=18446744072633712920, retaddr=0x40232bde) at qemu/softmmu_template.h:78
#13 0x00005555557f50b5 in __ldl_mmu (addr=18446744072633712920, mmu_idx=0) at qemu/softmmu_template.h:114

Re: [Qemu-devel] [Question]Support of China loogson processor

[Paolo Bonzini]

On 16/04/2015 17:05, Leon Alrae wrote:
> On 16/04/2015 13:02, Paolo Bonzini wrote:
>>
>>
>> On 16/04/2015 13:07, Leon Alrae wrote:
>>> Since I also haven't had a chance to test Loongson emulation, I thought
>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
>>>
>>> Good news is that I'm able to get to the login prompt using ancient QEMU
>>> v1.0, kernel 2.6.33 (with additional patch from
>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
>>> some old debian image I had handy. However, in any newer version
>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just
>>> segfaults somewhere inside hw/bonito.c quite early during kernel
>>> booting.
>>
>> Where exactly?  If it's related to the memory API conversion, it may be
>> easy to fix.  I can look at a backtrace (or you can just put the Debian
>> image somewhere I can grab it).
> 
> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093
> 
> Crash occurs during the first access, below there is backtrace from
> working and not working case:

This is my best guess...

diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
index 8bdd569..8134d0b 100644
--- a/hw/pci-host/bonito.c
+++ b/hw/pci-host/bonito.c
@@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr,
     uint32_t saddr;
     int reset = 0;
 
-    saddr = (addr - BONITO_REGBASE) >> 2;
+    saddr = addr >> 2;
 
     DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr);
     switch (saddr) {
@@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr,
     PCIBonitoState *s = opaque;
     uint32_t saddr;
 
-    saddr = (addr - BONITO_REGBASE) >> 2;
+    saddr = addr >> 2;
 
     DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr);
     switch (saddr) {


Paolo

Re: [Qemu-devel] [Question]Support of China loogson processor

[Leon Alrae]

On 16/04/15 16:17, Paolo Bonzini wrote:
> 
> 
> On 16/04/2015 17:05, Leon Alrae wrote:
>> On 16/04/2015 13:02, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/04/2015 13:07, Leon Alrae wrote:
>>>> Since I also haven't had a chance to test Loongson emulation, I thought
>>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
>>>>
>>>> Good news is that I'm able to get to the login prompt using ancient QEMU
>>>> v1.0, kernel 2.6.33 (with additional patch from
>>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
>>>> some old debian image I had handy. However, in any newer version
>>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just
>>>> segfaults somewhere inside hw/bonito.c quite early during kernel
>>>> booting.
>>>
>>> Where exactly?  If it's related to the memory API conversion, it may be
>>> easy to fix.  I can look at a backtrace (or you can just put the Debian
>>> image somewhere I can grab it).
>>
>> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093
>>
>> Crash occurs during the first access, below there is backtrace from
>> working and not working case:
> 
> This is my best guess...
> 
> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
> index 8bdd569..8134d0b 100644
> --- a/hw/pci-host/bonito.c
> +++ b/hw/pci-host/bonito.c
> @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr,
>      uint32_t saddr;
>      int reset = 0;
>  
> -    saddr = (addr - BONITO_REGBASE) >> 2;
> +    saddr = addr >> 2;
>  
>      DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr);
>      switch (saddr) {
> @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr,
>      PCIBonitoState *s = opaque;
>      uint32_t saddr;
>  
> -    saddr = (addr - BONITO_REGBASE) >> 2;
> +    saddr = addr >> 2;
>  
>      DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr);
>      switch (saddr) {
> 

Nice. Thanks!

Would you send the patch or should I do this? With this fix fulong2e
machine is brought back to life. It would be great to have it in 2.3.

Leon

Re: [Qemu-devel] [Question]Support of China loogson processor

[Paolo Bonzini]

On 16/04/2015 21:25, Leon Alrae wrote:
> On 16/04/15 16:17, Paolo Bonzini wrote:
>>
>>
>> On 16/04/2015 17:05, Leon Alrae wrote:
>>> On 16/04/2015 13:02, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 16/04/2015 13:07, Leon Alrae wrote:
>>>>> Since I also haven't had a chance to test Loongson emulation, I thought
>>>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
>>>>>
>>>>> Good news is that I'm able to get to the login prompt using ancient QEMU
>>>>> v1.0, kernel 2.6.33 (with additional patch from
>>>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
>>>>> some old debian image I had handy. However, in any newer version
>>>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just
>>>>> segfaults somewhere inside hw/bonito.c quite early during kernel
>>>>> booting.
>>>>
>>>> Where exactly?  If it's related to the memory API conversion, it may be
>>>> easy to fix.  I can look at a backtrace (or you can just put the Debian
>>>> image somewhere I can grab it).
>>>
>>> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093
>>>
>>> Crash occurs during the first access, below there is backtrace from
>>> working and not working case:
>>
>> This is my best guess...
>>
>> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
>> index 8bdd569..8134d0b 100644
>> --- a/hw/pci-host/bonito.c
>> +++ b/hw/pci-host/bonito.c
>> @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr,
>>      uint32_t saddr;
>>      int reset = 0;
>>  
>> -    saddr = (addr - BONITO_REGBASE) >> 2;
>> +    saddr = addr >> 2;
>>  
>>      DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr);
>>      switch (saddr) {
>> @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr,
>>      PCIBonitoState *s = opaque;
>>      uint32_t saddr;
>>  
>> -    saddr = (addr - BONITO_REGBASE) >> 2;
>> +    saddr = addr >> 2;
>>  
>>      DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr);
>>      switch (saddr) {
>>
> 
> Nice. Thanks!
> 
> Would you send the patch or should I do this? With this fix fulong2e
> machine is brought back to life. It would be great to have it in 2.3.

You can send a pull request directly (add my Signed-off-by and Cc:
qemu-stable@nongnu.org, please), but it is possible Peter will tell you
to wait for 2.3.1.  It's been broken for a few years already. :)

Paolo

Re: [Qemu-devel] [Question]Support of China loogson processor

[Peter Maydell]

On 16 April 2015 at 16:17, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 16/04/2015 17:05, Leon Alrae wrote:
>> On 16/04/2015 13:02, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/04/2015 13:07, Leon Alrae wrote:
>>>> Since I also haven't had a chance to test Loongson emulation, I thought
>>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine).
>>>>
>>>> Good news is that I'm able to get to the login prompt using ancient QEMU
>>>> v1.0, kernel 2.6.33 (with additional patch from
>>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and
>>>> some old debian image I had handy. However, in any newer version
>>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just
>>>> segfaults somewhere inside hw/bonito.c quite early during kernel
>>>> booting.
>>>
>>> Where exactly?  If it's related to the memory API conversion, it may be
>>> easy to fix.  I can look at a backtrace (or you can just put the Debian
>>> image somewhere I can grab it).
>>
>> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093
>>
>> Crash occurs during the first access, below there is backtrace from
>> working and not working case:
>
> This is my best guess...
>
> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
> index 8bdd569..8134d0b 100644
> --- a/hw/pci-host/bonito.c
> +++ b/hw/pci-host/bonito.c
> @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr,
>      uint32_t saddr;
>      int reset = 0;
>
> -    saddr = (addr - BONITO_REGBASE) >> 2;
> +    saddr = addr >> 2;
>
>      DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr);
>      switch (saddr) {
> @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr,
>      PCIBonitoState *s = opaque;
>      uint32_t saddr;
>
> -    saddr = (addr - BONITO_REGBASE) >> 2;
> +    saddr = addr >> 2;
>
>      DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr);
>      switch (saddr) {

Wow, I thought we'd fixed all those "non-page-aligned mmio
region broke when the memory core was fixed to actual pass
the correct address to it" bugs years ago. I wonder if there's
a way to find out if we have any more (coccinelle search pattern?)

Incidentally, this device will happily let the guest
overwrite arbitrary chunks of its state struct via
bonito_cop_writel and bonito_ldma_writel, so I hope
nobody runs untrusted guests on this model :-)

(Its realize function maps its own MMIO regions into
system memory, too, which is a huge style error these days.)

-- PMM