Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

On 20/10/2019 08:28, David Gibson wrote:
> On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote:
>> On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
>>> On 19/10/2019 17:31, Marty E. Plummer wrote:
 On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> On 18/10/2019 19:28, Marty E. Plummer wrote:
>> Hello,
>>
>> First off, thank you for the work you've done on the ppc64 support, it
>> has been very useful. I'm currently working on a coreboot port for the
>> talos ii line of systems (which means more ppc64 support, support
>> specifically for the power9 sforza chip, and specific mainboard support.
>> My plate is very full lol) and have been using qemu to debug the
>> bootblock.
>>
>> It has been very useful for that, but I'm now at the point where I need
>> to jump to romstage, and that's where it gets tricky. qemu parses the rom
>> image and looks for a ffs header, locates skiboot on it, and jumps 
>> straight
>> to that. Not exactly ideal for debugging something not produced from 
>> op-build.
>
> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> flash and extract the kernel and initramfs from the PNOR.
>
> However, you can bypass all this internal boot process by simply passing
> a -bios option and not passing a MTD device.
>
 Doing so gives me the following error:
 qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
 (this is after I patched the 4mb size limit up)
>>>
>>> Could you make that rom available ? 
>>>
>> Sure, I think. Not sure about how sending files works in my current mail
>> client but will see. Its more or less a 'stock' (as stock as can be for
>> a new coreboot target) coreboot.rom file, but I've added some logic into
>> the build to fake a pnor ffs header at the end in order to trick hostboot
>> bootloader into loading it.
> 
> Ok.  Note that the qemu emulated machine doesn't model the hardware
> right down to the level of hostboot.  That's wy we're just loading
> skiboot and jumping straight into it usually.  I guess clg's stuff to
> load pnor images gets us a little closer to the hardware behaviour,
> but I think it's still only a rough approximation.

It's really tied to the OpenPOWER firmwares using the HIOMAP protocol
to discuss with the BMC and load the flash. We could loosen how QEMU 
interprets the MTD device and use a property to inform QEMU that this
is an OpenPOWER  PNOR file and that skiboot and can be loaded from it.
Something to discuss.


I have applied this small hack to load larger -bios files :
 
--- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c
+++ qemu-powernv-4.2.git/hw/ppc/pnv.c
@@ -58,7 +58,7 @@
 
 #define FW_FILE_NAME"skiboot.lid"
 #define FW_LOAD_ADDR0x0
-#define FW_MAX_SIZE (4 * MiB)
+#define FW_MAX_SIZE (64 * MiB)
 
 #define KERNEL_LOAD_ADDR0x2000
 #define KERNEL_MAX_SIZE (256 * MiB)

and coreboot.rom loads and boots and loops.


You can use -d exec,in_asm to check what's going on.


C.

Re: [PATCH v3 1/9] Acceptance tests: refactor wait_for_console_pattern

[David Gibson]

On Thu, Oct 17, 2019 at 06:52:31PM +0200, Philippe Mathieu-Daudé wrote:
> From: Cleber Rosa 
> 
> The same utility method is already present in two different test
> files, so let's consolidate it into a single utility function.
> 
> Signed-off-by: Cleber Rosa 
> Message-Id: <20190916164011.7653-1-cr...@redhat.com>
> Reviewed-by: Philippe Mathieu-Daudé 
> [PMD: rebased fixing conflicts in linux_ssh_mips_malta.py]
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: David Gibson 

> ---
>  tests/acceptance/avocado_qemu/__init__.py | 26 +
>  tests/acceptance/boot_linux_console.py| 47 +++
>  tests/acceptance/linux_ssh_mips_malta.py  | 18 ++---
>  3 files changed, 42 insertions(+), 49 deletions(-)
> 
> diff --git a/tests/acceptance/avocado_qemu/__init__.py 
> b/tests/acceptance/avocado_qemu/__init__.py
> index bd41e0443c..a0fe16e47f 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -8,6 +8,7 @@
>  # This work is licensed under the terms of the GNU GPL, version 2 or
>  # later.  See the COPYING file in the top-level directory.
>  
> +import logging
>  import os
>  import sys
>  import uuid
> @@ -53,6 +54,31 @@ def pick_default_qemu_bin(arch=None):
>  return qemu_bin_from_src_dir_path
>  
>  
> +def wait_for_console_pattern(test, success_message,
> + failure_message='Kernel panic - not syncing'):
> +"""
> +Waits for messages to appear on the console, while logging the content
> +
> +:param test: an Avocado test containing a VM that will have its console
> + read and probed for a success or failure message
> +:type test: :class:`avocado_qemu.Test`
> +:param success_message: if this message appears, test succeeds
> +:param failure_message: if this message appears, test fails
> +"""
> +console = test.vm.console_socket.makefile()
> +console_logger = logging.getLogger('console')
> +while True:
> +msg = console.readline().strip()
> +if not msg:
> +continue
> +console_logger.debug(msg)
> +if success_message in msg:
> +break
> +if failure_message in msg:
> +fail = 'Failure message found in console: %s' % failure_message
> +test.fail(fail)
> +
> +
>  class Test(avocado.Test):
>  def setUp(self):
>  self._vms = {}
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index 8a9a314ab4..9ff2213874 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -9,12 +9,12 @@
>  # later.  See the COPYING file in the top-level directory.
>  
>  import os
> -import logging
>  import lzma
>  import gzip
>  import shutil
>  
>  from avocado_qemu import Test
> +from avocado_qemu import wait_for_console_pattern
>  from avocado.utils import process
>  from avocado.utils import archive
>  
> @@ -29,31 +29,10 @@ class BootLinuxConsole(Test):
>  
>  KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
>  
> -def wait_for_console_pattern(self, success_message,
> - failure_message='Kernel panic - not 
> syncing'):
> -"""
> -Waits for messages to appear on the console, while logging the 
> content
> -
> -:param success_message: if this message appears, test succeeds
> -:param failure_message: if this message appears, test fails
> -"""
> -console = self.vm.console_socket.makefile()
> -console_logger = logging.getLogger('console')
> -while True:
> -msg = console.readline().strip()
> -if not msg:
> -continue
> -console_logger.debug(msg)
> -if success_message in msg:
> -break
> -if failure_message in msg:
> -fail = 'Failure message found in console: %s' % 
> failure_message
> -self.fail(fail)
> -
>  def exec_command_and_wait_for_pattern(self, command, success_message):
>  command += '\n'
>  self.vm.console_socket.sendall(command.encode())
> -self.wait_for_console_pattern(success_message)
> +wait_for_console_pattern(self, success_message)
>  
>  def extract_from_deb(self, deb, path):
>  """
> @@ -89,7 +68,7 @@ class BootLinuxConsole(Test):
>   '-append', kernel_command_line)
>  self.vm.launch()
>  console_pattern = 'Kernel command line: %s' % kernel_command_line
> -self.wait_for_console_pattern(console_pattern)
> +wait_for_console_pattern(self, console_pattern)
>  
>  def test_mips_malta(self):
>  """
> @@ -112,7 +91,7 @@ class BootLinuxConsole(Test):
>   '-append', kernel_command_line)
>  self.vm.launch()
>  console_pattern = 'Kernel command line: %s' % kernel_command_line
> -self.wait_fo

[PATCH] fdc: support READ command with VERIFY DMA mode

[Sven Schnelle]

While working on the Tulip driver i tried to write some Teledisk images to
a floppy image which didn't work. Turned out that Teledisk checks the written
data by issuing a READ command to the FDC but running the DMA controller
in VERIFY mode. As we ignored the DMA request in that case, the DMA transfer
never finished, and Teledisk reported an error.

Signed-off-by: Sven Schnelle 
---
 hw/block/fdc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index ac5d31e8c1..8a1228df78 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -1733,7 +1733,8 @@ static void fdctrl_start_transfer(FDCtrl *fdctrl, int 
direction)
 dma_mode_ok = (dma_mode == ISADMA_TRANSFER_WRITE);
 break;
 case FD_DIR_READ:
-dma_mode_ok = (dma_mode == ISADMA_TRANSFER_READ);
+dma_mode_ok = (dma_mode == ISADMA_TRANSFER_READ) ||
+  (dma_mode == ISADMA_TRANSFER_VERIFY);
 break;
 case FD_DIR_VERIFY:
 dma_mode_ok = true;
@@ -1835,8 +1836,11 @@ static int fdctrl_transfer_handler (void *opaque, int 
nchan,
 switch (fdctrl->data_dir) {
 case FD_DIR_READ:
 /* READ commands */
-k->write_memory(fdctrl->dma, nchan, fdctrl->fifo + rel_pos,
-fdctrl->data_pos, len);
+if (k->get_transfer_mode(fdctrl->dma, fdctrl->dma_chann) !=
+ISADMA_TRANSFER_VERIFY) {
+k->write_memory(fdctrl->dma, nchan, fdctrl->fifo + rel_pos,
+fdctrl->data_pos, len);
+}
 break;
 case FD_DIR_WRITE:
 /* WRITE commands */
-- 
2.23.0

Re: qemu/powernv: coreboot support?

[David Gibson]

On Sat, Oct 19, 2019 at 10:31:09AM -0500, Marty E. Plummer wrote:
> On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> > On 18/10/2019 19:28, Marty E. Plummer wrote:
> > > Hello,
> > > 
> > > First off, thank you for the work you've done on the ppc64 support, it
> > > has been very useful. I'm currently working on a coreboot port for the
> > > talos ii line of systems (which means more ppc64 support, support
> > > specifically for the power9 sforza chip, and specific mainboard support.
> > > My plate is very full lol) and have been using qemu to debug the
> > > bootblock.
> > > 
> > > It has been very useful for that, but I'm now at the point where I need
> > > to jump to romstage, and that's where it gets tricky. qemu parses the rom
> > > image and looks for a ffs header, locates skiboot on it, and jumps 
> > > straight
> > > to that. Not exactly ideal for debugging something not produced from 
> > > op-build.
> > 
> > yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> > file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> > flash and extract the kernel and initramfs from the PNOR.
> > 
> > However, you can bypass all this internal boot process by simply passing
> > a -bios option and not passing a MTD device.
> > 
> Doing so gives me the following error:
> qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> (this is after I patched the 4mb size limit up)

Hm curious.  We'd have to delve into load_image_targphys() and see why
it's failing.  Have you checked for simple causes: incorrect path, or
bad permissions to your coreboot image.

> > I haven't published the PNOR support and the boot from PNOR yet. Lack
> > of time and because sPAPR is the priority.
> > 
> > > Do you think it would be within your wheelhouse to provide a generic, 
> > > non-ffs
> > > pnor interface for loading arbitary rom images? 
> > 
> > I should probably send the PNOR patchset now so that we can discuss on 
> > a better way to satisfy all needs.  
> > 
> > > It would be of great help if
> > > you could. (This would still hopefully have the bmc support code as
> > > well, as I'm still needing to support a system using one).
> > 
> > We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> > is possible to interconnect them through the BT device. Or you can use
> > the IPMI BT simulator of QEMU on the PowerNV machine
> > 
> > Thanks,
> > 
> > C. 
> > 
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: qemu/powernv: coreboot support?

[David Gibson]

On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote:
> On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
> > On 19/10/2019 17:31, Marty E. Plummer wrote:
> > > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> > >> On 18/10/2019 19:28, Marty E. Plummer wrote:
> > >>> Hello,
> > >>>
> > >>> First off, thank you for the work you've done on the ppc64 support, it
> > >>> has been very useful. I'm currently working on a coreboot port for the
> > >>> talos ii line of systems (which means more ppc64 support, support
> > >>> specifically for the power9 sforza chip, and specific mainboard support.
> > >>> My plate is very full lol) and have been using qemu to debug the
> > >>> bootblock.
> > >>>
> > >>> It has been very useful for that, but I'm now at the point where I need
> > >>> to jump to romstage, and that's where it gets tricky. qemu parses the 
> > >>> rom
> > >>> image and looks for a ffs header, locates skiboot on it, and jumps 
> > >>> straight
> > >>> to that. Not exactly ideal for debugging something not produced from 
> > >>> op-build.
> > >>
> > >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR 
> > >> support
> > >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> > >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> > >> flash and extract the kernel and initramfs from the PNOR.
> > >>
> > >> However, you can bypass all this internal boot process by simply passing
> > >> a -bios option and not passing a MTD device.
> > >>
> > > Doing so gives me the following error:
> > > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> > > (this is after I patched the 4mb size limit up)
> > 
> > Could you make that rom available ? 
> > 
> Sure, I think. Not sure about how sending files works in my current mail
> client but will see. Its more or less a 'stock' (as stock as can be for
> a new coreboot target) coreboot.rom file, but I've added some logic into
> the build to fake a pnor ffs header at the end in order to trick hostboot
> bootloader into loading it.

Ok.  Note that the qemu emulated machine doesn't model the hardware
right down to the level of hostboot.  That's wy we're just loading
skiboot and jumping straight into it usually.  I guess clg's stuff to
load pnor images gets us a little closer to the hardware behaviour,
but I think it's still only a rough approximation.

> > Thanks,
> > 
> > C. 



-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: qemu/powernv: coreboot support?

[David Gibson]

On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> On 18/10/2019 19:28, Marty E. Plummer wrote:
> > Hello,
> > 
> > First off, thank you for the work you've done on the ppc64 support, it
> > has been very useful. I'm currently working on a coreboot port for the
> > talos ii line of systems (which means more ppc64 support, support
> > specifically for the power9 sforza chip, and specific mainboard support.
> > My plate is very full lol) and have been using qemu to debug the
> > bootblock.
> > 
> > It has been very useful for that, but I'm now at the point where I need
> > to jump to romstage, and that's where it gets tricky. qemu parses the rom
> > image and looks for a ffs header, locates skiboot on it, and jumps straight
> > to that. Not exactly ideal for debugging something not produced from 
> > op-build.
> 
> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> flash and extract the kernel and initramfs from the PNOR.

Ah!  Now I understand.  I hadn't looked at that branch, so I had no
idea what all this pnor stuff was about.  In mainline we just load
skiboot as a normal firmware file and jump into it.

> However, you can bypass all this internal boot process by simply passing
> a -bios option and not passing a MTD device.

Right.

> I haven't published the PNOR support and the boot from PNOR yet. Lack
> of time and because sPAPR is the priority.
> 
> > Do you think it would be within your wheelhouse to provide a generic, 
> > non-ffs
> > pnor interface for loading arbitary rom images? 
> 
> I should probably send the PNOR patchset now so that we can discuss on 
> a better way to satisfy all needs.  
> 
> > It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> is possible to interconnect them through the BT device. Or you can use
> the IPMI BT simulator of QEMU on the PowerNV machine
> 
> Thanks,
> 
> C. 
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Bug 1848901] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

[P.O.]

QEMU 4.1.0 btw.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848901

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
  (28)

Status in QEMU:
  New

Bug description:
  => QEMU process has stopped, return code: -6

  Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
  2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
  'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
  /7725cdea-5e66-4777-b4dd-
  c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
  -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
  telnet:127.0.0.1:5000,server,nowait -monitor
  tcp:127.0.0.1:44629,server,nowait -net none -device
  e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
  socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
  e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
  socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
  e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
  socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
  e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
  socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
  e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
  socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
  e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
  socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
  e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
  socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
  e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
  socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
  -nographic

   
  Execution log:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

  and then it just closes...


  [deemon@Zen ~]$ coredumpctl info 8638
 PID: 8638 (qemu-system-x86)
 UID: 1000 (deemon)
 GID: 1000 (deemon)
  Signal: 6 (ABRT)
   Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 
file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu>
  Executable: /usr/bin/qemu-system-x86_64
   Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
   Slice: user-1000.slice
 Session: 2
   Owner UID: 1000 (deemon)
 Boot ID: cd30f69a8d194359a31889dc7b6b026c
  Machine ID: d0a2d74a5cd9430797d902f5237c448d
Hostname: Zen
 Storage: 
/var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4
 (truncated)
 Message: Process 8638 (qemu-system-x86) of user 1000 dumped core.
  
  Stack trace of thread 8642:
  #0  0x7f1a33609f25 n/a (n/a)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848901/+subscriptions

[Bug 1848901] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

[P.O.]

correct hash from GNS3 webpage then*

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848901

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
  (28)

Status in QEMU:
  New

Bug description:
  => QEMU process has stopped, return code: -6

  Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
  2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
  'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
  /7725cdea-5e66-4777-b4dd-
  c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
  -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
  telnet:127.0.0.1:5000,server,nowait -monitor
  tcp:127.0.0.1:44629,server,nowait -net none -device
  e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
  socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
  e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
  socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
  e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
  socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
  e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
  socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
  e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
  socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
  e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
  socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
  e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
  socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
  e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
  socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
  -nographic

   
  Execution log:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

  and then it just closes...


  [deemon@Zen ~]$ coredumpctl info 8638
 PID: 8638 (qemu-system-x86)
 UID: 1000 (deemon)
 GID: 1000 (deemon)
  Signal: 6 (ABRT)
   Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 
file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu>
  Executable: /usr/bin/qemu-system-x86_64
   Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
   Slice: user-1000.slice
 Session: 2
   Owner UID: 1000 (deemon)
 Boot ID: cd30f69a8d194359a31889dc7b6b026c
  Machine ID: d0a2d74a5cd9430797d902f5237c448d
Hostname: Zen
 Storage: 
/var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4
 (truncated)
 Message: Process 8638 (qemu-system-x86) of user 1000 dumped core.
  
  Stack trace of thread 8642:
  #0  0x7f1a33609f25 n/a (n/a)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848901/+subscriptions

[Bug 1848901] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

[P.O.]

Was trying to start Cisco ASAv 9.8.1 (with the correct hash from your
own webpage) through GNS3 on Manjaro when this happened.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848901

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
  (28)

Status in QEMU:
  New

Bug description:
  => QEMU process has stopped, return code: -6

  Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
  2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
  'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
  /7725cdea-5e66-4777-b4dd-
  c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
  -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
  telnet:127.0.0.1:5000,server,nowait -monitor
  tcp:127.0.0.1:44629,server,nowait -net none -device
  e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
  socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
  e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
  socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
  e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
  socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
  e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
  socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
  e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
  socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
  e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
  socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
  e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
  socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
  e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
  socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
  -nographic

   
  Execution log:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

  and then it just closes...


  [deemon@Zen ~]$ coredumpctl info 8638
 PID: 8638 (qemu-system-x86)
 UID: 1000 (deemon)
 GID: 1000 (deemon)
  Signal: 6 (ABRT)
   Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 
file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu>
  Executable: /usr/bin/qemu-system-x86_64
   Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
   Slice: user-1000.slice
 Session: 2
   Owner UID: 1000 (deemon)
 Boot ID: cd30f69a8d194359a31889dc7b6b026c
  Machine ID: d0a2d74a5cd9430797d902f5237c448d
Hostname: Zen
 Storage: 
/var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4
 (truncated)
 Message: Process 8638 (qemu-system-x86) of user 1000 dumped core.
  
  Stack trace of thread 8642:
  #0  0x7f1a33609f25 n/a (n/a)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848901/+subscriptions

[Bug 1848901] [NEW] kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

[P.O.]

Public bug reported:

=> QEMU process has stopped, return code: -6

Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
/7725cdea-5e66-4777-b4dd-
c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
-uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
telnet:127.0.0.1:5000,server,nowait -monitor
tcp:127.0.0.1:44629,server,nowait -net none -device
e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
-nographic

 
Execution log:
kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

and then it just closes...


[deemon@Zen ~]$ coredumpctl info 8638
   PID: 8638 (qemu-system-x86)
   UID: 1000 (deemon)
   GID: 1000 (deemon)
Signal: 6 (ABRT)
 Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
  Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 
file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu>
Executable: /usr/bin/qemu-system-x86_64
 Control Group: /user.slice/user-1000.slice/session-2.scope
  Unit: session-2.scope
 Slice: user-1000.slice
   Session: 2
 Owner UID: 1000 (deemon)
   Boot ID: cd30f69a8d194359a31889dc7b6b026c
Machine ID: d0a2d74a5cd9430797d902f5237c448d
  Hostname: Zen
   Storage: 
/var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.157153484900.lz4
 (truncated)
   Message: Process 8638 (qemu-system-x86) of user 1000 dumped core.

Stack trace of thread 8642:
#0  0x7f1a33609f25 n/a (n/a)

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848901

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
  (28)

Status in QEMU:
  New

Bug description:
  => QEMU process has stopped, return code: -6

  Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m
  2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive
  'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu
  /7725cdea-5e66-4777-b4dd-
  c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0'
  -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial
  telnet:127.0.0.1:5000,server,nowait -monitor
  tcp:127.0.0.1:44629,server,nowait -net none -device
  e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev
  socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:1 -device
  e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev
  socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device
  e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev
  socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device
  e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev
  socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device
  e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev
  socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device
  e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev
  socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device
  e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev
  socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device
  e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev
  socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014
  -nographic

   
  Execution log:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28)

  and then it just closes...


  [deemon@Zen ~]$ coredumpctl info 8638
 PID: 8638 (qemu-system-x86)
 UID: 1000 (deemon)
 GID: 1000 (deemon)
  Signal: 6 (ABRT)
   Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago)
Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M 
-smp cpus=

[PATCH v3 15/16] python/qemu/machine: Allow to use other serial consoles than default

[Philippe Mathieu-Daudé]

Currently the QEMU Python module limits the QEMUMachine class to
use the first serial console.

Some machines/guest might use another console than the first one as
the 'boot console'. For example the Raspberry Pi uses the second
(AUX) console.

To be able to use the Nth console as default, we simply need to
connect all the N - 1 consoles to the null chardev.

Add an index argument, so we can use a specific serial console as
default.

Signed-off-by: Philippe Mathieu-Daudé 
---
v2:
- renamed 'console_index', added docstring (Cleber)
- reworded description (pm215)
---
 python/qemu/machine.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/python/qemu/machine.py b/python/qemu/machine.py
index 128a3d1dc2..6fa68fa35a 100644
--- a/python/qemu/machine.py
+++ b/python/qemu/machine.py
@@ -235,6 +235,8 @@ class QEMUMachine(object):
 '-display', 'none', '-vga', 'none']
 if self._machine is not None:
 args.extend(['-machine', self._machine])
+for i in range(self._console_index):
+args.extend(['-serial', 'null'])
 if self._console_set:
 self._console_address = os.path.join(self._temp_dir,
  self._name + "-console.sock")
@@ -495,7 +497,7 @@ class QEMUMachine(object):
 """
 self._machine = machine_type
 
-def set_console(self, device_type=None):
+def set_console(self, device_type=None, console_index=0):
 """
 Sets the device type for a console device
 
@@ -516,9 +518,14 @@ class QEMUMachine(object):
 chardev:console" command line argument will
 be used instead, resorting to the machine's
 default device type.
+@param console_index: the index of the console device to use.
+  If not zero, the command line will create
+  'index - 1' consoles and connect them to
+  the 'null' backing character device.
 """
 self._console_set = True
 self._console_device_type = device_type
+self._console_index = console_index
 
 @property
 def console_socket(self):
-- 
2.21.0

[PATCH NOTFORMERGE v3 16/16] tests/acceptance: Test U-boot on the Raspberry Pi 3

[Philippe Mathieu-Daudé]

This is a proof-of-concept for the '-smp cores=1' feature which
restricts the cores brought online on reset.

The u-boot binary is old and from an untrusted source, but I
don't want to add the build machinery in QEMU, so it is enough
to demonstrate the feature works reliably.

By default this test is not run:

  $ avocado run -t machine:raspi3 tests/acceptance/
   (1/1) 
tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi3_uboot: 
SKIP: untrusted code
  RESULTS: PASS 0 | ERROR 0 | FAIL 0 | SKIP 1 | WARN 0 | INTERRUPT 0 | 
CANCEL 0
  JOB TIME   : 0.23 s

We can run it setting the AVOCADO_ALLOW_UNTRUSTED_CODE variable:

  $ AVOCADO_ALLOW_UNTRUSTED_CODE=1 ./tests/venv/bin/avocado --show=app,console 
run -t machine:raspi3 tests/acceptance/
   (1/1) 
tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi3_uboot:  
console: U-Boot 2016.05-rc1-gd36dcaf (Apr 28 2016 - 23:29:29 +0200)
  console: DRAM:  960 MiB
  console: RPI 3 Model B (0xa02082)
  console: boot regs: 0x 0x 0x 0x
  console: MMC:   bcm2835_sdhci: 0
  console: Card did not respond to voltage select!
  console: ** Bad device mmc 0 **
  console: Using default environment
  console: In:serial
  console: Out:   lcd
  console: Err:   lcd
  console: Net:   Net Initialization Skipped
  console: No ethernet found.
  PASS (0.30 s)

Then test QEMU:

  $ qemu-system-aarch64 \
  -M raspi3 -smp 4,cores=1 \
  -kernel u-boot.bin \
  -serial null -serial stdio

  U-Boot 2016.05-rc1-gd36dcaf (Apr 28 2016 - 23:29:29 +0200)

  DRAM:  960 MiB
  RPI 3 Model B (0xa02082)
  boot regs: 0x 0x 0x 0x
  MMC:   bcm2835_sdhci: 0
  Card did not respond to voltage select!
  ** Bad device mmc 0 **
  Using default environment

  In:serial
  Out:   lcd
  Err:   lcd
  Net:   Net Initialization Skipped
  No ethernet found.
  starting USB...
  USB0:   Core Release: 0.000
  SNPSID invalid (not DWC2 OTG device): 
  Port not available.
  Autoboot in 2 seconds
  Card did not respond to voltage select!
  starting USB...
  USB0:   Core Release: 0.000
  SNPSID invalid (not DWC2 OTG device): 
  Port not available.
  USB is stopped. Please issue 'usb start' first.
  starting USB...
  USB0:   Core Release: 0.000
  SNPSID invalid (not DWC2 OTG device): 
  Port not available.
  No ethernet found.
  missing environment variable: pxeuuid
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/000
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/00
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/0
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/000
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/00
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/0
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/default-arm-bcm283x
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/default-arm
  No ethernet found.
  missing environment variable: bootfile
  Retrieving file: pxelinux.cfg/default
  No ethernet found.
  Config file not found
  starting USB...
  USB0:   Core Release: 0.000
  SNPSID invalid (not DWC2 OTG device): 
  Port not available.
  No ethernet found.
  U-Boot> version

  U-Boot 2016.05-rc1-gd36dcaf (Apr 28 2016 - 23:29:29 +0200)
  aarch64-unknown-linux-gnu-gcc (Gentoo 5.3.0 p1.0, pie-0.6.5) 5.3.0
  GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
  U-Boot> ^C
  qemu-system-aarch64: terminating on signal 2

We can also build a recent U-boot with:

  u-boot$ export CROSS_COMPILE=aarch64-linux-gnu-
  u-boot$ make rpi_3_defconfig
  u-boot$ make -j8

And test it:

  $ qemu-system-aarch64 \
  -M raspi3 -smp 4,cores=1 \
  -kernel u-boot.bin \
  -serial null -serial stdio

  MMC:   mmc@7e202000: 0, sdhci@7e30: 1
  Loading Environment from FAT... WARNING at 
drivers/mmc/bcm2835_sdhost.c:410/bcm2835_send_command()!
  WARNING at drivers/mmc/bcm2835_sdhost.c:410/bcm2835_send_command()!
  Card did not respond to voltage select!
  In:serial
  Out:   vidconsole
  Err:   vidconsole
  Net:   No ethernet found.
  starting USB...
  Bus usb@7e98: Port not available.
  Hit any key to stop autoboot:  0
  WARNING at drivers/mmc/bcm2835_sdhost.c:410/bcm2835_send_command()!
  WARNING at drivers/mmc/bcm2835_sdhost.c:410/bcm2835_send_command()!
  WARNING at drivers/mmc/bcm2835_sdhost.c:410/bcm2835_send_command()!
  Card did not respond to voltage select!
  MMC: no card present
  starting USB...
  Bus usb@7e98: Port not availab

[PATCH v3 12/16] hw/arm/bcm2836: Rename enabled_cpus -> enabled_cores

[Philippe Mathieu-Daudé]

We now use -smp cores= to limit the number of cores powered
on reset. Rename the 'enabled_cpus' variable as 'enabled_cores'
to better match the new use. No functional changes.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2836.c | 4 ++--
 hw/arm/raspi.c   | 2 +-
 include/hw/arm/bcm2836.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index ada35e5620..e3cef69687 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -202,7 +202,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 }
 
 /* start powered off if not enabled */
-object_property_set_bool(OBJECT(&s->cpu[n].core), n >= s->enabled_cpus,
+object_property_set_bool(OBJECT(&s->cpu[n].core), n >= 
s->enabled_cores,
  "start-powered-off", &err);
 if (err) {
 error_propagate(errp, err);
@@ -235,7 +235,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 }
 
 static Property bcm2836_props[] = {
-DEFINE_PROP_UINT32("enabled-cpus", BCM283XState, enabled_cpus,
+DEFINE_PROP_UINT32("enabled-cores", BCM283XState, enabled_cores,
BCM283X_NCPUS),
 DEFINE_PROP_END_OF_LIST()
 };
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 45d3f91f95..b1b488ca53 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -191,7 +191,7 @@ static void raspi_init(MachineState *machine, int version)
 object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),
&error_abort);
 object_property_set_int(OBJECT(&s->soc), machine->smp.cores,
-"enabled-cpus", &error_abort);
+"enabled-cores", &error_abort);
 int board_rev = version == 3 ? 0xa02082 : 0xa21041;
 object_property_set_int(OBJECT(&s->soc), board_rev, "board-rev",
 &error_abort);
diff --git a/include/hw/arm/bcm2836.h b/include/hw/arm/bcm2836.h
index 787ab76738..2c3f1e6c6a 100644
--- a/include/hw/arm/bcm2836.h
+++ b/include/hw/arm/bcm2836.h
@@ -33,7 +33,7 @@ typedef struct BCM283XState {
 /*< public >*/
 
 char *cpu_type;
-uint32_t enabled_cpus;
+uint32_t enabled_cores;
 
 struct {
 MemoryRegion bus;
-- 
2.21.0

[PATCH v3 10/16] hw/arm/raspi: Use AddressSpace when using arm_boot::write_secondary_boot

[Philippe Mathieu-Daudé]

write_secondary_boot() is used in SMP configurations where the
CPU address space might not be the main System Bus.
The rom_add_blob_fixed_as() function allow us to specify an
address space. Use it to write each boot blob in the corresponding
CPU address space.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/raspi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index a12459bc41..569d85c11a 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -60,12 +60,14 @@ static void write_smpboot(ARMCPU *cpu, const struct 
arm_boot_info *info)
 QEMU_BUILD_BUG_ON((BOARDSETUP_ADDR & 0xf) != 0
   || (BOARDSETUP_ADDR >> 4) >= 0x100);
 
-rom_add_blob_fixed("raspi_smpboot", smpboot, sizeof(smpboot),
-   info->smp_loader_start);
+rom_add_blob_fixed_as("raspi_smpboot", smpboot, sizeof(smpboot),
+  info->smp_loader_start,
+  arm_boot_address_space(cpu, info));
 }
 
 static void write_smpboot64(ARMCPU *cpu, const struct arm_boot_info *info)
 {
+AddressSpace *as = arm_boot_address_space(cpu, info);
 /* Unlike the AArch32 version we don't need to call the board setup hook.
  * The mechanism for doing the spin-table is also entirely different.
  * We must have four 64-bit fields at absolute addresses
@@ -92,10 +94,10 @@ static void write_smpboot64(ARMCPU *cpu, const struct 
arm_boot_info *info)
 0, 0, 0, 0
 };
 
-rom_add_blob_fixed("raspi_smpboot", smpboot, sizeof(smpboot),
-   info->smp_loader_start);
-rom_add_blob_fixed("raspi_spintables", spintables, sizeof(spintables),
-   SPINTABLE_ADDR);
+rom_add_blob_fixed_as("raspi_smpboot", smpboot, sizeof(smpboot),
+  info->smp_loader_start, as);
+rom_add_blob_fixed_as("raspi_spintables", spintables, sizeof(spintables),
+  SPINTABLE_ADDR, as);
 }
 
 static void write_board_setup(ARMCPU *cpu, const struct arm_boot_info *info)
-- 
2.21.0

[PATCH v3 13/16] hw/arm/raspi: Make the board code modular

[Philippe Mathieu-Daudé]

Our code currently create the raspi2 (based on the BCM2836)
and the raspi3 (on the BCM2837). Similarly, the raspi4 is
based on the BCM2838. To be able to add the new board,
make the current code more modular:

- Dynamically fills the 'board-rev' value
- Allow DRAM sizes different than 1 GiB

Rename the board model name as 'B' since this is the one
encoded in the 'board-rev' tag.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/raspi.c | 107 +++--
 1 file changed, 94 insertions(+), 13 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index b1b488ca53..004804bdb3 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -13,6 +13,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/units.h"
+#include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "cpu.h"
 #include "hw/arm/bcm2836.h"
@@ -29,8 +30,67 @@
 #define FIRMWARE_ADDR_3 0x8 /* Pi 3 loads kernel.img here by default */
 #define SPINTABLE_ADDR  0xd8 /* Pi 3 bootloader spintable */
 
-/* Table of Linux board IDs for different Pi versions */
-static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43, [3] = 0xc44};
+enum BoardIdManufacturer {
+M_SONY_UK = 0,
+M_EMBEST = 2,
+};
+
+enum BoardIdChip {
+C_BCM2835 = 0,
+C_BCM2836 = 1,
+C_BCM2837 = 2,
+};
+
+enum BoardIdType {
+T_2B = 0x04,
+T_3B = 0x08,
+};
+
+enum BoardIdRevision {
+R_1_0 = 0,
+R_1_1 = 1,
+R_1_2 = 2,
+R_1_3 = 3,
+};
+
+static const char *processor_typename[] = {
+[C_BCM2836] = TYPE_BCM2836,
+[C_BCM2837] = TYPE_BCM2837,
+};
+
+typedef struct BoardInfo BoardInfo;
+
+struct BoardInfo {
+/* Table of Linux board IDs for different Pi versions */
+int board_id;
+/*
+ * Board revision codes:
+ * www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/
+ */
+struct {
+enum BoardIdType type;
+enum BoardIdRevision revision;
+enum BoardIdChip chip;
+enum BoardIdManufacturer manufacturer;
+} board_rev;
+uint64_t ram_size_min;
+uint64_t ram_size_max;
+};
+
+static const BoardInfo bcm283x_boards[] = {
+[2] = {
+.board_id = 0xc43,
+.board_rev = { T_2B, R_1_1, C_BCM2836, M_EMBEST },
+.ram_size_min = 1 * GiB,
+.ram_size_max = 1 * GiB,
+},
+[3] = {
+.board_id = 0xc44,
+.board_rev = { T_3B, R_1_2, C_BCM2837, M_SONY_UK },
+.ram_size_min = 1 * GiB,
+.ram_size_max = 1 * GiB,
+},
+};
 
 typedef struct RasPiState {
 BCM283XState soc;
@@ -116,7 +176,7 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
 static struct arm_boot_info binfo;
 int r;
 
-binfo.board_id = raspi_boardid[version];
+binfo.board_id = bcm283x_boards[version].board_id;
 binfo.ram_size = ram_size;
 binfo.nb_cpus = machine->smp.cpus;
 
@@ -148,7 +208,7 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
  * the normal Linux boot process
  */
 if (machine->firmware) {
-hwaddr firmware_addr = version == 3 ? FIRMWARE_ADDR_3 : 
FIRMWARE_ADDR_2;
+hwaddr firmware_addr = version >= 3 ? FIRMWARE_ADDR_3 : 
FIRMWARE_ADDR_2;
 /* load the firmware image (typically kernel.img) */
 r = load_image_targphys(machine->firmware, firmware_addr,
 ram_size - firmware_addr);
@@ -172,16 +232,32 @@ static void raspi_init(MachineState *machine, int version)
 BlockBackend *blk;
 BusState *bus;
 DeviceState *carddev;
+char *size_str;
+int board_rev;
+const char *soc_type;
 
-if (machine->ram_size > 1 * GiB) {
+if (machine->ram_size < bcm283x_boards[version].ram_size_min) {
+size_str = size_to_str(bcm283x_boards[version].ram_size_min);
+error_report("Requested ram size is too small for this machine: "
+ "minimum is %s", size_str);
+g_free(size_str);
+exit(1);
+}
+if (machine->ram_size > bcm283x_boards[version].ram_size_max) {
+size_str = size_to_str(bcm283x_boards[version].ram_size_max);
 error_report("Requested ram size is too large for this machine: "
- "maximum is 1GB");
+ "maximum is %s", size_str);
+g_free(size_str);
+exit(1);
+}
+if (!is_power_of_2(machine->ram_size)) {
+error_report("Requested ram size is not a power of 2");
 exit(1);
 }
 
+soc_type = processor_typename[bcm283x_boards[version].board_rev.chip];
 object_initialize_child(OBJECT(machine), "soc", &s->soc, sizeof(s->soc),
-version == 3 ? TYPE_BCM2837 : TYPE_BCM2836,
-&error_abort, NULL);
+soc_type, &error_abort, NULL);
 
 /* Allocate and map RAM */
 memory_region_allocate_system_memory(&s->ram, OBJECT(machine), "ram",
@@ -192,9 +268,14 @@ static void raspi_init(MachineState *machine, int version)

[PATCH v3 14/16] hw/arm/highbank: Use AddressSpace when using write_secondary_boot()

[Philippe Mathieu-Daudé]

write_secondary_boot() is used in SMP configurations where the
CPU address space might not be the main System Bus.
The rom_add_blob_fixed_as() function allow us to specify an
address space. Use it to write each boot blob in the corresponding
CPU address space.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/highbank.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index f1724d6929..518d935fdf 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm/highbank.c
@@ -78,7 +78,8 @@ static void hb_write_secondary(ARMCPU *cpu, const struct 
arm_boot_info *info)
 for (n = 0; n < ARRAY_SIZE(smpboot); n++) {
 smpboot[n] = tswap32(smpboot[n]);
 }
-rom_add_blob_fixed("smpboot", smpboot, sizeof(smpboot), SMP_BOOT_ADDR);
+rom_add_blob_fixed_as("smpboot", smpboot, sizeof(smpboot), SMP_BOOT_ADDR,
+  arm_boot_address_space(cpu, info));
 }
 
 static void hb_reset_secondary(ARMCPU *cpu, const struct arm_boot_info *info)
-- 
2.21.0

[PATCH v3 08/16] hw/arm/bcm2835_peripherals: Add const link property in realize()

[Philippe Mathieu-Daudé]

The VideoCore GPU is indenpendant from the Peripheral block. In
the next commit, we will move its instantiation to the SoC block.
The "gpu-bus" object will not be accessible in init() but later
in realize(). As a preliminary step to keep the diff clearer, move
the const link property creation from init() to realize().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2835_peripherals.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index 17207ae07e..d51e9c8def 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -82,9 +82,6 @@ static void bcm2835_peripherals_init(Object *obj)
 object_property_add_alias(obj, "vcram-size", OBJECT(&s->fb), "vcram-size",
   &error_abort);
 
-object_property_add_const_link(OBJECT(&s->fb), "dma-mr",
-   OBJECT(&s->gpu_bus_mr), &error_abort);
-
 /* Property channel */
 sysbus_init_child_obj(obj, "property", &s->property, sizeof(s->property),
   TYPE_BCM2835_PROPERTY);
@@ -93,8 +90,6 @@ static void bcm2835_peripherals_init(Object *obj)
 
 object_property_add_const_link(OBJECT(&s->property), "fb",
OBJECT(&s->fb), &error_abort);
-object_property_add_const_link(OBJECT(&s->property), "dma-mr",
-   OBJECT(&s->gpu_bus_mr), &error_abort);
 
 /* Random Number Generator */
 sysbus_init_child_obj(obj, "rng", &s->rng, sizeof(s->rng),
@@ -112,9 +107,6 @@ static void bcm2835_peripherals_init(Object *obj)
 sysbus_init_child_obj(obj, "dma", &s->dma, sizeof(s->dma),
   TYPE_BCM2835_DMA);
 
-object_property_add_const_link(OBJECT(&s->dma), "dma-mr",
-   OBJECT(&s->gpu_bus_mr), &error_abort);
-
 /* Thermal */
 sysbus_init_child_obj(obj, "thermal", &s->thermal, sizeof(s->thermal),
   TYPE_BCM2835_THERMAL);
@@ -156,6 +148,7 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
 memory_region_add_subregion_overlap(&s->gpu_bus_mr, BCM2835_VC_PERI_BASE,
 &s->peri_mr_alias, 1);
 
+obj = OBJECT(&s->gpu_bus_mr);
 /* RAM is aliased four times (different cache configurations) on the GPU */
 for (n = 0; n < 4; n++) {
 memory_region_init_alias(&s->ram_alias[n], OBJECT(s),
@@ -236,6 +229,12 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
 return;
 }
 
+object_property_add_const_link(OBJECT(&s->fb), "dma-mr", obj, &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
 object_property_set_uint(OBJECT(&s->fb), ram_size - vcram_size,
  "vcram-base", &err);
 if (err) {
@@ -255,6 +254,11 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
qdev_get_gpio_in(DEVICE(&s->mboxes), MBOX_CHAN_FB));
 
 /* Property channel */
+object_property_add_const_link(OBJECT(&s->property), "dma-mr", obj, &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
 object_property_set_bool(OBJECT(&s->property), true, "realized", &err);
 if (err) {
 error_propagate(errp, err);
@@ -323,6 +327,11 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
INTERRUPT_SDIO));
 
 /* DMA Channels */
+object_property_add_const_link(OBJECT(&s->dma), "dma-mr", obj, &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
 object_property_set_bool(OBJECT(&s->dma), true, "realized", &err);
 if (err) {
 error_propagate(errp, err);
-- 
2.21.0

[PATCH v3 09/16] hw/arm/bcm2836: Create VideoCore address space in the SoC

[Philippe Mathieu-Daudé]

Currently the VideoCore is created in the Peripheral container
as the 'GPU bus'. It is created there because the peripherals
using DMA use physical addresses from the VideoCore bus.
However the VideoCore is a GPU core placed at the same
hierarchical level than the ARM cores.

To match the datasheet design, create the VideoCore container
in the SoC, and link it to the peripheral container.

The VideoCore bus is 1GiB wide, accessible at 4 regions in
different cache configurations. Add the full mapping.

Before this commit the memory tree is:

  (qemu) info mtree
  address-space: bcm2835-dma-memory
- (prio 0, i/o): bcm2835-gpu
  -3fff (prio 0, i/o): alias 
bcm2835-gpu-ram-alias[*] @ram -3fff
  4000-7fff (prio 0, i/o): alias 
bcm2835-gpu-ram-alias[*] @ram -3fff
  7e00-7eff (prio 1, i/o): alias 
bcm2835-peripherals @bcm2835-peripherals -00ff
  8000-bfff (prio 0, i/o): alias 
bcm2835-gpu-ram-alias[*] @ram -3fff
  c000- (prio 0, i/o): alias 
bcm2835-gpu-ram-alias[*] @ram -3fff

After:

  address-space: bcm2835-dma-memory
- (prio 0, i/o): gpu-bus
  -3fff (prio 0, i/o): alias l1-l2-cached 
@videocore -3fff
  4000-7fff (prio 0, i/o): alias l2-cached-coherent 
@videocore -3fff
  8000-bfff (prio 0, i/o): alias l2-cached 
@videocore -3fff
  c000- (prio 0, i/o): alias direct-uncached 
@videocore -3fff

  memory-region: videocore
-3fff (prio 0, i/o): videocore
  -3fff (prio 0, i/o): alias vc-ram @ram 
-3fff
  3e00-3eff (prio 1, i/o): alias vc-peripherals 
@bcm2835-peripherals -00ff

Now the periferals are accessible from the uncached region too.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2835_peripherals.c | 25 +-
 hw/arm/bcm2836.c | 38 
 include/hw/arm/bcm2835_peripherals.h |  4 +--
 include/hw/arm/bcm2836.h |  7 +
 4 files changed, 53 insertions(+), 21 deletions(-)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index d51e9c8def..5da310efb1 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -9,6 +9,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
 #include "hw/arm/bcm2835_peripherals.h"
@@ -45,10 +46,6 @@ static void bcm2835_peripherals_init(Object *obj)
 object_property_add_child(obj, "peripheral-io", OBJECT(&s->peri_mr), NULL);
 sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->peri_mr);
 
-/* Internal memory region for peripheral bus addresses (not exported) */
-memory_region_init(&s->gpu_bus_mr, obj, "bcm2835-gpu", (uint64_t)1 << 32);
-object_property_add_child(obj, "gpu-bus", OBJECT(&s->gpu_bus_mr), NULL);
-
 /* Internal memory region for request/response communication with
  * mailbox-addressable peripherals (not exported)
  */
@@ -140,21 +137,11 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
 ram = MEMORY_REGION(obj);
 ram_size = memory_region_size(ram);
 
-/* Map peripherals and RAM into the GPU address space. */
-memory_region_init_alias(&s->peri_mr_alias, OBJECT(s),
- "bcm2835-peripherals", &s->peri_mr, 0,
- memory_region_size(&s->peri_mr));
-
-memory_region_add_subregion_overlap(&s->gpu_bus_mr, BCM2835_VC_PERI_BASE,
-&s->peri_mr_alias, 1);
-
-obj = OBJECT(&s->gpu_bus_mr);
-/* RAM is aliased four times (different cache configurations) on the GPU */
-for (n = 0; n < 4; n++) {
-memory_region_init_alias(&s->ram_alias[n], OBJECT(s),
- "bcm2835-gpu-ram-alias[*]", ram, 0, ram_size);
-memory_region_add_subregion_overlap(&s->gpu_bus_mr, (hwaddr)n << 30,
-&s->ram_alias[n], 0);
+obj = object_property_get_link(OBJECT(dev), "videocore-bus", &err);
+if (obj == NULL) {
+error_setg(errp, "%s: required videocore-bus link not found: %s",
+   __func__, error_get_pretty(err));
+return;
 }
 
 /* Interrupt Controller */
diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index 374a44b38c..ada35e5620 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -51,6 +51,14 @@ static vo

[PATCH v3 07/16] hw/arm/bcm2836: Use per CPU address spaces

[Philippe Mathieu-Daudé]

Currently all CPUs access the main system bus. Let each CPU have
his own address space.

Before:

  (qemu) info mtree
  address-space: memory
- (prio 0, i/o): system
  -3fff (prio 0, ram): ram
  3f00-3fff (prio 1, i/o): bcm2835-peripherals
3f003000-3f00301f (prio 0, i/o): bcm2835-sys-timer
3f007000-3f007fff (prio 0, i/o): bcm2835-dma
3f00b200-3f00b3ff (prio 0, i/o): bcm2835-ic
3f00b400-3f00b43f (prio -1000, i/o): bcm2835-sp804
3f00b800-3f00bbff (prio 0, i/o): bcm2835-mbox
3f10-3f100fff (prio -1000, i/o): bcm2835-cprman
3f102000-3f102fff (prio -1000, i/o): bcm2835-a2w
3f104000-3f10400f (prio 0, i/o): bcm2835-rng
3f20-3f200fff (prio 0, i/o): bcm2835_gpio
3f201000-3f201fff (prio 0, i/o): pl011
3f202000-3f202fff (prio 0, i/o): bcm2835-sdhost
3f203000-3f2030ff (prio -1000, i/o): bcm2835-i2s
3f204000-3f20401f (prio -1000, i/o): bcm2835-spi0
3f205000-3f20501f (prio -1000, i/o): bcm2835-i2c0
3f20f000-3f20f07f (prio -1000, i/o): bcm2835-otp
3f212000-3f212007 (prio 0, i/o): bcm2835-thermal
3f214000-3f2140ff (prio -1000, i/o): bcm2835-spis
3f215000-3f2150ff (prio 0, i/o): bcm2835-aux
3f30-3f3000ff (prio 0, i/o): sdhci
3f60-3f6000ff (prio -1000, i/o): bcm2835-smi
3f804000-3f80401f (prio -1000, i/o): bcm2835-i2c1
3f805000-3f80501f (prio -1000, i/o): bcm2835-i2c2
3f90-3f907fff (prio -1000, i/o): bcm2835-dbus
3f91-3f917fff (prio -1000, i/o): bcm2835-ave0
3f98-3f980fff (prio -1000, i/o): dwc-usb2
3fe0-3fe000ff (prio -1000, i/o): bcm2835-sdramc
3fe05000-3fe050ff (prio 0, i/o): bcm2835-dma-chan15
  4000-40ff (prio 0, i/o): bcm2836-control

  address-space: cpu-secure-memory-0
- (prio 0, i/o): system
  -3fff (prio 0, ram): ram
  3f00-3fff (prio 1, i/o): bcm2835-peripherals
3f003000-3f00301f (prio 0, i/o): bcm2835-sys-timer
3f007000-3f007fff (prio 0, i/o): bcm2835-dma
3f00b200-3f00b3ff (prio 0, i/o): bcm2835-ic
3f00b400-3f00b43f (prio -1000, i/o): bcm2835-sp804
3f00b800-3f00bbff (prio 0, i/o): bcm2835-mbox
3f10-3f100fff (prio -1000, i/o): bcm2835-cprman
3f102000-3f102fff (prio -1000, i/o): bcm2835-a2w
3f104000-3f10400f (prio 0, i/o): bcm2835-rng
3f20-3f200fff (prio 0, i/o): bcm2835_gpio
3f201000-3f201fff (prio 0, i/o): pl011
3f202000-3f202fff (prio 0, i/o): bcm2835-sdhost
3f203000-3f2030ff (prio -1000, i/o): bcm2835-i2s
3f204000-3f20401f (prio -1000, i/o): bcm2835-spi0
3f205000-3f20501f (prio -1000, i/o): bcm2835-i2c0
3f20f000-3f20f07f (prio -1000, i/o): bcm2835-otp
3f212000-3f212007 (prio 0, i/o): bcm2835-thermal
3f214000-3f2140ff (prio -1000, i/o): bcm2835-spis
3f215000-3f2150ff (prio 0, i/o): bcm2835-aux
3f30-3f3000ff (prio 0, i/o): sdhci
3f60-3f6000ff (prio -1000, i/o): bcm2835-smi
3f804000-3f80401f (prio -1000, i/o): bcm2835-i2c1
3f805000-3f80501f (prio -1000, i/o): bcm2835-i2c2
3f90-3f907fff (prio -1000, i/o): bcm2835-dbus
3f91-3f917fff (prio -1000, i/o): bcm2835-ave0
3f98-3f980fff (prio -1000, i/o): dwc-usb2
3fe0-3fe000ff (prio -1000, i/o): bcm2835-sdramc
3fe05000-3fe050ff (prio 0, i/o): bcm2835-dma-chan15
  4000-40ff (prio 0, i/o): bcm2836-control

  address-space: cpu-memory-0
- (prio 0, i/o): system
  -3fff (prio 0, ram): ram
  3f00-3fff (prio 1, i/o): bcm2835-peripherals
3f003000-3f00301f (prio 0, i/o): bcm2835-sys-timer
3f007000-3f007fff (prio 0, i/o): bcm2835-dma
3f00b200-000

[PATCH v3 11/16] hw/arm/raspi: Use -smp cores= option to restrict enabled cores

[Philippe Mathieu-Daudé]

The abstract TYPE_BCM283X device provides a 'enabled-cpus' property
to restrict the number of cores powered on reset. This because on
real hardware the GPU is responsible of starting the cores and keep
them spinning until the Linux kernel is ready to use them.
When using the -kernel paramenter, QEMU does this by installing the
'raspi_smpboot' code when arm_boot_info::write_board_setup() is
called. This is a special feature to help the Linux kernel, and can
only be used with a Linux kernel.

Even if loaded with the -kernel option, U-boot is not Linux, thus
is not recognized as it and the raspi_smpboot code is not installed.

Upon introduction of this machine in commit 1df7d1f9303, the -smp 
option allowd to limit the number of cores powered on reset.
Unfortunately later commit 72649619341 added a check which made this
feature unusable:

  $ qemu-system-aarch64 -M raspi3 -smp 1
  qemu-system-aarch64: Invalid SMP CPUs 1. The min CPUs supported by machine 
'raspi3' is 4

Fortunately, the -smp option allow various kind of CPU topology:

  -smp 
[cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,dies=dies][,sockets=sockets]
   set the number of CPUs to 'n' [default=1]
   maxcpus= maximum number of total cpus, including
   offline CPUs for hotplug, etc
   cores= number of CPU cores on one socket (for PC, it's on one die)
   threads= number of threads on one CPU core
   dies= number of CPU dies on one socket (for PC only)
   sockets= number of discrete sockets in the system

Let's use the 'cores' argument to specify the number of cores powered
at reset to restore this feature, and allow to boot U-boot.

We can now run U-boot using:

  $ qemu-system-aarch64 -M raspi3 -smp 4,cores=1 ...

Reported-by: Laurent Bonnans 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/raspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 569d85c11a..45d3f91f95 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -190,8 +190,8 @@ static void raspi_init(MachineState *machine, int version)
 /* Setup the SOC */
 object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),
&error_abort);
-object_property_set_int(OBJECT(&s->soc), machine->smp.cpus, "enabled-cpus",
-&error_abort);
+object_property_set_int(OBJECT(&s->soc), machine->smp.cores,
+"enabled-cpus", &error_abort);
 int board_rev = version == 3 ? 0xa02082 : 0xa21041;
 object_property_set_int(OBJECT(&s->soc), board_rev, "board-rev",
 &error_abort);
-- 
2.21.0

[PATCH v3 04/16] hw/arm/bcm2835_peripherals: Use the SYS_timer

[Philippe Mathieu-Daudé]

Connect the recently added SYS_timer.
Now U-Boot does not hang anymore polling a free running counter
stuck at 0.
This timer is also used by the Linux kernel thermal subsystem.

Reviewed-by: Alistair Francis 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Remove spurious error check (Alex)
---
 hw/arm/bcm2835_peripherals.c | 17 -
 include/hw/arm/bcm2835_peripherals.h |  3 ++-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index 70bf927a02..17207ae07e 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -58,6 +58,10 @@ static void bcm2835_peripherals_init(Object *obj)
 /* Interrupt Controller */
 sysbus_init_child_obj(obj, "ic", &s->ic, sizeof(s->ic), TYPE_BCM2835_IC);
 
+/* SYS Timer */
+sysbus_init_child_obj(obj, "systimer", &s->systmr, sizeof(s->systmr),
+  TYPE_BCM2835_SYSTIMER);
+
 /* UART0 */
 sysbus_init_child_obj(obj, "uart0", &s->uart0, sizeof(s->uart0),
   TYPE_PL011);
@@ -171,6 +175,18 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
 sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->ic), 0));
 sysbus_pass_irq(SYS_BUS_DEVICE(s), SYS_BUS_DEVICE(&s->ic));
 
+/* Sys Timer */
+object_property_set_bool(OBJECT(&s->systmr), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+memory_region_add_subregion(&s->peri_mr, ST_OFFSET,
+sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->systmr), 0));
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->systmr), 0,
+qdev_get_gpio_in_named(DEVICE(&s->ic), BCM2835_IC_ARM_IRQ,
+   INTERRUPT_ARM_TIMER));
+
 /* UART0 */
 qdev_prop_set_chr(DEVICE(&s->uart0), "chardev", serial_hd(0));
 object_property_set_bool(OBJECT(&s->uart0), true, "realized", &err);
@@ -352,7 +368,6 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
 }
 
 create_unimp(s, &s->armtmr, "bcm2835-sp804", ARMCTRL_TIMER0_1_OFFSET, 
0x40);
-create_unimp(s, &s->systmr, "bcm2835-systimer", ST_OFFSET, 0x20);
 create_unimp(s, &s->cprman, "bcm2835-cprman", CPRMAN_OFFSET, 0x1000);
 create_unimp(s, &s->a2w, "bcm2835-a2w", A2W_OFFSET, 0x1000);
 create_unimp(s, &s->i2s, "bcm2835-i2s", I2S_OFFSET, 0x100);
diff --git a/include/hw/arm/bcm2835_peripherals.h 
b/include/hw/arm/bcm2835_peripherals.h
index be7ad9b499..7859281e11 100644
--- a/include/hw/arm/bcm2835_peripherals.h
+++ b/include/hw/arm/bcm2835_peripherals.h
@@ -24,6 +24,7 @@
 #include "hw/sd/sdhci.h"
 #include "hw/sd/bcm2835_sdhost.h"
 #include "hw/gpio/bcm2835_gpio.h"
+#include "hw/timer/bcm2835_systmr.h"
 #include "hw/misc/unimp.h"
 
 #define TYPE_BCM2835_PERIPHERALS "bcm2835-peripherals"
@@ -39,7 +40,7 @@ typedef struct BCM2835PeripheralState {
 MemoryRegion ram_alias[4];
 qemu_irq irq, fiq;
 
-UnimplementedDeviceState systmr;
+BCM2835SystemTimerState systmr;
 UnimplementedDeviceState armtmr;
 UnimplementedDeviceState cprman;
 UnimplementedDeviceState a2w;
-- 
2.21.0

[PATCH v3 02/16] hw/arm/bcm2835_peripherals: Use the thermal sensor block

[Philippe Mathieu-Daudé]

Map the thermal sensor in the BCM2835 block.

Reviewed-by: Alistair Francis 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2835_peripherals.c | 13 +
 include/hw/arm/bcm2835_peripherals.h |  2 ++
 include/hw/arm/raspi_platform.h  |  1 +
 3 files changed, 16 insertions(+)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index fdcf616c56..70bf927a02 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -111,6 +111,10 @@ static void bcm2835_peripherals_init(Object *obj)
 object_property_add_const_link(OBJECT(&s->dma), "dma-mr",
OBJECT(&s->gpu_bus_mr), &error_abort);
 
+/* Thermal */
+sysbus_init_child_obj(obj, "thermal", &s->thermal, sizeof(s->thermal),
+  TYPE_BCM2835_THERMAL);
+
 /* GPIO */
 sysbus_init_child_obj(obj, "gpio", &s->gpio, sizeof(s->gpio),
   TYPE_BCM2835_GPIO);
@@ -321,6 +325,15 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
   INTERRUPT_DMA0 + n));
 }
 
+/* THERMAL */
+object_property_set_bool(OBJECT(&s->thermal), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+memory_region_add_subregion(&s->peri_mr, THERMAL_OFFSET,
+sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->thermal), 0));
+
 /* GPIO */
 object_property_set_bool(OBJECT(&s->gpio), true, "realized", &err);
 if (err) {
diff --git a/include/hw/arm/bcm2835_peripherals.h 
b/include/hw/arm/bcm2835_peripherals.h
index 62a4c7b559..be7ad9b499 100644
--- a/include/hw/arm/bcm2835_peripherals.h
+++ b/include/hw/arm/bcm2835_peripherals.h
@@ -20,6 +20,7 @@
 #include "hw/misc/bcm2835_property.h"
 #include "hw/misc/bcm2835_rng.h"
 #include "hw/misc/bcm2835_mbox.h"
+#include "hw/misc/bcm2835_thermal.h"
 #include "hw/sd/sdhci.h"
 #include "hw/sd/bcm2835_sdhost.h"
 #include "hw/gpio/bcm2835_gpio.h"
@@ -53,6 +54,7 @@ typedef struct BCM2835PeripheralState {
 SDHCIState sdhci;
 BCM2835SDHostState sdhost;
 BCM2835GpioState gpio;
+Bcm2835ThermalState thermal;
 UnimplementedDeviceState i2s;
 UnimplementedDeviceState spi[1];
 UnimplementedDeviceState i2c[3];
diff --git a/include/hw/arm/raspi_platform.h b/include/hw/arm/raspi_platform.h
index cdcbca943f..61b04a1bd4 100644
--- a/include/hw/arm/raspi_platform.h
+++ b/include/hw/arm/raspi_platform.h
@@ -48,6 +48,7 @@
 #define SPI0_OFFSET 0x204000
 #define BSC0_OFFSET 0x205000 /* BSC0 I2C/TWI */
 #define OTP_OFFSET  0x20f000
+#define THERMAL_OFFSET  0x212000
 #define BSC_SL_OFFSET   0x214000 /* SPI slave */
 #define AUX_OFFSET  0x215000 /* AUX: UART1/SPI1/SPI2 */
 #define EMMC1_OFFSET0x30
-- 
2.21.0

[PATCH v3 05/16] hw/arm/bcm2836: Make the SoC code modular

[Philippe Mathieu-Daudé]

This file creates the BCM2836/BCM2837 blocks.
The biggest differences with the BCM2838 we are going to add, are
the base addresses of the interrupt controller and the peripherals.
Add these addresses in the BCM283XInfo structure to make this
block more modular. Remove the MCORE_OFFSET offset as it is
not useful and rather confusing.

Reviewed-by: Esteban Bosse 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2836.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index 723aef6bf5..019e67b906 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -16,15 +16,11 @@
 #include "hw/arm/raspi_platform.h"
 #include "hw/sysbus.h"
 
-/* Peripheral base address seen by the CPU */
-#define BCM2836_PERI_BASE   0x3F00
-
-/* "QA7" (Pi2) interrupt controller and mailboxes etc. */
-#define BCM2836_CONTROL_BASE0x4000
-
 struct BCM283XInfo {
 const char *name;
 const char *cpu_type;
+hwaddr peri_base; /* Peripheral base address seen by the CPU */
+hwaddr ctrl_base; /* Interrupt controller and mailboxes etc. */
 int clusterid;
 };
 
@@ -32,12 +28,16 @@ static const BCM283XInfo bcm283x_socs[] = {
 {
 .name = TYPE_BCM2836,
 .cpu_type = ARM_CPU_TYPE_NAME("cortex-a7"),
+.peri_base = 0x3f00,
+.ctrl_base = 0x4000,
 .clusterid = 0xf,
 },
 #ifdef TARGET_AARCH64
 {
 .name = TYPE_BCM2837,
 .cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"),
+.peri_base = 0x3f00,
+.ctrl_base = 0x4000,
 .clusterid = 0x0,
 },
 #endif
@@ -104,7 +104,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 }
 
 sysbus_mmio_map_overlap(SYS_BUS_DEVICE(&s->peripherals), 0,
-BCM2836_PERI_BASE, 1);
+info->peri_base, 1);
 
 /* bcm2836 interrupt controller (and mailboxes, etc.) */
 object_property_set_bool(OBJECT(&s->control), true, "realized", &err);
@@ -113,7 +113,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 return;
 }
 
-sysbus_mmio_map(SYS_BUS_DEVICE(&s->control), 0, BCM2836_CONTROL_BASE);
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->control), 0, info->ctrl_base);
 
 sysbus_connect_irq(SYS_BUS_DEVICE(&s->peripherals), 0,
 qdev_get_gpio_in_named(DEVICE(&s->control), "gpu-irq", 0));
@@ -126,7 +126,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 
 /* set periphbase/CBAR value for CPU-local registers */
 object_property_set_int(OBJECT(&s->cpus[n]),
-BCM2836_PERI_BASE + MSYNC_OFFSET,
+info->peri_base,
 "reset-cbar", &err);
 if (err) {
 error_propagate(errp, err);
-- 
2.21.0

[PATCH v3 06/16] hw/arm/bcm2836: Rename cpus[] as cpu[].core

[Philippe Mathieu-Daudé]

As we are going to add more core-specific fields, add a 'cpu'
structure and move the ARMCPU field there as 'core'.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2836.c | 26 ++
 include/hw/arm/bcm2836.h |  4 +++-
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index 019e67b906..221ff06895 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -51,8 +51,9 @@ static void bcm2836_init(Object *obj)
 int n;
 
 for (n = 0; n < BCM283X_NCPUS; n++) {
-object_initialize_child(obj, "cpu[*]", &s->cpus[n], sizeof(s->cpus[n]),
-info->cpu_type, &error_abort, NULL);
+object_initialize_child(obj, "cpu[*]", &s->cpu[n].core,
+sizeof(s->cpu[n].core), info->cpu_type,
+&error_abort, NULL);
 }
 
 sysbus_init_child_obj(obj, "control", &s->control, sizeof(s->control),
@@ -122,10 +123,10 @@ static void bcm2836_realize(DeviceState *dev, Error 
**errp)
 
 for (n = 0; n < BCM283X_NCPUS; n++) {
 /* TODO: this should be converted to a property of ARM_CPU */
-s->cpus[n].mp_affinity = (info->clusterid << 8) | n;
+s->cpu[n].core.mp_affinity = (info->clusterid << 8) | n;
 
 /* set periphbase/CBAR value for CPU-local registers */
-object_property_set_int(OBJECT(&s->cpus[n]),
+object_property_set_int(OBJECT(&s->cpu[n].core),
 info->peri_base,
 "reset-cbar", &err);
 if (err) {
@@ -134,14 +135,15 @@ static void bcm2836_realize(DeviceState *dev, Error 
**errp)
 }
 
 /* start powered off if not enabled */
-object_property_set_bool(OBJECT(&s->cpus[n]), n >= s->enabled_cpus,
+object_property_set_bool(OBJECT(&s->cpu[n].core), n >= s->enabled_cpus,
  "start-powered-off", &err);
 if (err) {
 error_propagate(errp, err);
 return;
 }
 
-object_property_set_bool(OBJECT(&s->cpus[n]), true, "realized", &err);
+object_property_set_bool(OBJECT(&s->cpu[n].core), true,
+ "realized", &err);
 if (err) {
 error_propagate(errp, err);
 return;
@@ -149,18 +151,18 @@ static void bcm2836_realize(DeviceState *dev, Error 
**errp)
 
 /* Connect irq/fiq outputs from the interrupt controller. */
 qdev_connect_gpio_out_named(DEVICE(&s->control), "irq", n,
-qdev_get_gpio_in(DEVICE(&s->cpus[n]), ARM_CPU_IRQ));
+qdev_get_gpio_in(DEVICE(&s->cpu[n].core), ARM_CPU_IRQ));
 qdev_connect_gpio_out_named(DEVICE(&s->control), "fiq", n,
-qdev_get_gpio_in(DEVICE(&s->cpus[n]), ARM_CPU_FIQ));
+qdev_get_gpio_in(DEVICE(&s->cpu[n].core), ARM_CPU_FIQ));
 
 /* Connect timers from the CPU to the interrupt controller */
-qdev_connect_gpio_out(DEVICE(&s->cpus[n]), GTIMER_PHYS,
+qdev_connect_gpio_out(DEVICE(&s->cpu[n].core), GTIMER_PHYS,
 qdev_get_gpio_in_named(DEVICE(&s->control), "cntpnsirq", n));
-qdev_connect_gpio_out(DEVICE(&s->cpus[n]), GTIMER_VIRT,
+qdev_connect_gpio_out(DEVICE(&s->cpu[n].core), GTIMER_VIRT,
 qdev_get_gpio_in_named(DEVICE(&s->control), "cntvirq", n));
-qdev_connect_gpio_out(DEVICE(&s->cpus[n]), GTIMER_HYP,
+qdev_connect_gpio_out(DEVICE(&s->cpu[n].core), GTIMER_HYP,
 qdev_get_gpio_in_named(DEVICE(&s->control), "cnthpirq", n));
-qdev_connect_gpio_out(DEVICE(&s->cpus[n]), GTIMER_SEC,
+qdev_connect_gpio_out(DEVICE(&s->cpu[n].core), GTIMER_SEC,
 qdev_get_gpio_in_named(DEVICE(&s->control), "cntpsirq", n));
 }
 }
diff --git a/include/hw/arm/bcm2836.h b/include/hw/arm/bcm2836.h
index 97187f72be..92a6544816 100644
--- a/include/hw/arm/bcm2836.h
+++ b/include/hw/arm/bcm2836.h
@@ -35,7 +35,9 @@ typedef struct BCM283XState {
 char *cpu_type;
 uint32_t enabled_cpus;
 
-ARMCPU cpus[BCM283X_NCPUS];
+struct {
+ARMCPU core;
+} cpu[BCM283X_NCPUS];
 BCM2836ControlState control;
 BCM2835PeripheralState peripherals;
 } BCM283XState;
-- 
2.21.0

[PATCH v3 03/16] hw/timer/bcm2835: Add the BCM2835 SYS_timer

[Philippe Mathieu-Daudé]

Add the 64-bit free running timer. Do not model the COMPARE register
(no IRQ generated).
This timer is used by Linux kernel and recently U-Boot:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clocksource/bcm2835_timer.c?h=v3.7
https://github.com/u-boot/u-boot/blob/v2019.07/include/configs/rpi.h#L19

Datasheet used:
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Signed-off-by: Philippe Mathieu-Daudé 
---
v2:
- Add status/compare* registers
- Add vmstate and reset handler

checkpatch warning:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
This is OK because the regex are:

  F: hw/*/bcm283*
  F: include/hw/*/bcm283*
---
 hw/timer/Makefile.objs|   1 +
 hw/timer/bcm2835_systmr.c | 166 ++
 hw/timer/trace-events |   5 +
 include/hw/timer/bcm2835_systmr.h |  33 ++
 4 files changed, 205 insertions(+)
 create mode 100644 hw/timer/bcm2835_systmr.c
 create mode 100644 include/hw/timer/bcm2835_systmr.h

diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 123d92c969..696cda5905 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -47,3 +47,4 @@ common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
 common-obj-$(CONFIG_CMSDK_APB_TIMER) += cmsdk-apb-timer.o
 common-obj-$(CONFIG_CMSDK_APB_DUALTIMER) += cmsdk-apb-dualtimer.o
 common-obj-$(CONFIG_MSF2) += mss-timer.o
+common-obj-$(CONFIG_RASPI) += bcm2835_systmr.o
diff --git a/hw/timer/bcm2835_systmr.c b/hw/timer/bcm2835_systmr.c
new file mode 100644
index 00..49b40b55f9
--- /dev/null
+++ b/hw/timer/bcm2835_systmr.c
@@ -0,0 +1,166 @@
+/*
+ * BCM2835 SYS timer emulation
+ *
+ * Copyright (C) 2019 Philippe Mathieu-Daudé 
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Datasheet: BCM2835 ARM Peripherals (C6357-M-1398)
+ * https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
+ *
+ * Only the free running 64-bit counter is implemented.
+ * The 4 COMPARE registers and the interruption are not implemented.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qemu/timer.h"
+#include "hw/timer/bcm2835_systmr.h"
+#include "hw/registerfields.h"
+#include "migration/vmstate.h"
+#include "trace.h"
+
+REG32(CTRL_STATUS,  0x00)
+REG32(COUNTER_LOW,  0x04)
+REG32(COUNTER_HIGH, 0x08)
+REG32(COMPARE0, 0x0c)
+REG32(COMPARE1, 0x10)
+REG32(COMPARE2, 0x14)
+REG32(COMPARE3, 0x18)
+
+static void bcm2835_systmr_update_irq(BCM2835SystemTimerState *s)
+{
+bool enable = !!s->reg.status;
+
+trace_bcm2835_systmr_irq(enable);
+qemu_set_irq(s->irq, enable);
+}
+
+static void bcm2835_systmr_update_compare(BCM2835SystemTimerState *s,
+  unsigned timer_index)
+{
+/* TODO fow now, since neither Linux nor U-boot use these timers. */
+qemu_log_mask(LOG_UNIMP, "COMPARE register %u not implemented\n",
+  timer_index);
+}
+
+static uint64_t bcm2835_systmr_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+BCM2835SystemTimerState *s = BCM2835_SYSTIMER(opaque);
+uint64_t r = 0;
+
+switch (offset) {
+case A_CTRL_STATUS:
+r = s->reg.status;
+break;
+case A_COMPARE0 ... A_COMPARE3:
+r = s->reg.compare[(offset - A_COMPARE0) >> 2];
+break;
+case A_COUNTER_LOW:
+case A_COUNTER_HIGH:
+/* Free running counter at 1MHz */
+r = qemu_clock_get_us(QEMU_CLOCK_VIRTUAL);
+r >>= 8 * (offset - A_COUNTER_LOW);
+r &= UINT32_MAX;
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: bad offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+break;
+}
+trace_bcm2835_systmr_read(offset, r);
+
+return r;
+}
+
+static void bcm2835_systmr_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+BCM2835SystemTimerState *s = BCM2835_SYSTIMER(opaque);
+
+trace_bcm2835_systmr_write(offset, value);
+switch (offset) {
+case A_CTRL_STATUS:
+s->reg.status &= ~value; /* Ack */
+bcm2835_systmr_update_irq(s);
+break;
+case A_COMPARE0 ... A_COMPARE3:
+s->reg.compare[(offset - A_COMPARE0) >> 2] = value;
+bcm2835_systmr_update_compare(s, (offset - A_COMPARE0) >> 2);
+break;
+case A_COUNTER_LOW:
+case A_COUNTER_HIGH:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: read-only ofs 0x%" HWADDR_PRIx 
"\n",
+  __func__, offset);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: bad offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+break;
+}
+}
+
+static const MemoryRegionOps bcm2835_systmr_ops = {
+.read = bcm2835_systmr_read,
+.write = bcm2835_systmr_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.impl = {
+.min_access_size = 4,
+.max

[PATCH v3 00/16] hw/arm/raspi: Add thermal/timer, improve address space, run U-boot

[Philippe Mathieu-Daudé]

Since v2:
- fixed issue in videocore address space
- allow to start with some cores OFF (to boot firmwares)
- add proof-of-concept test for '-smp cores=1' and U-boot
- fixed my email setup

Previous cover:

Hi,

Some patches from v1 are already merged. This v2 addresses the
review comment from v1, and add patches to clean the memory
space when using multiple cores.

Laurent, if you test U-Boot with this patchset again, do you mind
replying with a "Tested-by:" tag?

The next patchset is probably about the interrupt controller blocks,
then will come another one about the MBox/Properties.

The last patch is unrelated to the series, but since I cleaned this
for the raspi and the highbank is the only board with the same issue,
I included the patch in this series.

Please review.

Regards,

Phil.

$ git backport-diff -u v2
001/16:[] [--] 'hw/misc/bcm2835_thermal: Add a dummy BCM2835 thermal sensor'
002/16:[] [--] 'hw/arm/bcm2835_peripherals: Use the thermal sensor block'
003/16:[] [--] 'hw/timer/bcm2835: Add the BCM2835 SYS_timer'
004/16:[] [--] 'hw/arm/bcm2835_peripherals: Use the SYS_timer'
005/16:[] [--] 'hw/arm/bcm2836: Make the SoC code modular'
006/16:[down] 'hw/arm/bcm2836: Rename cpus[] as cpu[].core'
007/16:[0053] [FC] 'hw/arm/bcm2836: Use per CPU address spaces'
008/16:[down] 'hw/arm/bcm2835_peripherals: Add const link property in realize()'
009/16:[0105] [FC] 'hw/arm/bcm2836: Create VideoCore address space in the SoC'
010/16:[] [--] 'hw/arm/raspi: Use AddressSpace when using 
arm_boot::write_secondary_boot'
011/16:[down] 'hw/arm/raspi: Use -smp cores= option to restrict enabled 
cores'
012/16:[down] 'hw/arm/bcm2836: Rename enabled_cpus -> enabled_cores'
013/16:[] [-C] 'hw/arm/raspi: Make the board code modular'
014/16:[] [--] 'hw/arm/highbank: Use AddressSpace when using 
write_secondary_boot()'
015/16:[down] 'python/qemu/machine: Allow to use other serial consoles than 
default'
016/16:[down] 'NOTFORMERGE tests/acceptance: Test U-boot on the Raspberry Pi 3'

v2: https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04474.html

Philippe Mathieu-Daudé (16):
  hw/misc/bcm2835_thermal: Add a dummy BCM2835 thermal sensor
  hw/arm/bcm2835_peripherals: Use the thermal sensor block
  hw/timer/bcm2835: Add the BCM2835 SYS_timer
  hw/arm/bcm2835_peripherals: Use the SYS_timer
  hw/arm/bcm2836: Make the SoC code modular
  hw/arm/bcm2836: Rename cpus[] as cpu[].core
  hw/arm/bcm2836: Use per CPU address spaces
  hw/arm/bcm2835_peripherals: Add const link property in realize()
  hw/arm/bcm2836: Create VideoCore address space in the SoC
  hw/arm/raspi: Use AddressSpace when using
arm_boot::write_secondary_boot
  hw/arm/raspi: Use -smp cores= option to restrict enabled cores
  hw/arm/bcm2836: Rename enabled_cpus -> enabled_cores
  hw/arm/raspi: Make the board code modular
  hw/arm/highbank: Use AddressSpace when using write_secondary_boot()
  python/qemu/machine: Allow to use other serial consoles than default
  NOTFORMERGE tests/acceptance: Test U-boot on the Raspberry Pi 3

 hw/arm/bcm2835_peripherals.c   |  76 +++
 hw/arm/bcm2836.c   | 119 ++
 hw/arm/highbank.c  |   3 +-
 hw/arm/raspi.c | 127 +++
 hw/misc/Makefile.objs  |   1 +
 hw/misc/bcm2835_thermal.c  | 135 
 hw/timer/Makefile.objs |   1 +
 hw/timer/bcm2835_systmr.c  | 166 +
 hw/timer/trace-events  |   5 +
 include/hw/arm/bcm2835_peripherals.h   |   9 +-
 include/hw/arm/bcm2836.h   |  17 ++-
 include/hw/arm/raspi_platform.h|   1 +
 include/hw/misc/bcm2835_thermal.h  |  27 
 include/hw/timer/bcm2835_systmr.h  |  33 +
 python/qemu/machine.py |   9 +-
 tests/acceptance/boot_linux_console.py |  23 
 16 files changed, 671 insertions(+), 81 deletions(-)
 create mode 100644 hw/misc/bcm2835_thermal.c
 create mode 100644 hw/timer/bcm2835_systmr.c
 create mode 100644 include/hw/misc/bcm2835_thermal.h
 create mode 100644 include/hw/timer/bcm2835_systmr.h

-- 
2.21.0

[PATCH v3 01/16] hw/misc/bcm2835_thermal: Add a dummy BCM2835 thermal sensor

[Philippe Mathieu-Daudé]

We will soon implement the SYS_timer. This timer is used by Linux
in the thermal subsystem, so once available, the subsystem will be
enabled and poll the temperature sensors. We need to provide the
minimum required to keep Linux booting.

Add a dummy thermal sensor returning ~25°C based on:
https://github.com/raspberrypi/linux/blob/rpi-5.3.y/drivers/thermal/broadcom/bcm2835_thermal.c

Signed-off-by: Philippe Mathieu-Daudé 
---
v2:
- Explicit g_assert_not_reached() with comment (Alex)
- Add vmstate and reset handler (Peter)

checkpatch warning:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
This is OK because the regex are:

  F: hw/*/bcm283*
  F: include/hw/*/bcm283*
---
 hw/misc/Makefile.objs |   1 +
 hw/misc/bcm2835_thermal.c | 135 ++
 include/hw/misc/bcm2835_thermal.h |  27 ++
 3 files changed, 163 insertions(+)
 create mode 100644 hw/misc/bcm2835_thermal.c
 create mode 100644 include/hw/misc/bcm2835_thermal.h

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index a150680966..c89f3816a5 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -53,6 +53,7 @@ common-obj-$(CONFIG_OMAP) += omap_tap.o
 common-obj-$(CONFIG_RASPI) += bcm2835_mbox.o
 common-obj-$(CONFIG_RASPI) += bcm2835_property.o
 common-obj-$(CONFIG_RASPI) += bcm2835_rng.o
+common-obj-$(CONFIG_RASPI) += bcm2835_thermal.o
 common-obj-$(CONFIG_SLAVIO) += slavio_misc.o
 common-obj-$(CONFIG_ZYNQ) += zynq_slcr.o
 common-obj-$(CONFIG_ZYNQ) += zynq-xadc.o
diff --git a/hw/misc/bcm2835_thermal.c b/hw/misc/bcm2835_thermal.c
new file mode 100644
index 00..c6f3b1ad60
--- /dev/null
+++ b/hw/misc/bcm2835_thermal.c
@@ -0,0 +1,135 @@
+/*
+ * BCM2835 dummy thermal sensor
+ *
+ * Copyright (C) 2019 Philippe Mathieu-Daudé 
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qapi/error.h"
+#include "hw/misc/bcm2835_thermal.h"
+#include "hw/registerfields.h"
+#include "migration/vmstate.h"
+
+REG32(CTL, 0)
+FIELD(CTL, POWER_DOWN, 0, 1)
+FIELD(CTL, RESET, 1, 1)
+FIELD(CTL, BANDGAP_CTRL, 2, 3)
+FIELD(CTL, INTERRUPT_ENABLE, 5, 1)
+FIELD(CTL, DIRECT, 6, 1)
+FIELD(CTL, INTERRUPT_CLEAR, 7, 1)
+FIELD(CTL, HOLD, 8, 10)
+FIELD(CTL, RESET_DELAY, 18, 8)
+FIELD(CTL, REGULATOR_ENABLE, 26, 1)
+
+REG32(STAT, 4)
+FIELD(STAT, DATA, 0, 10)
+FIELD(STAT, VALID, 10, 1)
+FIELD(STAT, INTERRUPT, 11, 1)
+
+#define THERMAL_OFFSET_C 412
+#define THERMAL_COEFF  (-0.538f)
+
+static uint16_t bcm2835_thermal_temp2adc(int temp_C)
+{
+return (temp_C - THERMAL_OFFSET_C) / THERMAL_COEFF;
+}
+
+static uint64_t bcm2835_thermal_read(void *opaque, hwaddr addr, unsigned size)
+{
+Bcm2835ThermalState *s = BCM2835_THERMAL(opaque);
+uint32_t val = 0;
+
+switch (addr) {
+case A_CTL:
+val = s->ctl;
+break;
+case A_STAT:
+/* Temperature is constantly 25°C. */
+val = FIELD_DP32(bcm2835_thermal_temp2adc(25), STAT, VALID, true);
+break;
+default:
+/* MemoryRegionOps are aligned, so this can not happen. */
+g_assert_not_reached();
+}
+return val;
+}
+
+static void bcm2835_thermal_write(void *opaque, hwaddr addr,
+  uint64_t value, unsigned size)
+{
+Bcm2835ThermalState *s = BCM2835_THERMAL(opaque);
+
+switch (addr) {
+case A_CTL:
+s->ctl = value;
+break;
+case A_STAT:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: write 0x%" PRIx64
+   " to 0x%" HWADDR_PRIx "\n",
+   __func__, value, addr);
+break;
+default:
+/* MemoryRegionOps are aligned, so this can not happen. */
+g_assert_not_reached();
+}
+}
+
+static const MemoryRegionOps bcm2835_thermal_ops = {
+.read = bcm2835_thermal_read,
+.write = bcm2835_thermal_write,
+.impl.max_access_size = 4,
+.valid.min_access_size = 4,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void bcm2835_thermal_reset(DeviceState *dev)
+{
+Bcm2835ThermalState *s = BCM2835_THERMAL(dev);
+
+s->ctl = 0;
+}
+
+static void bcm2835_thermal_realize(DeviceState *dev, Error **errp)
+{
+Bcm2835ThermalState *s = BCM2835_THERMAL(dev);
+
+memory_region_init_io(&s->iomem, OBJECT(s), &bcm2835_thermal_ops,
+  s, TYPE_BCM2835_THERMAL, 8);
+sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->iomem);
+}
+
+static const VMStateDescription bcm2835_thermal_vmstate = {
+.name = "bcm2835_thermal",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(ctl, Bcm2835ThermalState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void bcm2835_thermal_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->realize = bcm2835_thermal_realize;
+dc->reset = bcm2835_thermal_reset;
+dc->vmsd = &bcm2835_thermal_vmstate;
+}
+
+static const TypeInfo 

Fwd: IGD assignment / Legacy Mode Question

[nicolas prochazka]

Hello,
We are using IGD legacy assignment to start our Vm  on Intel nuc
platform ( generation 7, 8 ) with succes.
However, in some cases, we must set rombar to off and sometime rombar
set to on in order to start the Vm.

We are using Windows 10 :
according to the hardware ( intel nuc 6,7,8 generation, other
plateforme as asus PN60 )
- Rombar must be set to on or off  , ( off can block at seabios level)
- When rombar is set to on, there's no windows boot logon ( vga not
detect ? , if rombar set to off, vga boot is present )

Is there any explanation to these strange behaviour, or just Intel Igd ?


Regards,
Nicolas Prochazka


Libvirt Xml :
Important point :



















=> Qemu log / seabios seems to be block


2019-10-07 12:39:58.384+: starting up libvirt version: 5.2.0, qemu
version: 4.1.0, kernel: 4.19.75, hostname: -DELL5590
LC_ALL=C \
PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
\
HOME=/var/lib/libvirt/qemu/domain-4-W10 \
USER=root \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-W10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-W10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-W10/.config \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-kvm.igd \
-name guest=W10,debug-threads=on \
-S \
-object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-W10/master-key.aes
\
-machine pc-i440fx-2.11,accel=kvm,usb=off,dump-guest-core=off \
-cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1000,hv_vpindex,hv_runtime,hv_synic,hv_reset
\
-bios /usr/share/seabios/bios.bin \
-m 6413 \
-mem-prealloc \
-mem-path /dev/hugepages/libvirt/qemu/4-W10 \
-realtime mlock=off \
-smp 6,sockets=1,cores=6,threads=1 \
-uuid 0414a538-bab4-3456-87f1-b8271b4b018d \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=25,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime \
-no-shutdown \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=1 \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \
-drive 
file=/data/VMS/W10/hda.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback
\
-device 
virtio-blk-pci,scsi=off,num-queues=4,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
\
-drive 
file=/data/VMS/W10/swap.qcow2,format=qcow2,if=none,id=drive-virtio-disk1,cache=unsafe
\
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on
\
-netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 \
-device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=ac:de:50:65:9f:5d,bus=pci.0,addr=0x3
\
-chardev socket,id=charchannel0,fd=29,server,nowait \
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
-device 
virtio-input-host-pci,id=input0,evdev=/dev/input/event4,bus=pci.0,addr=0x11
\
-device 
virtio-input-host-pci,id=input1,evdev=/dev/input/event5,bus=pci.0,addr=0x12
\
-device 
vfio-pci,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,rombar=0,romfile=/data/ROOT/templates/romIgd.03441V
\
-device vfio-pci,host=00:14.0,id=hostdev1,bus=pci.0,addr=0x7 \
-device vfio-pci,host=00:1f.3,id=hostdev2,bus=pci.0,addr=0x8 \
-device vfio-pci,host=02:00.0,id=hostdev3,bus=pci.0,addr=0x9 \
'-netdev 
user,id=user.0,restrict=on,hostfwd=tcp:127.0.0.1:5901-:5900,hostfwd=tcp:127.0.0.1:3389-:3389
-device virtio-net-pci,netdev=user.0' \
-set device.hostdev0.x-igd-gms=1 \
'-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios' \
-msg timestamp=on
2019-10-07 12:39:58.384+: Domain id=4 is tainted: high-privileges
2019-10-07 12:39:58.384+: Domain id=4 is tainted: custom-argv
2019-10-07 12:39:58.384+: Domain id=4 is tainted: host-cpu
qemu-system-x86_64.igd: -realtime mlock=off: warning: '-realtime
mlock=...' is deprecated, please use '-overcommit mem-lock=...'
instead
qemu_madvise: Invalid argument
madvise doesn't support MADV_DONTDUMP, but dump_guest_core=off specified
2019-10-07T12:39:59.942833Z qemu-system-x86_64.igd: vfio: Cannot reset
device :00:1f.3, no available reset mechanism.
2019-10-07T12:39:59.982817Z qemu-system-x86_64.igd: vfio: Cannot reset
device :00:14.0, no available reset mechanism.
2019-10-07T12:40:00.143566Z qemu-system-x86_64.igd: vfio: Cannot reset
device :00:1f.3, no available reset mechanism.
2019-10-07T12:40:00.143718Z qemu-system-x86_64.igd: vfio: Cannot reset
device :00:14.0, no available reset mechanism.
SeaBIOS (version 1.12.0-20191007_112719-localhost.localdomain)
BUILD: gcc: (Gentoo 7.3.0-r3 p1.4) 7.3.0 binutils: (Gentoo 2.24 p1.4) 2.24
No Xen hypervisor found.
RamSize: 0xc000 [cmos]
Relocating init from 0x000d88c0

Re: [PATCH 0/1] Update Bulgarian translation

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191019120534.27479-1-...@kambanaria.org/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  TESTiotest-qcow2: 010
  TESTcheck-qtest-x86_64: tests/ahci-test
test-aio-multithread: /tmp/qemu-test/src/util/async.c:283: aio_ctx_finalize: 
Assertion `!qemu_lockcnt_count(&ctx->list_lock)' failed.
ERROR - too few tests run (expected 6, got 2)
make: *** [check-unit] Error 1
make: *** Waiting for unfinished jobs
  TESTiotest-qcow2: 011
  TESTiotest-qcow2: 012
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=3135277df6de454d88bf6c095990791b', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-zj9rltvl/src/docker-src.2019-10-19-18.17.34.25692:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=3135277df6de454d88bf6c095990791b
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-zj9rltvl/src'
make: *** [docker-run-test-quick@centos7] Error 2

real11m37.398s
user0m9.811s


The full log is available at
http://patchew.org/logs/20191019120534.27479-1-...@kambanaria.org/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v7 3/3] target/ppc: Optimize emulation of vupkhpx and vupklpx instructions

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> 'trans_vupkpx' function implements both vupkhpx and vupklpx instructions
> with
> argument 'high' determine which instruction is processed. Instructions are
> implemented in two 'for' loops. Outer 'for' loop repeats unpacking two
> times,
> since both doubleword elements of destination register are formed the same
> way.
> It also stores result of every iteration in temporary register, that is
> later
> transferred to destination register. Inner 'for' loop does unpacking of
> pixels
> and forms resulting doubleword 32 by 32 bits.
>
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  2 -
>  target/ppc/int_helper.c | 20 
>  target/ppc/translate/vmx-impl.inc.c | 91 ++
> ++-
>  3 files changed, 89 insertions(+), 24 deletions(-)
>
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index b489b38..fd06b56 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -233,8 +233,6 @@ DEF_HELPER_2(vextsh2d, void, avr, avr)
>  DEF_HELPER_2(vextsw2d, void, avr, avr)
>  DEF_HELPER_2(vnegw, void, avr, avr)
>  DEF_HELPER_2(vnegd, void, avr, avr)
> -DEF_HELPER_2(vupkhpx, void, avr, avr)
> -DEF_HELPER_2(vupklpx, void, avr, avr)
>  DEF_HELPER_2(vupkhsb, void, avr, avr)
>  DEF_HELPER_2(vupkhsh, void, avr, avr)
>  DEF_HELPER_2(vupkhsw, void, avr, avr)
> diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
> index f910c11..9ee667d 100644
> --- a/target/ppc/int_helper.c
> +++ b/target/ppc/int_helper.c
> @@ -1737,26 +1737,6 @@ void helper_vsum4ubs(CPUPPCState *env, ppc_avr_t
> *r, ppc_avr_t *a, ppc_avr_t *b)
>  #define UPKHI 0
>  #define UPKLO 1
>  #endif
> -#define VUPKPX(suffix, hi)  \
> -void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> -{   \
> -int i;  \
> -ppc_avr_t result;   \
> -\
> -for (i = 0; i < ARRAY_SIZE(r->u32); i++) {  \
> -uint16_t e = b->u16[hi ? i : i + 4];\
> -uint8_t a = (e >> 15) ? 0xff : 0;   \
> -uint8_t r = (e >> 10) & 0x1f;   \
> -uint8_t g = (e >> 5) & 0x1f;\
> -uint8_t b = e & 0x1f;   \
> -\
> -result.u32[i] = (a << 24) | (r << 16) | (g << 8) | b;   \
> -}   \
> -*r = result;\
> -}
> -VUPKPX(lpx, UPKLO)
> -VUPKPX(hpx, UPKHI)
> -#undef VUPKPX
>
>  #define VUPK(suffix, unpacked, packee, hi)  \
>  void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> diff --git a/target/ppc/translate/vmx-impl.inc.c
> b/target/ppc/translate/vmx-impl.inc.c
> index 3550ffa..09d80d6 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -1031,6 +1031,95 @@ static void trans_vclzd(DisasContext *ctx)
>  tcg_temp_free_i64(avr);
>  }
>
> +/*
> + * vupkhpx VRT,VRB - Vector Unpack High Pixel
> + * vupklpx VRT,VRB - Vector Unpack Low Pixel
> + *
> + * Unpacks 4 pixels coded in 1-5-5-5 pattern from high/low doubleword
> element
> + * of source register into contigous array of bits in the destination
> register.
> + * Argument 'high' determines if high or low doubleword element of source
> + * register is processed.
> + */
> +static void trans_vupkpx(DisasContext *ctx, int high)


The last argument should be boolean.


> +{
> +int VT = rD(ctx->opcode);
> +int VB = rB(ctx->opcode);
> +TCGv_i64 tmp = tcg_temp_new_i64();
> +TCGv_i64 avr = tcg_temp_new_i64();
> +TCGv_i64 result = tcg_temp_new_i64();
> +TCGv_i64 result1 = tcg_temp_new_i64();
> +TCGv_i64 result2 = tcg_temp_new_i64();
> +int64_t mask1 = 0x1fULL;
> +int64_t mask2 = 0x1fULL << 8;
> +int64_t mask3 = 0x1fULL << 16;
> +int64_t mask4 = 0xffULL << 56;
> +int i, j;
> +
> +if (high == 1) {
> +get_avr64(avr, VB, true);
> +} else {
> +get_avr64(avr, VB, false);
> +}
> +
> +tcg_gen_movi_i64(result, 0x0ULL);
> +for (i = 0; i < 2; i++) {
> +for (j = 0; j < 2; j++) {
> +tcg_gen_shli_i64(tmp, avr, (j * 16));
> +tcg_gen_andi_i64(tmp, tmp, mask1 << (j * 32));
> +tcg_gen_or_i64(result, result, tmp);
> +
> +tcg_gen_shli_i64(tmp, avr, 3 + (j * 16));
> +tcg_gen_andi_i64(tmp, tmp, mask2 << (j * 32));
> +tcg_gen_

Re: [PATCH v32 04/13] target/avr: Add instruction translation - Registers definition

[Michael Rolnik]

On Fri, Oct 18, 2019 at 9:08 PM Aleksandar Markovic
 wrote:
>
>
>
> On Friday, October 18, 2019, Aleksandar Markovic 
>  wrote:
>>
>>
>>
>> On Friday, October 18, 2019, Michael Rolnik  wrote:
>>>
>>> On Fri, Oct 18, 2019 at 4:23 PM Aleksandar Markovic
>>>  wrote:
>>> >
>>> >
>>> >
>>> > On Friday, October 18, 2019, Michael Rolnik  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Oct 18, 2019 at 11:52 AM Aleksandar Markovic 
>>> >>  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thursday, October 17, 2019, Michael Rolnik  wrote:
>>> 
>>>  On Thu, Oct 17, 2019 at 11:17 PM Aleksandar Markovic
>>>   wrote:
>>>  >>
>>>  >>
>>>  >> >> +static TCGv cpu_Cf;
>>>  >> >> +static TCGv cpu_Zf;
>>>  >> >> +static TCGv cpu_Nf;
>>>  >> >> +static TCGv cpu_Vf;
>>>  >> >> +static TCGv cpu_Sf;
>>>  >> >> +static TCGv cpu_Hf;
>>>  >> >> +static TCGv cpu_Tf;
>>>  >> >> +static TCGv cpu_If;
>>>  >> >> +
>>>  >> >
>>>  >> >
>>>  >> > Hello, Michael,
>>>  >> >
>>>  >> > Is there any particular reason or motivation beyond modelling 
>>>  >> > status register flags as TCGv variables?
>>>  >>
>>>  >>
>>>  >>
>>>  >> I think it's easier this way as I don't need to convert flag values 
>>>  >> to
>>>  >> bits or bits to flag values.
>>>  >
>>>  >
>>>  > Ok. But, how do you map 0/1 flag value to the value of a TCGv 
>>>  > variable and vice versa? In other words, what value or values (out 
>>>  > of 2^32 vales) of a TCGv variable mean the flag is 1? And the same 
>>>  > question for 0.
>>>  >
>>>  > Is 01111110100 one or zero?
>>>  >
>>>  > Besides, in such arrangement, how do you display the 8-bit status 
>>>  > register in gdb, if at all?
>>> 
>>>  each flag register is either 0 or 1,
>>> 
>>> 
>>> 
>>> >>>
>>> >>> Michael,
>>> >>>
>>> >>> If this is true, why is there a special handling of two flags in the 
>>> >>> following code:
>>> >>>
>>> >>>
>>> >>> static inline uint8_t cpu_get_sreg(CPUAVRState *env)
>>> >>> {
>>> >>> uint8_t sreg;
>>> >>> sreg = (env->sregC & 0x01) << 0
>>> >>> | (env->sregZ == 0 ? 1 : 0) << 1
>>> >>> | (env->sregN) << 2
>>> >>> | (env->sregV) << 3
>>> >>> | (env->sregS) << 4
>>> >>> | (env->sregH) << 5
>>> >>> | (env->sregT) << 6
>>> >>> | (env->sregI) << 7;
>>> >>> return sreg;
>>> >>> }
>>> >>> static inline void cpu_set_sreg(CPUAVRState *env, uint8_t sreg)
>>> >>> {
>>> >>> env->sregC = (sreg >> 0) & 0x01;
>>> >>> env->sregZ = (sreg >> 1) & 0x01 ? 0 : 1;
>>> >>> env->sregN = (sreg >> 2) & 0x01;
>>> >>> env->sregV = (sreg >> 3) & 0x01;
>>> >>> env->sregS = (sreg >> 4) & 0x01;
>>> >>> env->sregH = (sreg >> 5) & 0x01;
>>> >>> env->sregT = (sreg >> 6) & 0x01;
>>> >>> env->sregI = (sreg >> 7) & 0x01;
>>> >>> }
>>> >>>  ?
>>> >>>
>>> >> Aleksandar,
>>> >>
>>> >> If I understand your question correctly cpu_get_sreg assembles SREG 
>>> >> value to be presented by GDB, and cpu_set_sreg sets flags values when 
>>> >> GDB modifies SREG.
>>> >>
>>> >> Michael
>>> >
>>> >
>>> >
>>> >
>>>
>>> Why is handling of sregC and sregZ flags different than handling of other 
>>> flags? This contradicts your previos statement that 1 (in TCGv) means 1 
>>> (flag), and 0 (in TCGv) means 0 (flag)?
>>> >
>>> >
>>> > Whatever is the explanation, ot should be included, in my opinion, in 
>>> > code comments.
>>> >
>>> > Please, Michael, let's first clarify the issue from the question above.
>>> >
>>> > Thanks, Aleksandar
>>> >
>>> >
>>> there is a comment here
>>> https://github.com/michaelrolnik/qemu-avr/blob/master/target/avr/cpu.h#L122-L129
>>> >
>>
>>
>>
>> ...but it does explain WHY of my question.
>
>
> I meant to say  "does not", not "does".
>
> Michael, don't be discouraged by lenghty review process, just be persistent 
> and available for communication with reviewers.
>
> Sincerely,
> Aleksandar
>
>

Aleksandar,

I will try to explain my reasoning for the current implementation.
1. Many (or even the majority) of instructions modify flags, i.e. the
flags value should be computed regardless whether they are used or
not.
2. SREG as a whole is almost never used except
a. GDB
b. IN, OUT, SBI, CBI, SBIC, SBIS instructions as 1 out of 8
possible registers.

So, as we can see flags are calculated more times then they are used.
This leads us to two following conclusions
1. don't maintain SREG as one register but as a set of 8 different registers
2. try to minimize number of calculations for these flags

All flags except Z (zero) are calculated fully and kept as one bit
Z just holds the result of last computation, so Z flag is set when
sregZ register is 0 otherwise the flag is not set.
that's why there is difference between Z and others.

so, you are right, there is no need to treat C differently. I will
send an update later.

Thanks.

Michael Rolnik




>>
>>
>> The reason I insist on your explanation is that when we model a cpu or a 
>> device in QEMU, a goal 

Re: [PATCH v7 3/3] target/ppc: Optimize emulation of vupkhpx and vupklpx instructions

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> 'trans_vupkpx' function implements both vupkhpx and vupklpx instructions
> with
> argument 'high' determine which instruction is processed. Instructions are
> implemented in two 'for' loops. Outer 'for' loop repeats unpacking two
> times,
> since both doubleword elements of destination register are formed the same
> way.
> It also stores result of every iteration in temporary register, that is
> later
> transferred to destination register. Inner 'for' loop does unpacking of
> pixels
> and forms resulting doubleword 32 by 32 bits.
>
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  2 -
>  target/ppc/int_helper.c | 20 
>  target/ppc/translate/vmx-impl.inc.c | 91 ++
> ++-
>  3 files changed, 89 insertions(+), 24 deletions(-)
>
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index b489b38..fd06b56 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -233,8 +233,6 @@ DEF_HELPER_2(vextsh2d, void, avr, avr)
>  DEF_HELPER_2(vextsw2d, void, avr, avr)
>  DEF_HELPER_2(vnegw, void, avr, avr)
>  DEF_HELPER_2(vnegd, void, avr, avr)
> -DEF_HELPER_2(vupkhpx, void, avr, avr)
> -DEF_HELPER_2(vupklpx, void, avr, avr)
>  DEF_HELPER_2(vupkhsb, void, avr, avr)
>  DEF_HELPER_2(vupkhsh, void, avr, avr)
>  DEF_HELPER_2(vupkhsw, void, avr, avr)
> diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
> index f910c11..9ee667d 100644
> --- a/target/ppc/int_helper.c
> +++ b/target/ppc/int_helper.c
> @@ -1737,26 +1737,6 @@ void helper_vsum4ubs(CPUPPCState *env, ppc_avr_t
> *r, ppc_avr_t *a, ppc_avr_t *b)
>  #define UPKHI 0
>  #define UPKLO 1
>  #endif
> -#define VUPKPX(suffix, hi)  \
> -void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> -{   \
> -int i;  \
> -ppc_avr_t result;   \
> -\
> -for (i = 0; i < ARRAY_SIZE(r->u32); i++) {  \
> -uint16_t e = b->u16[hi ? i : i + 4];\
> -uint8_t a = (e >> 15) ? 0xff : 0;   \
> -uint8_t r = (e >> 10) & 0x1f;   \
> -uint8_t g = (e >> 5) & 0x1f;\
> -uint8_t b = e & 0x1f;   \
> -\
> -result.u32[i] = (a << 24) | (r << 16) | (g << 8) | b;   \
> -}   \
> -*r = result;\
> -}
> -VUPKPX(lpx, UPKLO)
> -VUPKPX(hpx, UPKHI)
> -#undef VUPKPX
>
>  #define VUPK(suffix, unpacked, packee, hi)  \
>  void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> diff --git a/target/ppc/translate/vmx-impl.inc.c
> b/target/ppc/translate/vmx-impl.inc.c
> index 3550ffa..09d80d6 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -1031,6 +1031,95 @@ static void trans_vclzd(DisasContext *ctx)
>  tcg_temp_free_i64(avr);
>  }
>
> +/*
> + * vupkhpx VRT,VRB - Vector Unpack High Pixel
> + * vupklpx VRT,VRB - Vector Unpack Low Pixel
> + *
> + * Unpacks 4 pixels coded in 1-5-5-5 pattern from high/low doubleword
> element
> + * of source register into contigous array of bits in the destination
> register.
> + * Argument 'high' determines if high or low doubleword element of source
> + * register is processed.
> + */
> +static void trans_vupkpx(DisasContext *ctx, int high)
> +{
> +int VT = rD(ctx->opcode);
> +int VB = rB(ctx->opcode);
> +TCGv_i64 tmp = tcg_temp_new_i64();
> +TCGv_i64 avr = tcg_temp_new_i64();
> +TCGv_i64 result = tcg_temp_new_i64();
> +TCGv_i64 result1 = tcg_temp_new_i64();
> +TCGv_i64 result2 = tcg_temp_new_i64();
> +int64_t mask1 = 0x1fULL;
> +int64_t mask2 = 0x1fULL << 8;
> +int64_t mask3 = 0x1fULL << 16;
> +int64_t mask4 = 0xffULL << 56;
> +int i, j;
> +
> +if (high == 1) {
> +get_avr64(avr, VB, true);
> +} else {
> +get_avr64(avr, VB, false);
> +}
> +
> +tcg_gen_movi_i64(result, 0x0ULL);
> +for (i = 0; i < 2; i++) {
> +for (j = 0; j < 2; j++) {
> +tcg_gen_shli_i64(tmp, avr, (j * 16));
> +tcg_gen_andi_i64(tmp, tmp, mask1 << (j * 32));
> +tcg_gen_or_i64(result, result, tmp);
> +
> +tcg_gen_shli_i64(tmp, avr, 3 + (j * 16));
> +tcg_gen_andi_i64(tmp, tmp, mask2 << (j * 32));
> +tcg_gen_or_i64(result, result, tmp);
> +
> + 

Re: [PATCH v7 0/3] target/ppc: Optimize emulation of some Altivec instructions

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> Optimize emulation of ten Altivec instructions: lvsl, lvsr, vsl, vsr,
> vpkpx,
> vgbbd, vclzb, vclzh, vclzw, vclzd, vupkhpx and vupklpx.
>
>
ten -> twelve



> This series buils up on and complements


>
buils -> builds


>
recent work of Thomas Murta, Mark
> Cave-Ayland and Richard Henderson in the same area. It is based on
> devising TCG
> translation implementation for selected instructions rather than using
> helpers.
> The selected instructions are most of the time idiosyncratic to ppc
> platform,
> so relatively complex TCG translation (without direct mapping to host
> instruction that is not possible in these cases) seems to be the best
> option,
> and that approach is presented in this series. The performance improvements
> are significant in all cases.
>
> V7:
>
> Added optimization for vupkhpx and vupklpx instructions.
>
> V6:
>
> Rebased series to the latest qemu code.
> Excluded all patches that are already accepted.
>
> V5:
>
> Fixed vpkpx bug and added it back in patch.
> Fixed graphical distortions on OSX 10.3 and 10.4.
> Removed conversion of vmrgh and vmrgl instructions to vector operations for
> further investigation.
>
> V4:
>
> Addressed Richard's Henderson's

suggestions.
> Removed vpkpx's optimization for further investigation on graphical
> distortions
> it caused on OSX 10.2-4 guests.
> Added opcodes for vector vmrgh(b|h|w) and vmrgl(b|h|w) in tcg.
> Implemented vector vmrgh and vmrgl instructions for i386.
> Converted vmrgh and vmrgl instructions to vector operations.
>
> V3:
>
> Fixed problem during build.
>
> V2:
>
> Addressed Richard's Henderson's suggestions.
> Fixed problem during build on patch 2/8.
> Rebased series to the latest qemu code.
>
> Stefan Brankovic (3):
>   target/ppc: Optimize emulation of vclzh and vclzb instructions
>   target/ppc: Optimize emulation of vpkpx instruction
>   target/ppc: Optimize emulation of vupkhpx and vupklpx instructions
>
>  target/ppc/helper.h |   5 -
>  target/ppc/int_helper.c |  50 --
>  target/ppc/translate/vmx-impl.inc.c | 326 ++
> +-
>  3 files changed, 321 insertions(+), 60 deletions(-)
>
> --
> 2.7.4
>
>
>

Re: [PATCH v7 1/3] target/ppc: Optimize emulation of vclzh and vclzb instructions

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> Optimize Altivec instruction vclzh (Vector Count Leading Zeros Halfword).
> This instruction counts the number of leading zeros of each halfword
> element
> in source register and places result in the appropriate halfword element of
> destination register.
>
> In each iteration of outer for loop count operation is performed on one
> doubleword element of source register vB. In the first iteration, higher
> doubleword element of vB is placed in variable avr, and then counting
> for every halfword element is performed by  using tcg_gen_clzi_i64.
> Since it counts leading zeros on 64 bit lenght, ith byte element has to
> be moved to the highest 16 bits of tmp, or-ed with mask(in order to get all
> ones in lowest 48 bits), then perform tcg_gen_clzi_i64 and move it's result
> in appropriate halfword element of result. This is done in inner for loop.
> After the operation is finished, the result is saved in the appropriate
> doubleword element of destination register vD. The same sequence of orders
> is to be applied again for the  lower doubleword element of vB.
>
> Optimize Altivec instruction vclzb (Vector Count Leading Zeros Byte).
> This instruction counts the number of leading zeros of each byte element
> in source register and places result in the appropriate byte element of
> destination register.
>
> In each iteration of the outer for loop, counting operation is done on one
> doubleword element of source register vB. In the first iteration, the
> higher doubleword element of vB is placed in variable avr, and then
> counting
> for every byte element is performed using tcg_gen_clzi_i64. Since it counts
> leading zeros on 64 bit lenght, ith byte element has to be moved to the
> highest
> 8 bits of variable  tmp, ored with mask(in order to get all ones in the
> lowest
> 56 bits), then perform tcg_gen_clzi_i64 and move it's result in the
> appropriate
> byte element of result. This is done in inner for loop. After the
> operation is
> finished, the result is saved in the  appropriate doubleword element of
> destination
> register vD. The same sequence of orders is to be applied again for the
> lower
> doubleword element of vB.
>
>
The same hints as for the commit message of patch 2/3.

Additionally, the first and the third paragraph should be merged into a
single one at the beggining of the commit message


Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |   2 -
>  target/ppc/int_helper.c |   9 ---
>  target/ppc/translate/vmx-impl.inc.c | 136 ++
> +-
>  3 files changed, 134 insertions(+), 13 deletions(-)
>
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index f843814..281e54f 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -308,8 +308,6 @@ DEF_HELPER_4(vcfsx, void, env, avr, avr, i32)
>  DEF_HELPER_4(vctuxs, void, env, avr, avr, i32)
>  DEF_HELPER_4(vctsxs, void, env, avr, avr, i32)
>
> -DEF_HELPER_2(vclzb, void, avr, avr)
> -DEF_HELPER_2(vclzh, void, avr, avr)
>  DEF_HELPER_2(vctzb, void, avr, avr)
>  DEF_HELPER_2(vctzh, void, avr, avr)
>  DEF_HELPER_2(vctzw, void, avr, avr)
> diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
> index 6d238b9..cd00f5e 100644
> --- a/target/ppc/int_helper.c
> +++ b/target/ppc/int_helper.c
> @@ -1817,15 +1817,6 @@ VUPK(lsw, s64, s32, UPKLO)
>  }   \
>  }
>
> -#define clzb(v) ((v) ? clz32((uint32_t)(v) << 24) : 8)
> -#define clzh(v) ((v) ? clz32((uint32_t)(v) << 16) : 16)
> -
> -VGENERIC_DO(clzb, u8)
> -VGENERIC_DO(clzh, u16)
> -
> -#undef clzb
> -#undef clzh
> -
>  #define ctzb(v) ((v) ? ctz32(v) : 8)
>  #define ctzh(v) ((v) ? ctz32(v) : 16)
>  #define ctzw(v) ctz32((v))
> diff --git a/target/ppc/translate/vmx-impl.inc.c
> b/target/ppc/translate/vmx-impl.inc.c
> index 2472a52..a428ef3 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -751,6 +751,138 @@ static void trans_vgbbd(DisasContext *ctx)
>  }
>
>  /*
> + * vclzb VRT,VRB - Vector Count Leading Zeros Byte
> + *
> + * Counting the number of leading zero bits of each byte element in source
> + * register and placing result in appropriate byte element of destination
> + * register.
> + */
> +static void trans_vclzb(DisasContext *ctx)
> +{
> +int VT = rD(ctx->opcode);
> +int VB = rB(ctx->opcode);
> +TCGv_i64 avr = tcg_temp_new_i64();
> +TCGv_i64 result = tcg_temp_new_i64();
> +TCGv_i64 result1 = tcg_temp_new_i64();
> +TCGv_i64 result2 = tcg_temp_new_i64();
> +TCGv_i64 tmp = tcg_temp_new_i64();
> +TCGv_i64 mask = tcg_const_i64(0xffULL);
> +int i, j;
> +
> +for (i = 0; i < 2; i++) {
> +if (i == 0) {
> +/* Get high doubleword of vB in 'avr'. */
> +get_avr64(avr, VB, true);
> +} else {
> +/* Get low doubleword of vB in 'avr'. */
> +  

Re: [PATCH v7 2/3] target/ppc: Optimize emulation of vpkpx instruction

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> Optimize altivec instruction vpkpx (Vector Pack Pixel).
> Rearranges 8 pixels coded in 6-5-5 pattern (4 from each source register)
> into contigous array of bits in the destination register.
>
> In each iteration of outer loop, the instruction is to be done with
> the 6-5-5 pack for 2 pixels of each doubleword element of each
> source register. The first thing to be done in outer loop is
> choosing which doubleword element of which register is to be used
> in current iteration and it is to be placed in avr variable. The
> next step is to perform 6-5-5 pack of pixels on avr variable in inner
> for loop(2 iterations, 1 for each pixel) and save result in tmp variable.
> In the end of outer for loop, the result is merged in variable called
> result and saved in appropriate doubleword element of vD if the whole
> doubleword is finished(every second iteration). The outer loop has 4
> iterations.
>
>
Check spelling.

Use single quotation marks around variavle names and other code elements.

avr variable-> variable 'avr' (and several similar instances)


> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  1 -
>  target/ppc/int_helper.c | 21 
>  target/ppc/translate/vmx-impl.inc.c | 99 ++
> ++-
>  3 files changed, 98 insertions(+), 23 deletions(-)
>
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index 281e54f..b489b38 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -258,7 +258,6 @@ DEF_HELPER_4(vpkudus, void, env, avr, avr, avr)
>  DEF_HELPER_4(vpkuhum, void, env, avr, avr, avr)
>  DEF_HELPER_4(vpkuwum, void, env, avr, avr, avr)
>  DEF_HELPER_4(vpkudum, void, env, avr, avr, avr)
> -DEF_HELPER_3(vpkpx, void, avr, avr, avr)
>  DEF_HELPER_5(vmhaddshs, void, env, avr, avr, avr, avr)
>  DEF_HELPER_5(vmhraddshs, void, env, avr, avr, avr, avr)
>  DEF_HELPER_5(vmsumuhm, void, env, avr, avr, avr, avr)
> diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
> index cd00f5e..f910c11 100644
> --- a/target/ppc/int_helper.c
> +++ b/target/ppc/int_helper.c
> @@ -1262,27 +1262,6 @@ void helper_vpmsumd(ppc_avr_t *r, ppc_avr_t *a,
> ppc_avr_t *b)
>  #else
>  #define PKBIG 0
>  #endif
> -void helper_vpkpx(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
> -{
> -int i, j;
> -ppc_avr_t result;
> -#if defined(HOST_WORDS_BIGENDIAN)
> -const ppc_avr_t *x[2] = { a, b };
> -#else
> -const ppc_avr_t *x[2] = { b, a };
> -#endif
> -
> -VECTOR_FOR_INORDER_I(i, u64) {
> -VECTOR_FOR_INORDER_I(j, u32) {
> -uint32_t e = x[i]->u32[j];
> -
> -result.u16[4 * i + j] = (((e >> 9) & 0xfc00) |
> - ((e >> 6) & 0x3e0) |
> - ((e >> 3) & 0x1f));
> -}
> -}
> -*r = result;
> -}
>
>  #define VPK(suffix, from, to, cvt, dosat)   \
>  void helper_vpk##suffix(CPUPPCState *env, ppc_avr_t *r, \
> diff --git a/target/ppc/translate/vmx-impl.inc.c
> b/target/ppc/translate/vmx-impl.inc.c
> index a428ef3..3550ffa 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -579,6 +579,103 @@ static void trans_lvsr(DisasContext *ctx)
>  }
>
>  /*
> + * vpkpx VRT,VRA,VRB - Vector Pack Pixel
> + *
> + * Rearranges 8 pixels coded in 6-5-5 pattern (4 from each source
> register)
> + * into contigous array of bits in the destination register.
> + */
> +static void trans_vpkpx(DisasContext *ctx)
> +{
> +int VT = rD(ctx->opcode);
> +int VA = rA(ctx->opcode);
> +int VB = rB(ctx->opcode);
> +TCGv_i64 tmp = tcg_temp_new_i64();
> +TCGv_i64 shifted = tcg_temp_new_i64();
> +TCGv_i64 avr = tcg_temp_new_i64();
> +TCGv_i64 result = tcg_temp_new_i64();
> +TCGv_i64 result1 = tcg_temp_new_i64();
> +TCGv_i64 result2 = tcg_temp_new_i64();


'result2' is not needed, 'result' can be used in the final half instead all
the way up to the coping to the destination.


> +int64_t mask1 = 0x1fULL;
> +int64_t mask2 = 0x1fULL << 5;
> +int64_t mask3 = 0x3fULL << 10;
> +int i, j;
> +/*
> + * In each iteration do the 6-5-5 pack for 2 pixels of each doubleword
> + * element of each source register.
> + */
> +for (i = 0; i < 4; i++) {
> +switch (i) {
> +case 0:
> +/*
> + * Get high doubleword of vA to perform 6-5-5 pack of pixels
> + * 1 and 2.
> + */
> +get_avr64(avr, VA, true);
> +tcg_gen_movi_i64(result, 0x0ULL);
> +break;
> +case 1:
> +/*
> + * Get low doubleword of vA to perform 6-5-5 pack of pixels
> + * 3 and 4.
> + */
> +get_avr64(avr, VA, false);
> +break;
> +case 2:
> +/*
> + * Get high doubleword of vB to perform 6-5-5 pack of pi

Re: [PATCH v7 3/3] target/ppc: Optimize emulation of vupkhpx and vupklpx instructions

[Aleksandar Markovic]

On Thursday, October 17, 2019, Stefan Brankovic 
wrote:

> 'trans_vupkpx' function implements both vupkhpx and vupklpx instructions
> with


implements both -> implements emulation of both

with -> , while its

argument 'high' determine which


determine -> determines


> instruction is processed. Instructions are
> implemented in two 'for' loops. Outer 'for' loop repeats unpacking two
> times,
> since both doubleword elements of destination register are formed the same
> way.
> It also stores result of every iteration in temporary register, that is
> later
> transferred to destination register. Inner 'for' loop does unpacking of
> pixels
> and forms resulting doubleword 32 by 32 bits.


temporary register -> a temporary variable

destination register -> the destination register

'forms resulting doubleword 32 by 32 bits' is unclear, reword.


> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  2 -
>  target/ppc/int_helper.c | 20 
>  target/ppc/translate/vmx-impl.inc.c | 91 ++
> ++-
>  3 files changed, 89 insertions(+), 24 deletions(-)
>
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index b489b38..fd06b56 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -233,8 +233,6 @@ DEF_HELPER_2(vextsh2d, void, avr, avr)
>  DEF_HELPER_2(vextsw2d, void, avr, avr)
>  DEF_HELPER_2(vnegw, void, avr, avr)
>  DEF_HELPER_2(vnegd, void, avr, avr)
> -DEF_HELPER_2(vupkhpx, void, avr, avr)
> -DEF_HELPER_2(vupklpx, void, avr, avr)
>  DEF_HELPER_2(vupkhsb, void, avr, avr)
>  DEF_HELPER_2(vupkhsh, void, avr, avr)
>  DEF_HELPER_2(vupkhsw, void, avr, avr)
> diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
> index f910c11..9ee667d 100644
> --- a/target/ppc/int_helper.c
> +++ b/target/ppc/int_helper.c
> @@ -1737,26 +1737,6 @@ void helper_vsum4ubs(CPUPPCState *env, ppc_avr_t
> *r, ppc_avr_t *a, ppc_avr_t *b)
>  #define UPKHI 0
>  #define UPKLO 1
>  #endif
> -#define VUPKPX(suffix, hi)  \
> -void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> -{   \
> -int i;  \
> -ppc_avr_t result;   \
> -\
> -for (i = 0; i < ARRAY_SIZE(r->u32); i++) {  \
> -uint16_t e = b->u16[hi ? i : i + 4];\
> -uint8_t a = (e >> 15) ? 0xff : 0;   \
> -uint8_t r = (e >> 10) & 0x1f;   \
> -uint8_t g = (e >> 5) & 0x1f;\
> -uint8_t b = e & 0x1f;   \
> -\
> -result.u32[i] = (a << 24) | (r << 16) | (g << 8) | b;   \
> -}   \
> -*r = result;\
> -}
> -VUPKPX(lpx, UPKLO)
> -VUPKPX(hpx, UPKHI)
> -#undef VUPKPX
>
>  #define VUPK(suffix, unpacked, packee, hi)  \
>  void helper_vupk##suffix(ppc_avr_t *r, ppc_avr_t *b)\
> diff --git a/target/ppc/translate/vmx-impl.inc.c
> b/target/ppc/translate/vmx-impl.inc.c
> index 3550ffa..09d80d6 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -1031,6 +1031,95 @@ static void trans_vclzd(DisasContext *ctx)
>  tcg_temp_free_i64(avr);
>  }
>
> +/*
> + * vupkhpx VRT,VRB - Vector Unpack High Pixel
> + * vupklpx VRT,VRB - Vector Unpack Low Pixel
> + *
> + * Unpacks 4 pixels coded in 1-5-5-5 pattern from high/low doubleword
> element
> + * of source register into contigous array of bits in the destination
> register.
> + * Argument 'high' determines if high or low doubleword element of source
> + * register is processed.
> + */
> +static void trans_vupkpx(DisasContext *ctx, int high)
> +{
> +int VT = rD(ctx->opcode);
> +int VB = rB(ctx->opcode);
> +TCGv_i64 tmp = tcg_temp_new_i64();
> +TCGv_i64 avr = tcg_temp_new_i64();
> +TCGv_i64 result = tcg_temp_new_i64();
> +TCGv_i64 result1 = tcg_temp_new_i64();
> +TCGv_i64 result2 = tcg_temp_new_i64();
> +int64_t mask1 = 0x1fULL;
> +int64_t mask2 = 0x1fULL << 8;
> +int64_t mask3 = 0x1fULL << 16;
> +int64_t mask4 = 0xffULL << 56;

+int i, j;
> +
> +if (high == 1) {
> +get_avr64(avr, VB, true);


before this line, insert comment: /* vupkhpx */


> +} else {
> +get_avr64(avr, VB, false);


before this line, insert comment: /* vupklpx */


> +}
> +
> +tcg_gen_movi_i64(result, 0x0ULL);
> +for (i = 0; i < 2; i++) {
> +for (j = 0; j < 2;

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
> On 19/10/2019 17:31, Marty E. Plummer wrote:
> > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> >> On 18/10/2019 19:28, Marty E. Plummer wrote:
> >>> Hello,
> >>>
> >>> First off, thank you for the work you've done on the ppc64 support, it
> >>> has been very useful. I'm currently working on a coreboot port for the
> >>> talos ii line of systems (which means more ppc64 support, support
> >>> specifically for the power9 sforza chip, and specific mainboard support.
> >>> My plate is very full lol) and have been using qemu to debug the
> >>> bootblock.
> >>>
> >>> It has been very useful for that, but I'm now at the point where I need
> >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom
> >>> image and looks for a ffs header, locates skiboot on it, and jumps 
> >>> straight
> >>> to that. Not exactly ideal for debugging something not produced from 
> >>> op-build.
> >>
> >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> >> flash and extract the kernel and initramfs from the PNOR.
> >>
> >> However, you can bypass all this internal boot process by simply passing
> >> a -bios option and not passing a MTD device.
> >>
> > Doing so gives me the following error:
> > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> > (this is after I patched the 4mb size limit up)
> 
Oof. My bad, I had only patched the 4.1.0 package, not the live sources
from your tree.
> Could you make that rom available ? 
> 
Turns out the 'not text' warning came from lists.sr.ht, I wonder why
that mailed me.
> Thanks,
> 
> C. 

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
> On 19/10/2019 17:31, Marty E. Plummer wrote:
> > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> >> On 18/10/2019 19:28, Marty E. Plummer wrote:
> >>> Hello,
> >>>
> >>> First off, thank you for the work you've done on the ppc64 support, it
> >>> has been very useful. I'm currently working on a coreboot port for the
> >>> talos ii line of systems (which means more ppc64 support, support
> >>> specifically for the power9 sforza chip, and specific mainboard support.
> >>> My plate is very full lol) and have been using qemu to debug the
> >>> bootblock.
> >>>
> >>> It has been very useful for that, but I'm now at the point where I need
> >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom
> >>> image and looks for a ffs header, locates skiboot on it, and jumps 
> >>> straight
> >>> to that. Not exactly ideal for debugging something not produced from 
> >>> op-build.
> >>
> >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> >> flash and extract the kernel and initramfs from the PNOR.
> >>
> >> However, you can bypass all this internal boot process by simply passing
> >> a -bios option and not passing a MTD device.
> >>
> > Doing so gives me the following error:
> > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> > (this is after I patched the 4mb size limit up)
> 
> Could you make that rom available ? 
> 
Sent it, but the ml kicked back a 'hey, that's not a normal text file'
error, could you confirm if you personally got it?
> Thanks,
> 
> C. 

Re: [PATCH v5 04/13] hw/core: add Resettable support to BusClass and DeviceClass

[Richard Henderson]

On 10/18/19 8:06 AM, Damien Hedde wrote:
> This commit adds support of Resettable interface to buses and devices:
> + ResettableState structure is added in the Bus/Device state
> + Resettable methods are implemented.
> + device/bus_is_in_reset function defined
> 
> This commit allows to transition the objects to the new
> multi-phase interface without changing the reset behavior at all.
> Object single reset method can be split into the 3 different phases
> but the 3 phases are still executed in a row for a given object.
> From the qdev/qbus reset api point of view, nothing is changed.
> qdev_reset_all() and qbus_reset_all() are not modified as well as
> device_legacy_reset().
> 
> Transition of an object must be done from mother class to daughter
> classes. Care has been taken to allow the transition of a mother class
> without requiring the daughter classes to be transitioned at the same
> time. Note that SysBus and SysBusDevice class do not need any transition
> because they do not override the legacy reset method.
> 
> Signed-off-by: Damien Hedde 
> ---
>  hw/core/bus.c  | 97 ++
>  hw/core/qdev.c | 97 ++
>  include/hw/qdev-core.h | 27 
>  tests/Makefile.include |  1 +
>  4 files changed, 222 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v5 02/13] hw/core/qdev: add trace events to help with resettable transition

[Richard Henderson]

On 10/18/19 8:06 AM, Damien Hedde wrote:
> Adds trace events to reset procedure and when updating the parent
> bus of a device.
> 
> Signed-off-by: Damien Hedde 
> ---
>  hw/core/qdev.c   | 27 ---
>  hw/core/trace-events |  9 +
>  2 files changed, 33 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson 


r~

[PATCH] net: add tulip (dec21143) driver

[Sven Schnelle]

This adds the basic functionality to emulate a Tulip NIC.

Implemented are:

- RX and TX functionality
- Perfect Frame Filtering
- Big/Little Endian descriptor support
- 93C46 EEPROM support
- LXT970 PHY

Not implemented, mostly because i had no OS using these functions:

- Imperfect frame filtering
- General Purpose Timer
- Transmit automatic polling
- Boot ROM support
- SIA interface
- Big/Little Endian data buffer conversion

Successfully tested with the following Operating Systems:

- MSDOS with Microsoft Network Client 3.0 and DEC ODI drivers
- HPPA Linux
- Windows XP
- HP-UX

Signed-off-by: Sven Schnelle 
---
 MAINTAINERS  |   6 +
 hw/net/Kconfig   |   5 +
 hw/net/Makefile.objs |   1 +
 hw/net/trace-events  |  14 +
 hw/net/tulip.c   | 992 +++
 hw/net/tulip.h   | 265 +++
 include/hw/pci/pci_ids.h |   1 +
 7 files changed, 1284 insertions(+)
 create mode 100644 hw/net/tulip.c
 create mode 100644 hw/net/tulip.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 250ce8e7a1..a12031c389 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1638,6 +1638,12 @@ M: Stefan Weil 
 S: Maintained
 F: hw/net/eepro100.c
 
+tulip
+M: Sven Schnelle 
+S: Maintained
+F: hw/net/tulip.c
+F: hw/net/tulip.h
+
 Generic Loader
 M: Alistair Francis 
 S: Maintained
diff --git a/hw/net/Kconfig b/hw/net/Kconfig
index 4ef86dc3a5..3856417d42 100644
--- a/hw/net/Kconfig
+++ b/hw/net/Kconfig
@@ -24,6 +24,11 @@ config PCNET_PCI
 config PCNET_COMMON
 bool
 
+config TULIP
+bool
+default y if PCI_DEVICES
+depends on PCI
+
 config E1000_PCI
 bool
 default y if PCI_DEVICES
diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
index 9904273b06..7907d2c199 100644
--- a/hw/net/Makefile.objs
+++ b/hw/net/Makefile.objs
@@ -13,6 +13,7 @@ common-obj-$(CONFIG_E1000E_PCI_EXPRESS) += e1000e.o 
e1000e_core.o e1000x_common.
 common-obj-$(CONFIG_RTL8139_PCI) += rtl8139.o
 common-obj-$(CONFIG_VMXNET3_PCI) += net_tx_pkt.o net_rx_pkt.o
 common-obj-$(CONFIG_VMXNET3_PCI) += vmxnet3.o
+common-obj-$(CONFIG_TULIP) += tulip.o
 
 common-obj-$(CONFIG_SMC91C111) += smc91c111.o
 common-obj-$(CONFIG_LAN9118) += lan9118.o
diff --git a/hw/net/trace-events b/hw/net/trace-events
index 58665655cc..e70f12bee1 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -367,3 +367,17 @@ virtio_net_announce_notify(void) ""
 virtio_net_announce_timer(int round) "%d"
 virtio_net_handle_announce(int round) "%d"
 virtio_net_post_load_device(void)
+
+# tulip.c
+tulip_reg_write(uint64_t addr, const char *name, int size, uint64_t val) "addr 
0x%02"PRIx64" (%s) size %d value 0x%08"PRIx64
+tulip_reg_read(uint64_t addr, const char *name, int size, uint64_t val) "addr 
0x%02"PRIx64" (%s) size %d value 0x%08"PRIx64
+tulip_receive(const uint8_t *buf, size_t len) "buf %p size %zu"
+tulip_descriptor(const char *prefix, uint32_t addr, uint32_t status, uint32_t 
control, uint32_t len1, uint32_t len2, uint32_t buf1, uint32_t buf2) "%s 
0x%08x: status 0x%08x control 0x%03x len1 %4d len2 %4d buf1 0x%08x buf2 0x%08x"
+tulip_rx_state(const char *state) "RX %s"
+tulip_tx_state(const char *state) "TX %s"
+tulip_irq(uint32_t mask, uint32_t en, const char *state) "mask 0x%08x ie 
0x%08x %s"
+tulip_mii_write(int phy, int reg, uint16_t data) "phy 0x%x reg 0x%x data 
0x%04x"
+tulip_mii_read(int phy, int reg, uint16_t data) "phy 0x%x, reg 0x%x data 
0x%04x"
+tulip_reset(void) ""
+tulip_setup_frame(void) ""
+tulip_setup_filter(int n, uint8_t a, uint8_t b, uint8_t c, uint8_t d, uint8_t 
e, uint8_t f) "%d: %02x:%02x:%02x:%02x:%02x:%02x"
diff --git a/hw/net/tulip.c b/hw/net/tulip.c
new file mode 100644
index 00..a99b1b81c4
--- /dev/null
+++ b/hw/net/tulip.c
@@ -0,0 +1,992 @@
+/*
+ * QEMU TULIP Emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle 
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/irq.h"
+#include "hw/pci/pci.h"
+#include "hw/qdev-properties.h"
+#include "hw/nvram/eeprom93xx.h"
+#include "migration/vmstate.h"
+#include "sysemu/sysemu.h"
+#include "tulip.h"
+#include "trace.h"
+#include "net/eth.h"
+
+typedef struct TULIPState {
+PCIDevice dev;
+MemoryRegion io;
+MemoryRegion memory;
+NICConf c;
+qemu_irq irq;
+NICState *nic;
+eeprom_t *eeprom;
+uint32_t csr[16];
+
+/* state for MII */
+uint32_t old_csr9;
+uint32_t mii_word;
+uint32_t mii_bitcnt;
+
+hwaddr current_rx_desc;
+hwaddr current_tx_desc;
+
+uint8_t rx_frame[2048];
+uint8_t tx_frame[2048];
+uint16_t tx_frame_len;
+uint16_t rx_frame_len;
+uint16_t rx_frame_size;
+
+uint32_t rx_status;
+uint8_t filter[16][6];
+} TULIPState;
+
+static const VMStateDescription vmstate_pci_tulip = {
+.name = "tulip",
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(dev, TULIPState),
+VMSTATE_UINT32_ARRAY(csr, TULIPState, 16),
+VMSTATE_UINT

Re: [PATCH v5 01/13] add device_legacy_reset function to prepare for reset api change

[Richard Henderson]

On 10/18/19 8:06 AM, Damien Hedde wrote:
> Provide a temporary device_legacy_reset function doing what
> device_reset does to prepare for the transition with Resettable
> API.
> 
> All occurrence of device_reset in the code tree are also replaced
> by device_legacy_reset.
> 
> The new resettable API has different prototype and semantics
> (resetting child buses as well as the specified device). Subsequent
> commits will make the changeover for each call site individually; once
> that is complete device_legacy_reset() will be removed.
> 
> Signed-off-by: Damien Hedde 
> Reviewed-by: Peter Maydell 
> Acked-by: David Gibson 
> ---

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v2 06/10] hw/arm/bcm2836: Create VideoCore address space in the SoC

[Richard Henderson]

On 10/17/19 3:57 PM, Philippe Mathieu-Daudé wrote:
> +static const char *alias_name[] = {
> +NULL, "cached-coherent", "cached", "uncached"
> +};

While respinning,

  static const char * const alias_name[]

r~

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
> On 19/10/2019 17:31, Marty E. Plummer wrote:
> > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> >> On 18/10/2019 19:28, Marty E. Plummer wrote:
> >>> Hello,
> >>>
> >>> First off, thank you for the work you've done on the ppc64 support, it
> >>> has been very useful. I'm currently working on a coreboot port for the
> >>> talos ii line of systems (which means more ppc64 support, support
> >>> specifically for the power9 sforza chip, and specific mainboard support.
> >>> My plate is very full lol) and have been using qemu to debug the
> >>> bootblock.
> >>>
> >>> It has been very useful for that, but I'm now at the point where I need
> >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom
> >>> image and looks for a ffs header, locates skiboot on it, and jumps 
> >>> straight
> >>> to that. Not exactly ideal for debugging something not produced from 
> >>> op-build.
> >>
> >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> >> flash and extract the kernel and initramfs from the PNOR.
> >>
> >> However, you can bypass all this internal boot process by simply passing
> >> a -bios option and not passing a MTD device.
> >>
> > Doing so gives me the following error:
> > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> > (this is after I patched the 4mb size limit up)
> 
> Could you make that rom available ? 
> 
Sure, I think. Not sure about how sending files works in my current mail
client but will see. Its more or less a 'stock' (as stock as can be for
a new coreboot target) coreboot.rom file, but I've added some logic into
the build to fake a pnor ffs header at the end in order to trick hostboot
bootloader into loading it.
> Thanks,
> 
> C. 


coreboot.rom.gz
Description: Binary data

Re: [PATCH 1/1] Updated Bulgarian translation (19) - 4.1.0

[Aleksandar Markovic]

On Saturday, October 19, 2019, Alexander Shopov  wrote:

> Signed-off-by: Alexander Shopov 
> ---
>  po/bg.po | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 

diff --git a/po/bg.po b/po/bg.po
> index 3d8c353372..98c57e5b22 100644
> --- a/po/bg.po
> +++ b/po/bg.po
> @@ -1,14 +1,14 @@
>  # Bulgarian translation of qemu po-file.
> -# Copyright (C) 2016 Alexander Shopov 
> +# Copyright (C) 2016, 2019 Alexander Shopov 
>  # This file is distributed under the same license as the qemu package.
> -# Alexander Shopov , 2016.
> +# Alexander Shopov , 2016, 2019.
>  #
>  msgid ""
>  msgstr ""
> -"Project-Id-Version: QEMU 2.6.50\n"
> +"Project-Id-Version: QEMU 4.1.0\n"
>  "Report-Msgid-Bugs-To: qemu-devel@nongnu.org\n"
>  "POT-Creation-Date: 2018-07-18 07:56+0200\n"
> -"PO-Revision-Date: 2016-06-09 15:54+0300\n"
> +"PO-Revision-Date: 2019-10-19 13:14+0200\n"
>  "Last-Translator: Alexander Shopov \n"
>  "Language-Team: Bulgarian \n"
>  "Language: bg\n"
> @@ -66,7 +66,7 @@ msgid "Detach Tab"
>  msgstr "Към самостоятелен подпрозорец"
>
>  msgid "Show Menubar"
> -msgstr ""
> +msgstr "Лента за менюто"
>
>  msgid "_Machine"
>  msgstr "_Машина"
> --
> 2.23.0
>
>
>

Re: [PATCH v2 10/11] tests/ssh_linux_malta: Refactor how to get image/kernel info

[Aleksandar Markovic]

On Saturday, October 19, 2019, Philippe Mathieu-Daudé 
wrote:

> The qcow and kernel images use a similar pattern regarding they
> are for big/little endianess, or 32/64 bit.
> Refactor using more dictionary keys.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 75 ++--
>  1 file changed, 44 insertions(+), 31 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 

diff --git a/tests/acceptance/linux_ssh_mips_malta.py
> b/tests/acceptance/linux_ssh_mips_malta.py
> index 822b0553ff..2139c80f5f 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -26,15 +26,44 @@ class LinuxSSH(Test):
>  KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
>  VM_IP = '127.0.0.1'
>
> +BASE_URL = 'https://people.debian.org/~aurel32/qemu/'
>  IMAGE_INFO = {
> -'be': {'image_url': ('https://people.debian.org/~
> aurel32/qemu/mips/'
> - 'debian_wheezy_mips_standard.qcow2'),
> -   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5'},
> -'le': {'image_url': ('https://people.debian.org/~
> aurel32/qemu/mipsel/'
> - 'debian_wheezy_mipsel_standard.qcow2'),
> -   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802'}
> +'be': {'base_url': 'mips',
> +   'image_name': 'debian_wheezy_mips_standard.qcow2',
> +   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5',
> +   'kernel_hash': {
> +   32: '592e384a4edc16dade52a6cd5c785c637bcbc9ad',
> +   64: 'db6eea7de35d36c77d8c165b6bcb222e16eb91db'}
> +  },
> +'le': {'base_url': 'mipsel',
> +   'image_name': 'debian_wheezy_mipsel_standard.qcow2',
> +   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802',
> +   'kernel_hash': {
> +   32: 'a66bea5a8adaa2cb3d36a1d4e0ccdb01be8f6c2a',
> +   64: '6a7f77245acf231415a0e8b725d91ed2f3487794'}
> +  }
> +}
> +CPU_INFO = {
> +32: {'kernel_release': '3.2.0-4-4kc-malta'},
> +64: {'kernel_release': '3.2.0-4-5kc-malta'}
>  }
>
> +def get_url(self, endianess, path=''):
> +qkey = {'le': 'el', 'be': ''}
> +return '%s/mips%s/%s' % (self.BASE_URL, qkey[endianess], path)
> +
> +def get_image_info(self, endianess):
> +dinfo = self.IMAGE_INFO[endianess]
> +image_url = self.get_url(endianess, dinfo['image_name'])
> +image_hash = dinfo['image_hash']
> +return (image_url, image_hash)
> +
> +def get_kernel_info(self, endianess, wordsize):
> +minfo = self.CPU_INFO[wordsize]
> +kernel_url = self.get_url(endianess,
> +  'vmlinux-%s' % minfo['kernel_release'])
> +kernel_hash = self.IMAGE_INFO[endianess]['kernel_hash'][wordsize]
> +return kernel_url, kernel_hash
>
>  @skipUnless(ssh.SSH_CLIENT_BINARY, 'No SSH client available')
>  @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might
> timeout')
> @@ -79,8 +108,7 @@ class LinuxSSH(Test):
>  return stdout_lines, stderr_lines
>
>  def boot_debian_wheezy_image_and_ssh_login(self, endianess,
> kernel_path):
> -image_url = self.IMAGE_INFO[endianess]['image_url']
> -image_hash = self.IMAGE_INFO[endianess]['image_hash']
> +image_url, image_hash = self.get_image_info(endianess)
>  image_path = self.fetch_asset(image_url, asset_hash=image_hash)
>
>  self.vm.set_machine('malta')
> @@ -172,7 +200,10 @@ class LinuxSSH(Test):
>  'md5sum /dev/mtd2ro',
>  '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
>
> -def check_mips_malta(self, endianess, kernel_path, uname_m):
> +def check_mips_malta(self, uname_m, endianess):
> +wordsize = 64 if '64' in uname_m else 32
> +kernel_url, kernel_hash = self.get_kernel_info(endianess,
> wordsize)
> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
>  self.boot_debian_wheezy_image_and_ssh_login(endianess,
> kernel_path)
>
>  stdout, _ = self.ssh_command('uname -a')
> @@ -188,12 +219,7 @@ class LinuxSSH(Test):
>  :avocado: tags=endian:big
>  :avocado: tags=device:pcnet32
>  """
> -kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
> -  'vmlinux-3.2.0-4-4kc-malta')
> -kernel_hash = '592e384a4edc16dade52a6cd5c785c637bcbc9ad'
> -kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> -
> -self.check_mips_malta('be', kernel_path, 'mips')
> +self.check_mips_malta('mips', 'be')
>
>  def test_mips_malta32el_kernel3_2_0(self):
>  """
> @@ -202,12 +228,7 @@ class LinuxSSH(Test):
>  :avocado: tags=endian:little
>  :avocado: tags=device:pcnet32
>  """
> -kernel_u

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

On 19/10/2019 17:31, Marty E. Plummer wrote:
> On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
>> On 18/10/2019 19:28, Marty E. Plummer wrote:
>>> Hello,
>>>
>>> First off, thank you for the work you've done on the ppc64 support, it
>>> has been very useful. I'm currently working on a coreboot port for the
>>> talos ii line of systems (which means more ppc64 support, support
>>> specifically for the power9 sforza chip, and specific mainboard support.
>>> My plate is very full lol) and have been using qemu to debug the
>>> bootblock.
>>>
>>> It has been very useful for that, but I'm now at the point where I need
>>> to jump to romstage, and that's where it gets tricky. qemu parses the rom
>>> image and looks for a ffs header, locates skiboot on it, and jumps straight
>>> to that. Not exactly ideal for debugging something not produced from 
>>> op-build.
>>
>> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
>> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
>> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
>> flash and extract the kernel and initramfs from the PNOR.
>>
>> However, you can bypass all this internal boot process by simply passing
>> a -bios option and not passing a MTD device.
>>
> Doing so gives me the following error:
> qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
> (this is after I patched the 4mb size limit up)

Could you make that rom available ? 

Thanks,

C. 

Re: [PATCH v2 07/11] tests/ssh_linux_malta: Run tests using a snapshot image

[Aleksandar Markovic]

On Saturday, October 19, 2019, Philippe Mathieu-Daudé 
wrote:

> If a test fails, it can corrupt the underlying QCow2 image,
> making further tests failing.
> Fix this by running each test with a snapshot.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/tests/acceptance/linux_ssh_mips_malta.py
> b/tests/acceptance/linux_ssh_mips_malta.py
> index ffbb06f846..27907e8fbd 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -90,7 +90,7 @@ class LinuxSSH(Test):
>  self.vm.add_args('-no-reboot',
>   '-kernel', kernel_path,
>   '-append', kernel_command_line,
> - '-hda', image_path,
> + '-drive', 'file=%s,snapshot=on' % image_path,
>   '-netdev', 'user,id=vnet,hostfwd=:127.0.
> 0.1:0-:22',
>   '-device', 'pcnet,netdev=vnet')
>  self.vm.launch()
> --
> 2.21.0
>
>
>

Re: [PATCH v2 08/11] tests/ssh_linux_malta: Remove duplicated test

[Aleksandar Markovic]

On Saturday, October 19, 2019, Philippe Mathieu-Daudé 
wrote:

> Remove duplicated test (probably copy/paste error in
> commit 9090d3332cdcc).
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 3 ---
>  1 file changed, 3 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/tests/acceptance/linux_ssh_mips_malta.py
> b/tests/acceptance/linux_ssh_mips_malta.py
> index 27907e8fbd..5523ae2144 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -140,9 +140,6 @@ class LinuxSSH(Test):
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
>  'eth0')
> -self.ssh_command_output_contains(
> -'cat /proc/interrupts',
> -'eth0')
>  self.ssh_command_output_contains(
>  'cat /proc/devices',
>  'input')
> --
> 2.21.0
>
>
>

Re: [PATCH v2 11/11] tests/ssh_linux_malta: Fix 64-bit target tests

[Aleksandar Markovic]

On Saturday, October 19, 2019, Philippe Mathieu-Daudé 
wrote:

> Commit 9090d3332cdcc added tests for specific to the 32-bit
> machines, which inadvertently make the 64-bit tests failing.
> Now than we have this information available in the CPU_INFO
> array, use it to have the 64-bit tests back.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v2: do not include Aleksandar Rikalo mailmap change
> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/tests/acceptance/linux_ssh_mips_malta.py
> b/tests/acceptance/linux_ssh_mips_malta.py
> index 2139c80f5f..fc13f9e4d4 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -44,8 +44,8 @@ class LinuxSSH(Test):
>}
>  }
>  CPU_INFO = {
> -32: {'kernel_release': '3.2.0-4-4kc-malta'},
> -64: {'kernel_release': '3.2.0-4-5kc-malta'}
> +32: {'cpu': 'MIPS 24Kc', 'kernel_release': '3.2.0-4-4kc-malta'},
> +64: {'cpu': 'MIPS 20Kc', 'kernel_release': '3.2.0-4-5kc-malta'}
>  }
>
>  def get_url(self, endianess, path=''):
> @@ -143,16 +143,16 @@ class LinuxSSH(Test):
>  else:
>  self.fail('"%s" output does not contain "%s"' % (cmd, exp))
>
> -def run_common_commands(self):
> +def run_common_commands(self, wordsize):
>  self.ssh_command_output_contains(
>  'cat /proc/cpuinfo',
> -'24Kc')
> +self.CPU_INFO[wordsize]['cpu'])
>  self.ssh_command_output_contains(
>  'uname -m',
>  'mips')
>  self.ssh_command_output_contains(
>  'uname -r',
> -'3.2.0-4-4kc-malta')
> +self.CPU_INFO[wordsize]['kernel_release'])
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
>  'XT-PIC  timer')
> @@ -209,7 +209,7 @@ class LinuxSSH(Test):
>  stdout, _ = self.ssh_command('uname -a')
>  self.assertIn(True, [uname_m + " GNU/Linux" in line for line in
> stdout])
>
> -self.run_common_commands()
> +self.run_common_commands(wordsize)
>  self.shutdown_via_ssh()
>
>  def test_mips_malta32eb_kernel3_2_0(self):
> --
> 2.21.0
>
>
>

Re: [PATCH v2 09/11] tests/ssh_linux_malta: Match stricter console output

[Aleksandar Markovic]

On Saturday, October 19, 2019, Philippe Mathieu-Daudé 
wrote:

> Match on stricter console output.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/tests/acceptance/linux_ssh_mips_malta.py
> b/tests/acceptance/linux_ssh_mips_malta.py
> index 5523ae2144..822b0553ff 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -127,19 +127,19 @@ class LinuxSSH(Test):
>  '3.2.0-4-4kc-malta')
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
> -'timer')
> +'XT-PIC  timer')
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
> -'i8042')
> +'XT-PIC  i8042')
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
> -'serial')
> +'XT-PIC  serial')
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
> -'ata_piix')
> +'XT-PIC  ata_piix')
>  self.ssh_command_output_contains(
>  'cat /proc/interrupts',
> -'eth0')
> +'XT-PIC  eth0')
>  self.ssh_command_output_contains(
>  'cat /proc/devices',
>  'input')
> @@ -151,13 +151,13 @@ class LinuxSSH(Test):
>  'fb')
>  self.ssh_command_output_contains(
>  'cat /proc/ioports',
> -'serial')
> +' : serial')
>  self.ssh_command_output_contains(
>  'cat /proc/ioports',
> -'ata_piix')
> +' : ata_piix')
>  self.ssh_command_output_contains(
>  'cat /proc/ioports',
> -'piix4_smbus')
> +' : piix4_smbus')
>  self.ssh_command_output_contains(
>  'lspci -d 11ab:4620',
>  'GT-64120')
> @@ -167,7 +167,7 @@ class LinuxSSH(Test):
>  self.ssh_command_output_contains(
>  'cat /proc/mtd',
>  'YAMON')
> -# Empty 'Board Config'
> +# Empty 'Board Config' (64KB)
>  self.ssh_command_output_contains(
>  'md5sum /dev/mtd2ro',
>  '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
> --
> 2.21.0
>
>
>

[PATCH v2 09/11] tests/ssh_linux_malta: Match stricter console output

[Philippe Mathieu-Daudé]

Match on stricter console output.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 5523ae2144..822b0553ff 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -127,19 +127,19 @@ class LinuxSSH(Test):
 '3.2.0-4-4kc-malta')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'timer')
+'XT-PIC  timer')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'i8042')
+'XT-PIC  i8042')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'serial')
+'XT-PIC  serial')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'ata_piix')
+'XT-PIC  ata_piix')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'eth0')
+'XT-PIC  eth0')
 self.ssh_command_output_contains(
 'cat /proc/devices',
 'input')
@@ -151,13 +151,13 @@ class LinuxSSH(Test):
 'fb')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'serial')
+' : serial')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'ata_piix')
+' : ata_piix')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'piix4_smbus')
+' : piix4_smbus')
 self.ssh_command_output_contains(
 'lspci -d 11ab:4620',
 'GT-64120')
@@ -167,7 +167,7 @@ class LinuxSSH(Test):
 self.ssh_command_output_contains(
 'cat /proc/mtd',
 'YAMON')
-# Empty 'Board Config'
+# Empty 'Board Config' (64KB)
 self.ssh_command_output_contains(
 'md5sum /dev/mtd2ro',
 '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
-- 
2.21.0

[PATCH v2 05/11] tests/boot_linux_console: Use Avocado archive::gzip_uncompress()

[Philippe Mathieu-Daudé]

Avocado 67.0 [*] introduced the avocado.utils.archive module which
provides handling of gzip files. Use the gzip_uncompress() method.

[*] 
https://avocado-framework.readthedocs.io/en/67.0/api/utils/avocado.utils.html#avocado.utils.archive.gzip_uncompress

Suggested-by: Cleber Rosa 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: New patch replacing the gunzip() refactor
---
 tests/acceptance/boot_linux_console.py | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 4b419b0559..67d7e96d98 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -145,10 +145,7 @@ class BootLinuxConsole(Test):
 initrd_hash = 'bf806e17009360a866bf537f6de66590de349a99'
 initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
 initrd_path = self.workdir + "rootfs.cpio"
-
-with gzip.open(initrd_path_gz, 'rb') as f_in:
-with open(initrd_path, 'wb') as f_out:
-shutil.copyfileobj(f_in, f_out)
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
 
 self.vm.set_machine('malta')
 self.vm.set_console()
-- 
2.21.0

[PATCH v2 11/11] tests/ssh_linux_malta: Fix 64-bit target tests

[Philippe Mathieu-Daudé]

Commit 9090d3332cdcc added tests for specific to the 32-bit
machines, which inadvertently make the 64-bit tests failing.
Now than we have this information available in the CPU_INFO
array, use it to have the 64-bit tests back.

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: do not include Aleksandar Rikalo mailmap change
---
 tests/acceptance/linux_ssh_mips_malta.py | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 2139c80f5f..fc13f9e4d4 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -44,8 +44,8 @@ class LinuxSSH(Test):
   }
 }
 CPU_INFO = {
-32: {'kernel_release': '3.2.0-4-4kc-malta'},
-64: {'kernel_release': '3.2.0-4-5kc-malta'}
+32: {'cpu': 'MIPS 24Kc', 'kernel_release': '3.2.0-4-4kc-malta'},
+64: {'cpu': 'MIPS 20Kc', 'kernel_release': '3.2.0-4-5kc-malta'}
 }
 
 def get_url(self, endianess, path=''):
@@ -143,16 +143,16 @@ class LinuxSSH(Test):
 else:
 self.fail('"%s" output does not contain "%s"' % (cmd, exp))
 
-def run_common_commands(self):
+def run_common_commands(self, wordsize):
 self.ssh_command_output_contains(
 'cat /proc/cpuinfo',
-'24Kc')
+self.CPU_INFO[wordsize]['cpu'])
 self.ssh_command_output_contains(
 'uname -m',
 'mips')
 self.ssh_command_output_contains(
 'uname -r',
-'3.2.0-4-4kc-malta')
+self.CPU_INFO[wordsize]['kernel_release'])
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
 'XT-PIC  timer')
@@ -209,7 +209,7 @@ class LinuxSSH(Test):
 stdout, _ = self.ssh_command('uname -a')
 self.assertIn(True, [uname_m + " GNU/Linux" in line for line in 
stdout])
 
-self.run_common_commands()
+self.run_common_commands(wordsize)
 self.shutdown_via_ssh()
 
 def test_mips_malta32eb_kernel3_2_0(self):
-- 
2.21.0

[PATCH v2 08/11] tests/ssh_linux_malta: Remove duplicated test

[Philippe Mathieu-Daudé]

Remove duplicated test (probably copy/paste error in
commit 9090d3332cdcc).

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 27907e8fbd..5523ae2144 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -140,9 +140,6 @@ class LinuxSSH(Test):
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
 'eth0')
-self.ssh_command_output_contains(
-'cat /proc/interrupts',
-'eth0')
 self.ssh_command_output_contains(
 'cat /proc/devices',
 'input')
-- 
2.21.0

[PATCH v2 07/11] tests/ssh_linux_malta: Run tests using a snapshot image

[Philippe Mathieu-Daudé]

If a test fails, it can corrupt the underlying QCow2 image,
making further tests failing.
Fix this by running each test with a snapshot.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index ffbb06f846..27907e8fbd 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -90,7 +90,7 @@ class LinuxSSH(Test):
 self.vm.add_args('-no-reboot',
  '-kernel', kernel_path,
  '-append', kernel_command_line,
- '-hda', image_path,
+ '-drive', 'file=%s,snapshot=on' % image_path,
  '-netdev', 'user,id=vnet,hostfwd=:127.0.0.1:0-:22',
  '-device', 'pcnet,netdev=vnet')
 self.vm.launch()
-- 
2.21.0

[PATCH v2 01/11] Acceptance tests: refactor wait_for_console_pattern

[Philippe Mathieu-Daudé]

From: Cleber Rosa 

The same utility method is already present in two different test
files, so let's consolidate it into a single utility function.

Signed-off-by: Cleber Rosa 
Message-Id: <20190916164011.7653-1-cr...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
[PMD: failure_message is optional]
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/avocado_qemu/__init__.py | 25 +
 tests/acceptance/boot_linux_console.py| 27 +--
 tests/acceptance/linux_ssh_mips_malta.py  | 18 +++
 3 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index bd41e0443c..e3101cba30 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -8,6 +8,7 @@
 # This work is licensed under the terms of the GNU GPL, version 2 or
 # later.  See the COPYING file in the top-level directory.
 
+import logging
 import os
 import sys
 import uuid
@@ -53,6 +54,30 @@ def pick_default_qemu_bin(arch=None):
 return qemu_bin_from_src_dir_path
 
 
+def wait_for_console_pattern(test, success_message, failure_message=None):
+"""
+Waits for messages to appear on the console, while logging the content
+
+:param test: an Avocado test containing a VM that will have its console
+ read and probed for a success or failure message
+:type test: :class:`avocado_qemu.Test`
+:param success_message: if this message appears, test succeeds
+:param failure_message: if this message appears, test fails
+"""
+console = test.vm.console_socket.makefile()
+console_logger = logging.getLogger('console')
+while True:
+msg = console.readline().strip()
+if not msg:
+continue
+console_logger.debug(msg)
+if success_message in msg:
+break
+if failure_message and failure_message in msg:
+fail = 'Failure message found in console: %s' % failure_message
+test.fail(fail)
+
+
 class Test(avocado.Test):
 def setUp(self):
 self._vms = {}
diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 8a9a314ab4..8897e0c253 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -9,12 +9,12 @@
 # later.  See the COPYING file in the top-level directory.
 
 import os
-import logging
 import lzma
 import gzip
 import shutil
 
 from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
 
@@ -29,31 +29,14 @@ class BootLinuxConsole(Test):
 
 KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
 
-def wait_for_console_pattern(self, success_message,
- failure_message='Kernel panic - not syncing'):
-"""
-Waits for messages to appear on the console, while logging the content
-
-:param success_message: if this message appears, test succeeds
-:param failure_message: if this message appears, test fails
-"""
-console = self.vm.console_socket.makefile()
-console_logger = logging.getLogger('console')
-while True:
-msg = console.readline().strip()
-if not msg:
-continue
-console_logger.debug(msg)
-if success_message in msg:
-break
-if failure_message in msg:
-fail = 'Failure message found in console: %s' % failure_message
-self.fail(fail)
+def wait_for_console_pattern(self, success_message):
+wait_for_console_pattern(self, success_message,
+ failure_message='Kernel panic - not syncing')
 
 def exec_command_and_wait_for_pattern(self, command, success_message):
 command += '\n'
 self.vm.console_socket.sendall(command.encode())
-self.wait_for_console_pattern(success_message)
+wait_for_console_pattern(self, success_message)
 
 def extract_from_deb(self, deb, path):
 """
diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 25a1df5098..ffbb06f846 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -13,6 +13,7 @@ import time
 
 from avocado import skipUnless
 from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
 from avocado.utils import ssh
@@ -40,19 +41,6 @@ class LinuxSSH(Test):
 def setUp(self):
 super(LinuxSSH, self).setUp()
 
-def wait_for_console_pattern(self, success_message,
- failure_message='Oops'):
-console = self.vm.console_socket.makefile()
-console_logger = logging.getLogger('console')
- 

[PATCH v2 03/11] tests/acceptance: Send on serial lines

[Philippe Mathieu-Daudé]

Some firmwares don't parse the  control character and
expect a .

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/boot_linux_console.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 8897e0c253..497faa4f7f 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -34,7 +34,7 @@ class BootLinuxConsole(Test):
  failure_message='Kernel panic - not syncing')
 
 def exec_command_and_wait_for_pattern(self, command, success_message):
-command += '\n'
+command += '\r\n'
 self.vm.console_socket.sendall(command.encode())
 wait_for_console_pattern(self, success_message)
 
-- 
2.21.0

[PATCH v2 10/11] tests/ssh_linux_malta: Refactor how to get image/kernel info

[Philippe Mathieu-Daudé]

The qcow and kernel images use a similar pattern regarding they
are for big/little endianess, or 32/64 bit.
Refactor using more dictionary keys.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 75 ++--
 1 file changed, 44 insertions(+), 31 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 822b0553ff..2139c80f5f 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -26,15 +26,44 @@ class LinuxSSH(Test):
 KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
 VM_IP = '127.0.0.1'
 
+BASE_URL = 'https://people.debian.org/~aurel32/qemu/'
 IMAGE_INFO = {
-'be': {'image_url': ('https://people.debian.org/~aurel32/qemu/mips/'
- 'debian_wheezy_mips_standard.qcow2'),
-   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5'},
-'le': {'image_url': ('https://people.debian.org/~aurel32/qemu/mipsel/'
- 'debian_wheezy_mipsel_standard.qcow2'),
-   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802'}
+'be': {'base_url': 'mips',
+   'image_name': 'debian_wheezy_mips_standard.qcow2',
+   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5',
+   'kernel_hash': {
+   32: '592e384a4edc16dade52a6cd5c785c637bcbc9ad',
+   64: 'db6eea7de35d36c77d8c165b6bcb222e16eb91db'}
+  },
+'le': {'base_url': 'mipsel',
+   'image_name': 'debian_wheezy_mipsel_standard.qcow2',
+   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802',
+   'kernel_hash': {
+   32: 'a66bea5a8adaa2cb3d36a1d4e0ccdb01be8f6c2a',
+   64: '6a7f77245acf231415a0e8b725d91ed2f3487794'}
+  }
+}
+CPU_INFO = {
+32: {'kernel_release': '3.2.0-4-4kc-malta'},
+64: {'kernel_release': '3.2.0-4-5kc-malta'}
 }
 
+def get_url(self, endianess, path=''):
+qkey = {'le': 'el', 'be': ''}
+return '%s/mips%s/%s' % (self.BASE_URL, qkey[endianess], path)
+
+def get_image_info(self, endianess):
+dinfo = self.IMAGE_INFO[endianess]
+image_url = self.get_url(endianess, dinfo['image_name'])
+image_hash = dinfo['image_hash']
+return (image_url, image_hash)
+
+def get_kernel_info(self, endianess, wordsize):
+minfo = self.CPU_INFO[wordsize]
+kernel_url = self.get_url(endianess,
+  'vmlinux-%s' % minfo['kernel_release'])
+kernel_hash = self.IMAGE_INFO[endianess]['kernel_hash'][wordsize]
+return kernel_url, kernel_hash
 
 @skipUnless(ssh.SSH_CLIENT_BINARY, 'No SSH client available')
 @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
@@ -79,8 +108,7 @@ class LinuxSSH(Test):
 return stdout_lines, stderr_lines
 
 def boot_debian_wheezy_image_and_ssh_login(self, endianess, kernel_path):
-image_url = self.IMAGE_INFO[endianess]['image_url']
-image_hash = self.IMAGE_INFO[endianess]['image_hash']
+image_url, image_hash = self.get_image_info(endianess)
 image_path = self.fetch_asset(image_url, asset_hash=image_hash)
 
 self.vm.set_machine('malta')
@@ -172,7 +200,10 @@ class LinuxSSH(Test):
 'md5sum /dev/mtd2ro',
 '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
 
-def check_mips_malta(self, endianess, kernel_path, uname_m):
+def check_mips_malta(self, uname_m, endianess):
+wordsize = 64 if '64' in uname_m else 32
+kernel_url, kernel_hash = self.get_kernel_info(endianess, wordsize)
+kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
 self.boot_debian_wheezy_image_and_ssh_login(endianess, kernel_path)
 
 stdout, _ = self.ssh_command('uname -a')
@@ -188,12 +219,7 @@ class LinuxSSH(Test):
 :avocado: tags=endian:big
 :avocado: tags=device:pcnet32
 """
-kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
-  'vmlinux-3.2.0-4-4kc-malta')
-kernel_hash = '592e384a4edc16dade52a6cd5c785c637bcbc9ad'
-kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-
-self.check_mips_malta('be', kernel_path, 'mips')
+self.check_mips_malta('mips', 'be')
 
 def test_mips_malta32el_kernel3_2_0(self):
 """
@@ -202,12 +228,7 @@ class LinuxSSH(Test):
 :avocado: tags=endian:little
 :avocado: tags=device:pcnet32
 """
-kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
-  'vmlinux-3.2.0-4-4kc-malta')
-kernel_hash = 'a66bea5a8adaa2cb3d36a1d4e0ccdb01be8f6c2a'
-kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-
-self.check_mips_malta('le', kernel_path, 'mi

[PATCH v2 06/11] tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu

[Philippe Mathieu-Daudé]

This tests boots a Linux kernel on a Malta machine up to a
busybox shell on the serial console. Few commands are executed
before halting the machine (via reboot).

We use the Fedora 24 kernel extracted from the image at:
https://fedoraproject.org/wiki/Architectures/MIPS
and the initrd cpio image from the kerneltests project:
https://kerneltests.org/

If MIPS is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips" tags.

Alternatively, this test can be run using:

  $ avocado --show=console run -t arch:mips64el 
tests/acceptance/boot_linux_console.py
  console: [0.00] Linux version 3.19.3.mtoman.20150408 
(mtoman@debian-co3-1) (gcc version 5.0.0 20150316 (Red Hat 5.0.0-0.20) (GCC) ) 
#3 Wed Apr 8 14:32:50 UTC 2015
  console: [0.00] Early serial console at I/O port 0x3f8 (options 
'38400n8')
  console: [0.00] bootconsole [uart0] enabled
  console: [0.00] CPU0 revision is: 00018900 (MIPS 5KE)
  console: [0.00] Checking for the multiply/shift bug... no.
  console: [0.00] Checking for the daddiu bug... no.
  [...]
  console: Boot successful.
  console: cat /proc/cpuinfo
  console: / # cat /proc/cpuinfo
  console: system type: MIPS Malta
  console: machine: Unknown
  console: processor  : 0
  console: cpu model  : MIPS 5KE V0.0
  console: : 1616.89
  console: wait instruction   : nouname -a
  console: microsecond timers : yes
  console: tlb_entries: 32
  console: extra interrupt vector : yes
  console: hardware watchpoint: yes, count: 1, address/irw mask: [0x0ff8]
  console: isa: mips1 mips2 mips3 mips4 mips5 mips32r1 
mips32r2 mips64r1 mips64r2
  console: ASEs implemented   :
  console: shadow register sets   : 1
  console: kscratch registers : 0
  console: package: 0
  console: core   : 0
  console: VCED exceptions: not available
  console: VCEI exceptions: not available
  console: / #
  console: / # uname -a
  console: Linux buildroot 3.19.3.mtoman.20150408 #3 Wed Apr 8 14:32:50 UTC 
2015 mips64 GNU/Linux
  console: reboot
  console: / #
  console: / # reboot
  console: / #
  console: / # reboot: Restarting system
  PASS (7.04 s)
  JOB TIME   : 7.20 s

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/boot_linux_console.py | 40 ++
 1 file changed, 40 insertions(+)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 67d7e96d98..e505a41eed 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -166,6 +166,46 @@ class BootLinuxConsole(Test):
 exec_command_and_wait_for_pattern(self, 'reboot',
 'reboot: Restarting system')
 
+def test_mips64el_malta_5KEc_cpio(self):
+"""
+:avocado: tags=arch:mips64el
+:avocado: tags=machine:malta
+:avocado: tags=endian:little
+"""
+kernel_url = ('https://github.com/philmd/qemu-testing-blob/'
+  'raw/9ad2df38/mips/malta/mips64el/'
+  'vmlinux-3.19.3.mtoman.20150408')
+kernel_hash = '00d1d268fb9f7d8beda1de6bebcc46e884d71754'
+kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
+initrd_url = ('https://github.com/groeck/linux-build-test/'
+  'raw/8584a59e/rootfs/'
+  'mipsel64/rootfs.mipsel64r1.cpio.gz')
+initrd_hash = '1dbb8a396e916847325284dbe2151167'
+initrd_path_gz = self.fetch_asset(initrd_url, algorithm='md5',
+  asset_hash=initrd_hash)
+initrd_path = self.workdir + "rootfs.cpio"
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
+
+self.vm.set_machine('malta')
+self.vm.set_console()
+kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE
+   + 'console=ttyS0 console=tty '
+   + 'rdinit=/sbin/init noreboot')
+self.vm.add_args('-cpu', '5KEc',
+ '-kernel', kernel_path,
+ '-initrd', initrd_path,
+ '-append', kernel_command_line,
+ '-no-reboot')
+self.vm.launch()
+wait_for_console_pattern(self, 'Boot successful.')
+
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'MIPS 5KE')
+exec_command_and_wait_for_pattern(self, 'uname -a',
+'3.19.3.mtoman.20150408')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')
+
 def do_test_mips_malta32el_nanomips(self, kernel_url, kerne

[PATCH v2 02/11] tests/acceptance: Fixe wait_for_console_pattern() hangs

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

Because of a possible deadlock (QEMU waiting for the socket to
become writable) let's close the console socket as soon as we
stop to use it.

Suggested-by: Cleber Rosa 
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/avocado_qemu/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index e3101cba30..a0450e5263 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -74,6 +74,7 @@ def wait_for_console_pattern(test, success_message, 
failure_message=None):
 if success_message in msg:
 break
 if failure_message and failure_message in msg:
+console.close()
 fail = 'Failure message found in console: %s' % failure_message
 test.fail(fail)
 
-- 
2.21.0

[PATCH v2 04/11] tests/acceptance: Refactor exec_command_and_wait_for_pattern()

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

The same utility method is already present in two different test
files, so let's consolidate it into a single utility function.

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: fix self -> test, failure_message is optional, added doc
---
 tests/acceptance/avocado_qemu/__init__.py | 19 +++
 tests/acceptance/boot_linux_console.py| 18 +++---
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index a0450e5263..7bc77118dd 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -79,6 +79,25 @@ def wait_for_console_pattern(test, success_message, 
failure_message=None):
 test.fail(fail)
 
 
+def exec_command_and_wait_for_pattern(test, command,
+  success_message, failure_message=None):
+"""
+Send a command to a console (appending CRLF characters), then wait
+for success_message to appear on the console, while logging the.
+content. Mark the test as failed if failure_message is found instead.
+
+:param test: an Avocado test containing a VM that will have its console
+ read and probed for a success or failure message
+:type test: :class:`avocado_qemu.Test`
+:param command: the command to send
+:param success_message: if this message appears, test succeeds
+:param failure_message: if this message appears, test fails
+"""
+command += '\r\n'
+test.vm.console_socket.sendall(command.encode())
+wait_for_console_pattern(test, success_message, failure_message)
+
+
 class Test(avocado.Test):
 def setUp(self):
 self._vms = {}
diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 497faa4f7f..4b419b0559 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -14,6 +14,7 @@ import gzip
 import shutil
 
 from avocado_qemu import Test
+from avocado_qemu import exec_command_and_wait_for_pattern
 from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
@@ -33,11 +34,6 @@ class BootLinuxConsole(Test):
 wait_for_console_pattern(self, success_message,
  failure_message='Kernel panic - not syncing')
 
-def exec_command_and_wait_for_pattern(self, command, success_message):
-command += '\r\n'
-self.vm.console_socket.sendall(command.encode())
-wait_for_console_pattern(self, success_message)
-
 def extract_from_deb(self, deb, path):
 """
 Extracts a file from a deb package into the test workdir
@@ -166,12 +162,12 @@ class BootLinuxConsole(Test):
 self.vm.launch()
 self.wait_for_console_pattern('Boot successful.')
 
-self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo',
-   'BogoMIPS')
-self.exec_command_and_wait_for_pattern('uname -a',
-   'Debian')
-self.exec_command_and_wait_for_pattern('reboot',
-   'reboot: Restarting system')
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'BogoMIPS')
+exec_command_and_wait_for_pattern(self, 'uname -a',
+'Debian')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')
 
 def do_test_mips_malta32el_nanomips(self, kernel_url, kernel_hash):
 kernel_path_xz = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-- 
2.21.0

[PATCH v2 00/11] tests/acceptance: Fix 64-bit MIPS target tests

[Philippe Mathieu-Daudé]

v2:
- Fixed GIT_COMMITTER_NAME
- do no include Aleksandar Rikalo mailmap change

Commit 9090d3332cdcc introduced a regression which makes the
64-bit target tests to fail.

This series fix it (by previously refactoring the linux_ssh_malta
test), and also add another test for the 5KEc CPU.

I had to include Avocado-related patches not yet merged again to
avoid sending patches that will later not apply.

Please review,

Phil.

Cleber Rosa (1):
  Acceptance tests: refactor wait_for_console_pattern

Philippe Mathieu-Daudé (10):
  tests/acceptance: Fixe wait_for_console_pattern() hangs
  tests/acceptance: Send  on serial lines
  tests/acceptance: Refactor exec_command_and_wait_for_pattern()
  tests/boot_linux_console: Use Avocado archive::gzip_uncompress()
  tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu
  tests/ssh_linux_malta: Run tests using a snapshot image
  tests/ssh_linux_malta: Remove duplicated test
  tests/ssh_linux_malta: Match stricter console output
  tests/ssh_linux_malta: Refactor how to get image/kernel info
  tests/ssh_linux_malta: Fix 64-bit target tests

 tests/acceptance/avocado_qemu/__init__.py |  45 
 tests/acceptance/boot_linux_console.py|  88 ---
 tests/acceptance/linux_ssh_mips_malta.py  | 124 +++---
 3 files changed, 158 insertions(+), 99 deletions(-)

-- 
2.21.0

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
> On 18/10/2019 19:28, Marty E. Plummer wrote:
> > Hello,
> > 
> > First off, thank you for the work you've done on the ppc64 support, it
> > has been very useful. I'm currently working on a coreboot port for the
> > talos ii line of systems (which means more ppc64 support, support
> > specifically for the power9 sforza chip, and specific mainboard support.
> > My plate is very full lol) and have been using qemu to debug the
> > bootblock.
> > 
> > It has been very useful for that, but I'm now at the point where I need
> > to jump to romstage, and that's where it gets tricky. qemu parses the rom
> > image and looks for a ffs header, locates skiboot on it, and jumps straight
> > to that. Not exactly ideal for debugging something not produced from 
> > op-build.
> 
> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
> file to extract the PAYLOAD partition (skiboot). skiboot also detects the
> flash and extract the kernel and initramfs from the PNOR.
> 
> However, you can bypass all this internal boot process by simply passing
> a -bios option and not passing a MTD device.
> 
Doing so gives me the following error:
qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
(this is after I patched the 4mb size limit up)
> I haven't published the PNOR support and the boot from PNOR yet. Lack
> of time and because sPAPR is the priority.
> 
> > Do you think it would be within your wheelhouse to provide a generic, 
> > non-ffs
> > pnor interface for loading arbitary rom images? 
> 
> I should probably send the PNOR patchset now so that we can discuss on 
> a better way to satisfy all needs.  
> 
> > It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> is possible to interconnect them through the BT device. Or you can use
> the IPMI BT simulator of QEMU on the PowerNV machine
> 
> Thanks,
> 
> C. 
> 

Re: [PATCH 00/11] tests/acceptance: Fix 64-bit MIPS target tests

[Philippe Mathieu-Daudé]

On 10/19/19 5:10 PM, Philippe Mathieu-Daudé wrote:

From: PhilMD 


Oh I sent this from a new workspace, and forgot to set git.user.name :S
git.sendemail.from doesn't enforce it.
I'll simply resend.


Commit 9090d3332cdcc introduced a regression which makes the
64-bit target tests to fail.

This series fix it (by previously refactoring the linux_ssh_malta
test), and also add another test for the 5KEc CPU.

I had to include Avocado-related patches not yet merged again to
avoid sending patches that will later not apply.

Please review,

Phil.

Cleber Rosa (1):
   Acceptance tests: refactor wait_for_console_pattern

Philippe Mathieu-Daudé (10):
   tests/acceptance: Fixe wait_for_console_pattern() hangs
   tests/acceptance: Send  on serial lines
   tests/acceptance: Refactor exec_command_and_wait_for_pattern()
   tests/boot_linux_console: Use Avocado archive::gzip_uncompress()
   tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu
   tests/ssh_linux_malta: Run tests using a snapshot image
   tests/ssh_linux_malta: Remove duplicated test
   tests/ssh_linux_malta: Match stricter console output
   tests/ssh_linux_malta: Refactor how to get image/kernel info
   tests/ssh_linux_malta: Fix 64-bit target tests

  .mailmap  |   1 +


Oh, the mailmap change wasn't supposed to get send neither...
It was just to stop receiving bounce errors from Microsoft MTA.


  tests/acceptance/avocado_qemu/__init__.py |  45 
  tests/acceptance/boot_linux_console.py|  88 ---
  tests/acceptance/linux_ssh_mips_malta.py  | 124 +++---
  4 files changed, 159 insertions(+), 99 deletions(-)

Re: [PATCH v4 0/11] add failover feature for assigned network devices

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191018202040.30349-1-jfreim...@redhat.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  hw/core/platform-bus.o
  CC  hw/core/generic-loader.o
/tmp/qemu-test/src/hw/core/qdev.c: In function 'qdev_should_hide_device':
/tmp/qemu-test/src/hw/core/qdev.c:235:15: error: 'rc' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
 return rc > 0;
~~~^~~
cc1: all warnings being treated as errors
make: *** [/tmp/qemu-test/src/rules.mak:69: hw/core/qdev.o] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=1d57bd92e38c4da3a26a7b0d378b562e', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-ggapjx1d/src/docker-src.2019-10-19-11.13.01.17849:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=1d57bd92e38c4da3a26a7b0d378b562e
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-ggapjx1d/src'
make: *** [docker-run-test-mingw@fedora] Error 2

real2m33.496s
user0m8.171s


The full log is available at
http://patchew.org/logs/20191018202040.30349-1-jfreim...@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v4 0/11] add failover feature for assigned network devices

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191018202040.30349-1-jfreim...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  hw/core/or-irq.o
  CC  hw/core/split-irq.o
/tmp/qemu-test/src/hw/core/qdev.c: In function 'qdev_should_hide_device':
/tmp/qemu-test/src/hw/core/qdev.c:235:5: error: 'rc' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
 return rc > 0;
 ^
cc1: all warnings being treated as errors
make: *** [hw/core/qdev.o] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=45df366e5eaf45f6ac429142fe2cc309', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-ozx9dk_0/src/docker-src.2019-10-19-11.10.07.7972:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=45df366e5eaf45f6ac429142fe2cc309
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-ozx9dk_0/src'
make: *** [docker-run-test-quick@centos7] Error 2

real2m19.619s
user0m8.409s


The full log is available at
http://patchew.org/logs/20191018202040.30349-1-jfreim...@redhat.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH 11/11] tests/ssh_linux_malta: Fix 64-bit target tests

[Philippe Mathieu-Daudé]

Commit 9090d3332cdcc added tests for specific to the 32-bit
machines, which inadvertently make the 64-bit tests failing.
Now than we have this information available in the CPU_INFO
array, use it to have the 64-bit tests back.

Signed-off-by: Philippe Mathieu-Daudé 
---
 .mailmap |  1 +
 tests/acceptance/linux_ssh_mips_malta.py | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/.mailmap b/.mailmap
index 0756a0bf66..fb7d7ede76 100644
--- a/.mailmap
+++ b/.mailmap
@@ -158,3 +158,4 @@ Zhengui Li 
 Zhenwei Pi 
 Zhenwei Pi 
 Zhuang Yanying 
+Aleksandar Rikalo  
diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 2139c80f5f..fc13f9e4d4 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -44,8 +44,8 @@ class LinuxSSH(Test):
   }
 }
 CPU_INFO = {
-32: {'kernel_release': '3.2.0-4-4kc-malta'},
-64: {'kernel_release': '3.2.0-4-5kc-malta'}
+32: {'cpu': 'MIPS 24Kc', 'kernel_release': '3.2.0-4-4kc-malta'},
+64: {'cpu': 'MIPS 20Kc', 'kernel_release': '3.2.0-4-5kc-malta'}
 }
 
 def get_url(self, endianess, path=''):
@@ -143,16 +143,16 @@ class LinuxSSH(Test):
 else:
 self.fail('"%s" output does not contain "%s"' % (cmd, exp))
 
-def run_common_commands(self):
+def run_common_commands(self, wordsize):
 self.ssh_command_output_contains(
 'cat /proc/cpuinfo',
-'24Kc')
+self.CPU_INFO[wordsize]['cpu'])
 self.ssh_command_output_contains(
 'uname -m',
 'mips')
 self.ssh_command_output_contains(
 'uname -r',
-'3.2.0-4-4kc-malta')
+self.CPU_INFO[wordsize]['kernel_release'])
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
 'XT-PIC  timer')
@@ -209,7 +209,7 @@ class LinuxSSH(Test):
 stdout, _ = self.ssh_command('uname -a')
 self.assertIn(True, [uname_m + " GNU/Linux" in line for line in 
stdout])
 
-self.run_common_commands()
+self.run_common_commands(wordsize)
 self.shutdown_via_ssh()
 
 def test_mips_malta32eb_kernel3_2_0(self):
-- 
2.21.0

Re: [PATCH v2 20/20] hw/pci-host/i440fx: Remove the last PIIX3 traces

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 10/18/19 7:04 PM, Aleksandar Markovic wrote:



On Friday, October 18, 2019, Philippe Mathieu-Daudé > wrote:


The PIIX3 is not tied to the i440FX and can even be used without it.
Move its creation to the machine code (pc_piix.c).
We have now removed the last trace of southbridge code in the i440FX
northbridge.

Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  hw/i386/pc_piix.c            | 8 +++-
  hw/pci-host/i440fx.c         | 8 
  include/hw/pci-host/i440fx.h | 3 +--
  3 files changed, 8 insertions(+), 11 deletions(-)


Reviewed-by: Aleksandar Markovic >


Philippe, I don't have any test equipment available at the moment, did 
you do some smoke tests with new v2 of the series (like booting a Malta 
board, or other relevant scenario)?


This series pass all 32-bit Avocado tests, and if you apply
"tests/acceptance: Fix 64-bit MIPS target tests" I just sent [*],
all the tests pass.

AVOCADO_TIMEOUT_EXPECTED=1 avocado \
  --show=app,ssh,console \
  run \
  -t arch:mipsel -t arch:mips -t arch:mips64el -t arch:mips64 \
  tests/acceptance/

[*] mid.mail-archive.com/20191019151058.31733-1-f4bug@amsat.org

Veuillez agréer, Monsieur Philippe, l'assurance de mon parfaite 
considération.


Merci ;)


Aleksandar

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 11b8de049f..f6e7196a82 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -199,14 +199,20 @@ static void pc_init1(MachineState *machine,
      }

      if (pcmc->pci_enabled) {
+        PIIX3State *piix3;
+
          pci_bus = i440fx_init(host_type,
                                pci_type,
-                              &i440fx_state, &piix3_devfn,
&isa_bus, pcms->gsi,
+                              &i440fx_state,
                                system_memory, system_io,
machine->ram_size,
                                pcms->below_4g_mem_size,
                                pcms->above_4g_mem_size,
                                pci_memory, ram_memory);
          pcms->bus = pci_bus;
+
+        piix3 = piix3_create(pci_bus, &isa_bus);
+        piix3->pic = pcms->gsi;
+        piix3_devfn = piix3->dev.devfn;
      } else {
          pci_bus = NULL;
          i440fx_state = NULL;
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index 79ecd58a2b..f27131102d 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -27,7 +27,6 @@
  #include "hw/pci/pci.h"
  #include "hw/pci/pci_host.h"
  #include "hw/pci-host/i440fx.h"
-#include "hw/southbridge/piix.h"
  #include "hw/qdev-properties.h"
  #include "hw/sysbus.h"
  #include "qapi/error.h"
@@ -272,8 +271,6 @@ static void i440fx_realize(PCIDevice *dev, Error
**errp)

  PCIBus *i440fx_init(const char *host_type, const char *pci_type,
                      PCII440FXState **pi440fx_state,
-                    int *piix3_devfn,
-                    ISABus **isa_bus, qemu_irq *pic,
                      MemoryRegion *address_space_mem,
                      MemoryRegion *address_space_io,
                      ram_addr_t ram_size,
@@ -286,7 +283,6 @@ PCIBus *i440fx_init(const char *host_type, const
char *pci_type,
      PCIBus *b;
      PCIDevice *d;
      PCIHostState *s;
-    PIIX3State *piix3;
      PCII440FXState *f;
      unsigned i;
      I440FXState *i440fx;
@@ -339,10 +335,6 @@ PCIBus *i440fx_init(const char *host_type,
const char *pci_type,
                   PAM_EXPAN_SIZE);
      }

-    piix3 = piix3_create(b, isa_bus);
-    piix3->pic = pic;
-    *piix3_devfn = piix3->dev.devfn;
-
      ram_size = ram_size / 8 / 1024 / 1024;
      if (ram_size > 255) {
          ram_size = 255;
diff --git a/include/hw/pci-host/i440fx.h b/include/hw/pci-host/i440fx.h
index e327f9bf87..f54e6466e4 100644
--- a/include/hw/pci-host/i440fx.h
+++ b/include/hw/pci-host/i440fx.h
@@ -22,8 +22,7 @@ typedef struct PCII440FXState PCII440FXState;
  #define TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE
"igd-passthrough-i440FX"

  PCIBus *i440fx_init(const char *host_type, const char *pci_type,
-                    PCII440FXState **pi440fx_state, int *piix_devfn,
-                    ISABus **isa_bus, qemu_irq *pic,
+                    PCII440FXState **pi440fx_state,
                      MemoryRegion *address_space_mem,
                      MemoryRegion *address_space_io,
                      ram_addr_t ram_size,
-- 
2.21.0

[PATCH 10/11] tests/ssh_linux_malta: Refactor how to get image/kernel info

[Philippe Mathieu-Daudé]

The qcow and kernel images use a similar pattern regarding they
are for big/little endianess, or 32/64 bit.
Refactor using more dictionary keys.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 75 ++--
 1 file changed, 44 insertions(+), 31 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 822b0553ff..2139c80f5f 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -26,15 +26,44 @@ class LinuxSSH(Test):
 KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
 VM_IP = '127.0.0.1'
 
+BASE_URL = 'https://people.debian.org/~aurel32/qemu/'
 IMAGE_INFO = {
-'be': {'image_url': ('https://people.debian.org/~aurel32/qemu/mips/'
- 'debian_wheezy_mips_standard.qcow2'),
-   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5'},
-'le': {'image_url': ('https://people.debian.org/~aurel32/qemu/mipsel/'
- 'debian_wheezy_mipsel_standard.qcow2'),
-   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802'}
+'be': {'base_url': 'mips',
+   'image_name': 'debian_wheezy_mips_standard.qcow2',
+   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5',
+   'kernel_hash': {
+   32: '592e384a4edc16dade52a6cd5c785c637bcbc9ad',
+   64: 'db6eea7de35d36c77d8c165b6bcb222e16eb91db'}
+  },
+'le': {'base_url': 'mipsel',
+   'image_name': 'debian_wheezy_mipsel_standard.qcow2',
+   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802',
+   'kernel_hash': {
+   32: 'a66bea5a8adaa2cb3d36a1d4e0ccdb01be8f6c2a',
+   64: '6a7f77245acf231415a0e8b725d91ed2f3487794'}
+  }
+}
+CPU_INFO = {
+32: {'kernel_release': '3.2.0-4-4kc-malta'},
+64: {'kernel_release': '3.2.0-4-5kc-malta'}
 }
 
+def get_url(self, endianess, path=''):
+qkey = {'le': 'el', 'be': ''}
+return '%s/mips%s/%s' % (self.BASE_URL, qkey[endianess], path)
+
+def get_image_info(self, endianess):
+dinfo = self.IMAGE_INFO[endianess]
+image_url = self.get_url(endianess, dinfo['image_name'])
+image_hash = dinfo['image_hash']
+return (image_url, image_hash)
+
+def get_kernel_info(self, endianess, wordsize):
+minfo = self.CPU_INFO[wordsize]
+kernel_url = self.get_url(endianess,
+  'vmlinux-%s' % minfo['kernel_release'])
+kernel_hash = self.IMAGE_INFO[endianess]['kernel_hash'][wordsize]
+return kernel_url, kernel_hash
 
 @skipUnless(ssh.SSH_CLIENT_BINARY, 'No SSH client available')
 @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
@@ -79,8 +108,7 @@ class LinuxSSH(Test):
 return stdout_lines, stderr_lines
 
 def boot_debian_wheezy_image_and_ssh_login(self, endianess, kernel_path):
-image_url = self.IMAGE_INFO[endianess]['image_url']
-image_hash = self.IMAGE_INFO[endianess]['image_hash']
+image_url, image_hash = self.get_image_info(endianess)
 image_path = self.fetch_asset(image_url, asset_hash=image_hash)
 
 self.vm.set_machine('malta')
@@ -172,7 +200,10 @@ class LinuxSSH(Test):
 'md5sum /dev/mtd2ro',
 '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
 
-def check_mips_malta(self, endianess, kernel_path, uname_m):
+def check_mips_malta(self, uname_m, endianess):
+wordsize = 64 if '64' in uname_m else 32
+kernel_url, kernel_hash = self.get_kernel_info(endianess, wordsize)
+kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
 self.boot_debian_wheezy_image_and_ssh_login(endianess, kernel_path)
 
 stdout, _ = self.ssh_command('uname -a')
@@ -188,12 +219,7 @@ class LinuxSSH(Test):
 :avocado: tags=endian:big
 :avocado: tags=device:pcnet32
 """
-kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
-  'vmlinux-3.2.0-4-4kc-malta')
-kernel_hash = '592e384a4edc16dade52a6cd5c785c637bcbc9ad'
-kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-
-self.check_mips_malta('be', kernel_path, 'mips')
+self.check_mips_malta('mips', 'be')
 
 def test_mips_malta32el_kernel3_2_0(self):
 """
@@ -202,12 +228,7 @@ class LinuxSSH(Test):
 :avocado: tags=endian:little
 :avocado: tags=device:pcnet32
 """
-kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
-  'vmlinux-3.2.0-4-4kc-malta')
-kernel_hash = 'a66bea5a8adaa2cb3d36a1d4e0ccdb01be8f6c2a'
-kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-
-self.check_mips_malta('le', kernel_path, 'mi

[PATCH 09/11] tests/ssh_linux_malta: Match stricter console output

[Philippe Mathieu-Daudé]

Match on stricter console output.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 5523ae2144..822b0553ff 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -127,19 +127,19 @@ class LinuxSSH(Test):
 '3.2.0-4-4kc-malta')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'timer')
+'XT-PIC  timer')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'i8042')
+'XT-PIC  i8042')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'serial')
+'XT-PIC  serial')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'ata_piix')
+'XT-PIC  ata_piix')
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
-'eth0')
+'XT-PIC  eth0')
 self.ssh_command_output_contains(
 'cat /proc/devices',
 'input')
@@ -151,13 +151,13 @@ class LinuxSSH(Test):
 'fb')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'serial')
+' : serial')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'ata_piix')
+' : ata_piix')
 self.ssh_command_output_contains(
 'cat /proc/ioports',
-'piix4_smbus')
+' : piix4_smbus')
 self.ssh_command_output_contains(
 'lspci -d 11ab:4620',
 'GT-64120')
@@ -167,7 +167,7 @@ class LinuxSSH(Test):
 self.ssh_command_output_contains(
 'cat /proc/mtd',
 'YAMON')
-# Empty 'Board Config'
+# Empty 'Board Config' (64KB)
 self.ssh_command_output_contains(
 'md5sum /dev/mtd2ro',
 '0dfbe8aa4c20b52e1b8bf3cb6cbdf193')
-- 
2.21.0

[PATCH 08/11] tests/ssh_linux_malta: Remove duplicated test

[Philippe Mathieu-Daudé]

Remove duplicated test (probably copy/paste error in
commit 9090d3332cdcc).

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 27907e8fbd..5523ae2144 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -140,9 +140,6 @@ class LinuxSSH(Test):
 self.ssh_command_output_contains(
 'cat /proc/interrupts',
 'eth0')
-self.ssh_command_output_contains(
-'cat /proc/interrupts',
-'eth0')
 self.ssh_command_output_contains(
 'cat /proc/devices',
 'input')
-- 
2.21.0

Re: [PATCH v2 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[Aleksandar Markovic]

On Friday, October 18, 2019, Philippe Mathieu-Daudé 
wrote:

> Changes since v1 [0]:
> - Removed patch reintroducing DO_UPCAST() use (thuth)
> - Took various patches out to reduce series (thuth)
> - Added review tags (thanks all for reviewing!)
>
>
As far as I can tell, a handful of checkpatch warnings are all false
positives.

Peter, I am fine with Philippe (or Herve for that matter) submitting this
series as a pull request (providing that some basic relevant Malta tests
are done), and, if you are fine too, I think we can proceed.

Integrating this series will make device model for Malta better (closer to
real hardware), and also help Philippe continue working on other device
cleanups.

Aleksandar




> $ git backport-diff -u pc_split_i440fx_piix-v1 -r mc146818rtc_init..
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences,
> respectively
>
> 001/20:[] [--] 'MAINTAINERS: Keep PIIX4 South Bridge separate from PC
> Chipsets'
> 002/20:[0011] [FC] 'piix4: add Reset Control Register'
> 003/20:[0014] [FC] 'piix4: add a i8259 interrupt controller as specified
> in datasheet'
> 004/20:[] [--] 'Revert "irq: introduce qemu_irq_proxy()"'
> 005/20:[] [--] 'piix4: rename PIIX4 object to piix4-isa'
> 006/20:[] [-C] 'piix4: add a i8257 dma controller as specified in
> datasheet'
> 007/20:[] [-C] 'piix4: add a i8254 pit controller as specified in
> datasheet'
> 008/20:[] [-C] 'piix4: add a mc146818rtc controller as specified in
> datasheet'
> 009/20:[] [--] 'hw/mips/mips_malta: Create IDE hard drive array
> dynamically'
> 010/20:[] [--] 'hw/mips/mips_malta: Extract the PIIX4 creation code as
> piix4_create()'
> 011/20:[] [--] 'hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c'
> 012/20:[] [--] 'hw/i386: Remove obsolete LoadStateHandler::load_state_old
> handlers'
> 013/20:[] [--] 'hw/pci-host/piix: Extract piix3_create()'
> 014/20:[0010] [FC] 'hw/pci-host/piix: Move RCR_IOPORT register definition'
> 015/20:[] [--] 'hw/pci-host/piix: Define and use the PIIX IRQ Route
> Control Registers'
> 016/20:[] [--] 'hw/pci-host/piix: Move i440FX declarations to
> hw/pci-host/i440fx.h'
> 017/20:[] [--] 'hw/pci-host/piix: Fix code style issues'
> 018/20:[0012] [FC] 'hw/pci-host/piix: Extract PIIX3 functions to
> hw/isa/piix3.c'
> 019/20:[] [--] 'hw/pci-host: Rename incorrectly named 'piix' as
> 'i440fx''
> 020/20:[] [-C] 'hw/pci-host/i440fx: Remove the last PIIX3 traces'
>
> Previous cover:
>
> This series is a rework of "piix4: cleanup and improvements" [1]
> from Hervé, and my "remove i386/pc dependency: PIIX cleanup" [2].
>
> Still trying to remove the strong X86/PC dependency 2 years later,
> one step at a time.
> Here we split the PIIX3 southbridge from i440FX northbridge.
> The i440FX northbridge is only used by the PC machine, while the
> PIIX southbridge is also used by the Malta MIPS machine.
>
> This is also a step forward using KConfig with the Malta board.
> Without this split, it was impossible to compile the Malta without
> pulling various X86 pieces of code.
>
> The overall design cleanup is not yet perfect, but enough to post
> as a series.
>
> Now that the PIIX3 code is extracted, the code duplication with the
> PIIX4 chipset is obvious. Not worth improving for now because it
> isn't broken.
>
> [0] https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html
> [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg500737.html
> [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg504081.html
>
> Based-on: <20191018133547.10936-1-phi...@redhat.com>
> mc146818rtc: Allow call object_initialize(MC146818_RTC) instead of
> rtc_init()
> 20191018133547.10936-1-philmd@redhat.com">https://mid.mail-archive.com/20191018133547.10936-1-philmd@redhat.com
>
> Hervé Poussineau (5):
>   piix4: Add the Reset Control Register
>   piix4: Add a i8259 Interrupt Controller as specified in datasheet
>   piix4: Rename PIIX4 object to piix4-isa
>   piix4: Add a i8257 DMA Controller as specified in datasheet
>   piix4: Add a i8254 PIT Controller as specified in datasheet
>
> Philippe Mathieu-Daudé (15):
>   MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
>   Revert "irq: introduce qemu_irq_proxy()"
>   piix4: Add a MC146818 RTC Controller as specified in datasheet
>   hw/mips/mips_malta: Create IDE hard drive array dynamically
>   hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
>   hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
>   hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
>   hw/pci-host/piix: Extract piix3_create()
>   hw/pci-host/piix: Move RCR_IOPORT register definition
>   hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
>   hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
>   hw/pci-host/p

[PATCH 04/11] tests/acceptance: Refactor exec_command_and_wait_for_pattern()

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

The same utility method is already present in two different test
files, so let's consolidate it into a single utility function.

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: fix self -> test, failure_message is optional, added doc
---
 tests/acceptance/avocado_qemu/__init__.py | 19 +++
 tests/acceptance/boot_linux_console.py| 18 +++---
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index a0450e5263..7bc77118dd 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -79,6 +79,25 @@ def wait_for_console_pattern(test, success_message, 
failure_message=None):
 test.fail(fail)
 
 
+def exec_command_and_wait_for_pattern(test, command,
+  success_message, failure_message=None):
+"""
+Send a command to a console (appending CRLF characters), then wait
+for success_message to appear on the console, while logging the.
+content. Mark the test as failed if failure_message is found instead.
+
+:param test: an Avocado test containing a VM that will have its console
+ read and probed for a success or failure message
+:type test: :class:`avocado_qemu.Test`
+:param command: the command to send
+:param success_message: if this message appears, test succeeds
+:param failure_message: if this message appears, test fails
+"""
+command += '\r\n'
+test.vm.console_socket.sendall(command.encode())
+wait_for_console_pattern(test, success_message, failure_message)
+
+
 class Test(avocado.Test):
 def setUp(self):
 self._vms = {}
diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 497faa4f7f..4b419b0559 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -14,6 +14,7 @@ import gzip
 import shutil
 
 from avocado_qemu import Test
+from avocado_qemu import exec_command_and_wait_for_pattern
 from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
@@ -33,11 +34,6 @@ class BootLinuxConsole(Test):
 wait_for_console_pattern(self, success_message,
  failure_message='Kernel panic - not syncing')
 
-def exec_command_and_wait_for_pattern(self, command, success_message):
-command += '\r\n'
-self.vm.console_socket.sendall(command.encode())
-wait_for_console_pattern(self, success_message)
-
 def extract_from_deb(self, deb, path):
 """
 Extracts a file from a deb package into the test workdir
@@ -166,12 +162,12 @@ class BootLinuxConsole(Test):
 self.vm.launch()
 self.wait_for_console_pattern('Boot successful.')
 
-self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo',
-   'BogoMIPS')
-self.exec_command_and_wait_for_pattern('uname -a',
-   'Debian')
-self.exec_command_and_wait_for_pattern('reboot',
-   'reboot: Restarting system')
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'BogoMIPS')
+exec_command_and_wait_for_pattern(self, 'uname -a',
+'Debian')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')
 
 def do_test_mips_malta32el_nanomips(self, kernel_url, kernel_hash):
 kernel_path_xz = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-- 
2.21.0

[PATCH 05/11] tests/boot_linux_console: Use Avocado archive::gzip_uncompress()

[Philippe Mathieu-Daudé]

Avocado 67.0 [*] introduced the avocado.utils.archive module which
provides handling of gzip files. Use the gzip_uncompress() method.

[*] 
https://avocado-framework.readthedocs.io/en/67.0/api/utils/avocado.utils.html#avocado.utils.archive.gzip_uncompress

Suggested-by: Cleber Rosa 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: New patch replacing the gunzip() refactor
---
 tests/acceptance/boot_linux_console.py | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 4b419b0559..67d7e96d98 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -145,10 +145,7 @@ class BootLinuxConsole(Test):
 initrd_hash = 'bf806e17009360a866bf537f6de66590de349a99'
 initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
 initrd_path = self.workdir + "rootfs.cpio"
-
-with gzip.open(initrd_path_gz, 'rb') as f_in:
-with open(initrd_path, 'wb') as f_out:
-shutil.copyfileobj(f_in, f_out)
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
 
 self.vm.set_machine('malta')
 self.vm.set_console()
-- 
2.21.0

[PATCH 01/11] Acceptance tests: refactor wait_for_console_pattern

[Philippe Mathieu-Daudé]

From: Cleber Rosa 

The same utility method is already present in two different test
files, so let's consolidate it into a single utility function.

Signed-off-by: Cleber Rosa 
Message-Id: <20190916164011.7653-1-cr...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
[PMD: failure_message is optional]
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/avocado_qemu/__init__.py | 25 +
 tests/acceptance/boot_linux_console.py| 27 +--
 tests/acceptance/linux_ssh_mips_malta.py  | 18 +++
 3 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index bd41e0443c..e3101cba30 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -8,6 +8,7 @@
 # This work is licensed under the terms of the GNU GPL, version 2 or
 # later.  See the COPYING file in the top-level directory.
 
+import logging
 import os
 import sys
 import uuid
@@ -53,6 +54,30 @@ def pick_default_qemu_bin(arch=None):
 return qemu_bin_from_src_dir_path
 
 
+def wait_for_console_pattern(test, success_message, failure_message=None):
+"""
+Waits for messages to appear on the console, while logging the content
+
+:param test: an Avocado test containing a VM that will have its console
+ read and probed for a success or failure message
+:type test: :class:`avocado_qemu.Test`
+:param success_message: if this message appears, test succeeds
+:param failure_message: if this message appears, test fails
+"""
+console = test.vm.console_socket.makefile()
+console_logger = logging.getLogger('console')
+while True:
+msg = console.readline().strip()
+if not msg:
+continue
+console_logger.debug(msg)
+if success_message in msg:
+break
+if failure_message and failure_message in msg:
+fail = 'Failure message found in console: %s' % failure_message
+test.fail(fail)
+
+
 class Test(avocado.Test):
 def setUp(self):
 self._vms = {}
diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 8a9a314ab4..8897e0c253 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -9,12 +9,12 @@
 # later.  See the COPYING file in the top-level directory.
 
 import os
-import logging
 import lzma
 import gzip
 import shutil
 
 from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
 
@@ -29,31 +29,14 @@ class BootLinuxConsole(Test):
 
 KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
 
-def wait_for_console_pattern(self, success_message,
- failure_message='Kernel panic - not syncing'):
-"""
-Waits for messages to appear on the console, while logging the content
-
-:param success_message: if this message appears, test succeeds
-:param failure_message: if this message appears, test fails
-"""
-console = self.vm.console_socket.makefile()
-console_logger = logging.getLogger('console')
-while True:
-msg = console.readline().strip()
-if not msg:
-continue
-console_logger.debug(msg)
-if success_message in msg:
-break
-if failure_message in msg:
-fail = 'Failure message found in console: %s' % failure_message
-self.fail(fail)
+def wait_for_console_pattern(self, success_message):
+wait_for_console_pattern(self, success_message,
+ failure_message='Kernel panic - not syncing')
 
 def exec_command_and_wait_for_pattern(self, command, success_message):
 command += '\n'
 self.vm.console_socket.sendall(command.encode())
-self.wait_for_console_pattern(success_message)
+wait_for_console_pattern(self, success_message)
 
 def extract_from_deb(self, deb, path):
 """
diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index 25a1df5098..ffbb06f846 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -13,6 +13,7 @@ import time
 
 from avocado import skipUnless
 from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
 from avocado.utils import ssh
@@ -40,19 +41,6 @@ class LinuxSSH(Test):
 def setUp(self):
 super(LinuxSSH, self).setUp()
 
-def wait_for_console_pattern(self, success_message,
- failure_message='Oops'):
-console = self.vm.console_socket.makefile()
-console_logger = logging.getLogger('console')
- 

[PATCH 07/11] tests/ssh_linux_malta: Run tests using a snapshot image

[Philippe Mathieu-Daudé]

If a test fails, it can corrupt the underlying QCow2 image,
making further tests failing.
Fix this by running each test with a snapshot.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/linux_ssh_mips_malta.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
b/tests/acceptance/linux_ssh_mips_malta.py
index ffbb06f846..27907e8fbd 100644
--- a/tests/acceptance/linux_ssh_mips_malta.py
+++ b/tests/acceptance/linux_ssh_mips_malta.py
@@ -90,7 +90,7 @@ class LinuxSSH(Test):
 self.vm.add_args('-no-reboot',
  '-kernel', kernel_path,
  '-append', kernel_command_line,
- '-hda', image_path,
+ '-drive', 'file=%s,snapshot=on' % image_path,
  '-netdev', 'user,id=vnet,hostfwd=:127.0.0.1:0-:22',
  '-device', 'pcnet,netdev=vnet')
 self.vm.launch()
-- 
2.21.0

[PATCH 00/11] tests/acceptance: Fix 64-bit MIPS target tests

[Philippe Mathieu-Daudé]

From: PhilMD 

Commit 9090d3332cdcc introduced a regression which makes the
64-bit target tests to fail.

This series fix it (by previously refactoring the linux_ssh_malta
test), and also add another test for the 5KEc CPU.

I had to include Avocado-related patches not yet merged again to
avoid sending patches that will later not apply.

Please review,

Phil.

Cleber Rosa (1):
  Acceptance tests: refactor wait_for_console_pattern

Philippe Mathieu-Daudé (10):
  tests/acceptance: Fixe wait_for_console_pattern() hangs
  tests/acceptance: Send  on serial lines
  tests/acceptance: Refactor exec_command_and_wait_for_pattern()
  tests/boot_linux_console: Use Avocado archive::gzip_uncompress()
  tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu
  tests/ssh_linux_malta: Run tests using a snapshot image
  tests/ssh_linux_malta: Remove duplicated test
  tests/ssh_linux_malta: Match stricter console output
  tests/ssh_linux_malta: Refactor how to get image/kernel info
  tests/ssh_linux_malta: Fix 64-bit target tests

 .mailmap  |   1 +
 tests/acceptance/avocado_qemu/__init__.py |  45 
 tests/acceptance/boot_linux_console.py|  88 ---
 tests/acceptance/linux_ssh_mips_malta.py  | 124 +++---
 4 files changed, 159 insertions(+), 99 deletions(-)

-- 
2.21.0

[PATCH 02/11] tests/acceptance: Fixe wait_for_console_pattern() hangs

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

Because of a possible deadlock (QEMU waiting for the socket to
become writable) let's close the console socket as soon as we
stop to use it.

Suggested-by: Cleber Rosa 
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/avocado_qemu/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index e3101cba30..a0450e5263 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -74,6 +74,7 @@ def wait_for_console_pattern(test, success_message, 
failure_message=None):
 if success_message in msg:
 break
 if failure_message and failure_message in msg:
+console.close()
 fail = 'Failure message found in console: %s' % failure_message
 test.fail(fail)
 
-- 
2.21.0

[PATCH 03/11] tests/acceptance: Send on serial lines

[Philippe Mathieu-Daudé]

Some firmwares don't parse the  control character and
expect a .

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/boot_linux_console.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 8897e0c253..497faa4f7f 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -34,7 +34,7 @@ class BootLinuxConsole(Test):
  failure_message='Kernel panic - not syncing')
 
 def exec_command_and_wait_for_pattern(self, command, success_message):
-command += '\n'
+command += '\r\n'
 self.vm.console_socket.sendall(command.encode())
 wait_for_console_pattern(self, success_message)
 
-- 
2.21.0

[PATCH 06/11] tests/boot_linux_console: Run BusyBox on 5KEc 64-bit cpu

[Philippe Mathieu-Daudé]

This tests boots a Linux kernel on a Malta machine up to a
busybox shell on the serial console. Few commands are executed
before halting the machine (via reboot).

We use the Fedora 24 kernel extracted from the image at:
https://fedoraproject.org/wiki/Architectures/MIPS
and the initrd cpio image from the kerneltests project:
https://kerneltests.org/

If MIPS is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips" tags.

Alternatively, this test can be run using:

  $ avocado --show=console run -t arch:mips64el 
tests/acceptance/boot_linux_console.py
  console: [0.00] Linux version 3.19.3.mtoman.20150408 
(mtoman@debian-co3-1) (gcc version 5.0.0 20150316 (Red Hat 5.0.0-0.20) (GCC) ) 
#3 Wed Apr 8 14:32:50 UTC 2015
  console: [0.00] Early serial console at I/O port 0x3f8 (options 
'38400n8')
  console: [0.00] bootconsole [uart0] enabled
  console: [0.00] CPU0 revision is: 00018900 (MIPS 5KE)
  console: [0.00] Checking for the multiply/shift bug... no.
  console: [0.00] Checking for the daddiu bug... no.
  [...]
  console: Boot successful.
  console: cat /proc/cpuinfo
  console: / # cat /proc/cpuinfo
  console: system type: MIPS Malta
  console: machine: Unknown
  console: processor  : 0
  console: cpu model  : MIPS 5KE V0.0
  console: : 1616.89
  console: wait instruction   : nouname -a
  console: microsecond timers : yes
  console: tlb_entries: 32
  console: extra interrupt vector : yes
  console: hardware watchpoint: yes, count: 1, address/irw mask: [0x0ff8]
  console: isa: mips1 mips2 mips3 mips4 mips5 mips32r1 
mips32r2 mips64r1 mips64r2
  console: ASEs implemented   :
  console: shadow register sets   : 1
  console: kscratch registers : 0
  console: package: 0
  console: core   : 0
  console: VCED exceptions: not available
  console: VCEI exceptions: not available
  console: / #
  console: / # uname -a
  console: Linux buildroot 3.19.3.mtoman.20150408 #3 Wed Apr 8 14:32:50 UTC 
2015 mips64 GNU/Linux
  console: reboot
  console: / #
  console: / # reboot
  console: / #
  console: / # reboot: Restarting system
  PASS (7.04 s)
  JOB TIME   : 7.20 s

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/boot_linux_console.py | 40 ++
 1 file changed, 40 insertions(+)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 67d7e96d98..e505a41eed 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -166,6 +166,46 @@ class BootLinuxConsole(Test):
 exec_command_and_wait_for_pattern(self, 'reboot',
 'reboot: Restarting system')
 
+def test_mips64el_malta_5KEc_cpio(self):
+"""
+:avocado: tags=arch:mips64el
+:avocado: tags=machine:malta
+:avocado: tags=endian:little
+"""
+kernel_url = ('https://github.com/philmd/qemu-testing-blob/'
+  'raw/9ad2df38/mips/malta/mips64el/'
+  'vmlinux-3.19.3.mtoman.20150408')
+kernel_hash = '00d1d268fb9f7d8beda1de6bebcc46e884d71754'
+kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
+initrd_url = ('https://github.com/groeck/linux-build-test/'
+  'raw/8584a59e/rootfs/'
+  'mipsel64/rootfs.mipsel64r1.cpio.gz')
+initrd_hash = '1dbb8a396e916847325284dbe2151167'
+initrd_path_gz = self.fetch_asset(initrd_url, algorithm='md5',
+  asset_hash=initrd_hash)
+initrd_path = self.workdir + "rootfs.cpio"
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
+
+self.vm.set_machine('malta')
+self.vm.set_console()
+kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE
+   + 'console=ttyS0 console=tty '
+   + 'rdinit=/sbin/init noreboot')
+self.vm.add_args('-cpu', '5KEc',
+ '-kernel', kernel_path,
+ '-initrd', initrd_path,
+ '-append', kernel_command_line,
+ '-no-reboot')
+self.vm.launch()
+wait_for_console_pattern(self, 'Boot successful.')
+
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'MIPS 5KE')
+exec_command_and_wait_for_pattern(self, 'uname -a',
+'3.19.3.mtoman.20150408')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')
+
 def do_test_mips_malta32el_nanomips(self, kernel_url, kerne

Re: [PATCH v2] Do not use %m in common code to print error messages

[Stefano Garzarella]

On Fri, Oct 18, 2019 at 06:01:22PM +0200, Thomas Huth wrote:
> On 18/10/2019 15.49, Kamil Rytarowski wrote:
> > On 18.10.2019 15:42, Stefano Garzarella wrote:
> >> On Fri, Oct 18, 2019 at 03:07:16PM +0200, Thomas Huth wrote:
> >>> The %m format specifier is an extension from glibc - and when compiling
> >>> QEMU for NetBSD, the compiler correctly complains, e.g.:
> >>>
> >>> /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c: In function 
> >>> 'sigfd_handler':
> >>> /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c:64:13: warning: %m is 
> >>> only
> >>>  allowed in syslog(3) like functions [-Wformat=]
> >>>  printf("read from sigfd returned %zd: %m\n", len);
> >>>  ^
> >>> Let's use g_strerror() here instead, which is an easy-to-use wrapper
> >>> around the thread-safe strerror_r() function.
> >>>
> >>> While we're at it, also convert the "printf()" in main-loop.c into
> >>> the preferred "error_report()".
> >>>
> >>> Signed-off-by: Thomas Huth 
> >>> ---
> >>>  v2: Do not try to g_free() the strings
> >>>
> >>>  hw/misc/tmp421.c | 4 ++--
> >>>  util/main-loop.c | 3 ++-
> >>>  util/systemd.c   | 4 ++--
> >>>  3 files changed, 6 insertions(+), 5 deletions(-)
> >>
> >> There are many uses of %m also in hw/vfio/ but that's Linux stuff.
> >> Should we change those too or it doesn't matter since it never really
> >> compiled on NetBSD?
> > 
> > It's a gnu (glibc) extension and linux can use alternative libc
> > implementations. Probably most of them capable to host qemu use %m.
> 
> I think I read somewhere that other libcs on Linux also support %m (like

Good to know!

> musl), but I just can't find that reference anymore. Anyway, we can
> still fix that later in case someone hits the issue.
> 

Yes, make sense to me.

Thanks,
Stefano

[PATCH 1/1] Updated Bulgarian translation (19) - 4.1.0

[Alexander Shopov]

Signed-off-by: Alexander Shopov 
---
 po/bg.po | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/po/bg.po b/po/bg.po
index 3d8c353372..98c57e5b22 100644
--- a/po/bg.po
+++ b/po/bg.po
@@ -1,14 +1,14 @@
 # Bulgarian translation of qemu po-file.
-# Copyright (C) 2016 Alexander Shopov 
+# Copyright (C) 2016, 2019 Alexander Shopov 
 # This file is distributed under the same license as the qemu package.
-# Alexander Shopov , 2016.
+# Alexander Shopov , 2016, 2019.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: QEMU 2.6.50\n"
+"Project-Id-Version: QEMU 4.1.0\n"
 "Report-Msgid-Bugs-To: qemu-devel@nongnu.org\n"
 "POT-Creation-Date: 2018-07-18 07:56+0200\n"
-"PO-Revision-Date: 2016-06-09 15:54+0300\n"
+"PO-Revision-Date: 2019-10-19 13:14+0200\n"
 "Last-Translator: Alexander Shopov \n"
 "Language-Team: Bulgarian \n"
 "Language: bg\n"
@@ -66,7 +66,7 @@ msgid "Detach Tab"
 msgstr "Към самостоятелен подпрозорец"
 
 msgid "Show Menubar"
-msgstr ""
+msgstr "Лента за менюто"
 
 msgid "_Machine"
 msgstr "_Машина"
-- 
2.23.0

[PATCH 0/1] Update Bulgarian translation

[Alexander Shopov]

This is the updated Bulgarian translation of Qemu

It has 1 new message translated and corresponds to v 4.1.0 and up
I am sending to the devel list, the trivial patch list and
all people listes as CC, Tested-By, Approved-By in the po dir
Please ping if that is too wide an audience and point me to
the right targets


Alexander Shopov (1):
  Updated Bulgarian translation (19) - 4.1.0

 po/bg.po | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
2.23.0

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

On 18/10/2019 19:28, Marty E. Plummer wrote:
> Hello,
> 
> First off, thank you for the work you've done on the ppc64 support, it
> has been very useful. I'm currently working on a coreboot port for the
> talos ii line of systems (which means more ppc64 support, support
> specifically for the power9 sforza chip, and specific mainboard support.
> My plate is very full lol) and have been using qemu to debug the
> bootblock.
> 
> It has been very useful for that, but I'm now at the point where I need
> to jump to romstage, and that's where it gets tricky. qemu parses the rom
> image and looks for a ffs header, locates skiboot on it, and jumps straight
> to that. Not exactly ideal for debugging something not produced from op-build.

yes. I suppose you are using my branch powernv-4.2 which adds PNOR support
and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
file to extract the PAYLOAD partition (skiboot). skiboot also detects the
flash and extract the kernel and initramfs from the PNOR.

However, you can bypass all this internal boot process by simply passing
a -bios option and not passing a MTD device.

I haven't published the PNOR support and the boot from PNOR yet. Lack
of time and because sPAPR is the priority.

> Do you think it would be within your wheelhouse to provide a generic, non-ffs
> pnor interface for loading arbitary rom images? 

I should probably send the PNOR patchset now so that we can discuss on 
a better way to satisfy all needs.  

> It would be of great help if
> you could. (This would still hopefully have the bmc support code as
> well, as I'm still needing to support a system using one).

We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
is possible to interconnect them through the BT device. Or you can use
the IPMI BT simulator of QEMU on the PowerNV machine

Thanks,

C. 

[PATCH 1/1] Updated Bulgarian translation (19) - 4.1.0

[Alexander Shopov]

From: Alexander Shopov 

Signed-off-by: Alexander Shopov 
---
 po/bg.po | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/po/bg.po b/po/bg.po
index 3d8c353372..98c57e5b22 100644
--- a/po/bg.po
+++ b/po/bg.po
@@ -1,14 +1,14 @@
 # Bulgarian translation of qemu po-file.
-# Copyright (C) 2016 Alexander Shopov 
+# Copyright (C) 2016, 2019 Alexander Shopov 
 # This file is distributed under the same license as the qemu package.
-# Alexander Shopov , 2016.
+# Alexander Shopov , 2016, 2019.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: QEMU 2.6.50\n"
+"Project-Id-Version: QEMU 4.1.0\n"
 "Report-Msgid-Bugs-To: qemu-devel@nongnu.org\n"
 "POT-Creation-Date: 2018-07-18 07:56+0200\n"
-"PO-Revision-Date: 2016-06-09 15:54+0300\n"
+"PO-Revision-Date: 2019-10-19 13:14+0200\n"
 "Last-Translator: Alexander Shopov \n"
 "Language-Team: Bulgarian \n"
 "Language: bg\n"
@@ -66,7 +66,7 @@ msgid "Detach Tab"
 msgstr "Към самостоятелен подпрозорец"
 
 msgid "Show Menubar"
-msgstr ""
+msgstr "Лента за менюто"
 
 msgid "_Machine"
 msgstr "_Машина"
-- 
2.23.0

[PATCH 0/1] Update Bulgarian translation

[Alexander Shopov]

From: Alexander Shopov 

This is the updated Bulgarian translation of Qemu

It has 1 new message translated and corresponds to v 4.1.0 and up
I am sending to the devel list, the trivial patch list and
all people listes as CC, Tested-By, Approved-By in the po dir
Please ping if that is too wide an audience and point me to
the right targets


Alexander Shopov (1):
  Updated Bulgarian translation (19) - 4.1.0

 po/bg.po | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
2.23.0

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 10:15:19PM +1100, David Gibson wrote:
> On Fri, Oct 18, 2019 at 12:28:29PM -0500, Marty E. Plummer wrote:
> > Hello,
> > 
> > First off, thank you for the work you've done on the ppc64 support, it
> > has been very useful. I'm currently working on a coreboot port for the
> > talos ii line of systems (which means more ppc64 support, support
> > specifically for the power9 sforza chip, and specific mainboard support.
> > My plate is very full lol) and have been using qemu to debug the
> > bootblock.
> 
> Ok.  I'm assuming that's with the powernv machine type?
> 
Assuming you mean the hardware, yes, the kernel for it is configured
with the powernv_defconfig.

Assuming that you mean how I call qemu, yes, also powernv: my full
command is:

qemu-system-ppc64 -cpu power9 -M powernv -m 4G -s -S \
-chardev socket,id=qemu-monitor,host=localhost,port=,server,nowait,telnet \
-mon qemu-monitor,mode=readline -nographic -bios 
build/cbfs/fallback/bootblock.bin
> > It has been very useful for that, but I'm now at the point where I need
> > to jump to romstage, and that's where it gets tricky. qemu parses the rom
> > image and looks for a ffs header, locates skiboot on it, and jumps straight
> > to that. Not exactly ideal for debugging something not produced from
> > op-build.
> 
> Um.. I'm not sure what code you're talking about.  AFAICT the pnv code
> just starts the cpus at address 0x10.
> 
If I pass it the full coreboot.rom file via
`-drive file=./build/coreboot.rom,format=raw,if=mtd` it returns this error:
'qemu-system-ppc64: Initialization of device pnv-pnor failed: bad header'
which arises in hw/ppc/pnv_pnor.c:136-140 using legoater's powernv-4.2
branch.

Ah, so I wasn't going crazy and it was skipping the first four instructions,
how odd. Any particular reason the first four instruction are skipped?
On hostboot that's setting up the msr; on skiboot that seems to be the
fdt_entry branch to boot_entry.
> > Do you think it would be within your wheelhouse to provide a generic, 
> > non-ffs
> > pnor interface for loading arbitary rom images? It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> Uh.. and I'm not really sure what you're asking for here.
> 
Basically not have to have a pnor-style image for mtd devices, and not
immidiatly jump to skiboot.
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Re: [PATCH 7/8] hw/m68k/mcf5206.c: Switch to transaction-based ptimer API

[Thomas Huth]

Am Sat, 19 Oct 2019 13:10:27 +0200
schrieb Thomas Huth :

> Am Sat, 19 Oct 2019 12:48:59 +0200
> schrieb Thomas Huth :
> 
> > Am Thu, 17 Oct 2019 14:29:04 +0100
> > schrieb Peter Maydell :
> > 
> > > Switch the mcf5206 code away from bottom-half based ptimers to
> > > the new transaction-based ptimer API.  This just requires adding
> > > begin/commit calls around the various places that modify the
> > > ptimer state, and using the new ptimer_init() function to create
> > > the timer.
> > > 
> > > Signed-off-by: Peter Maydell 
> > > ---
> > >  hw/m68k/mcf5206.c | 9 +
> > >  1 file changed, 5 insertions(+), 4 deletions(-)  
> > 
> > After applying the patch, I now get an assertion:
> > 
> > $ qemu-system-m68k -nographic -kernel
> > ~/tmp/images/image-an5206-big-2706.bin -M an5206
> > 
> > uClinux/COLDFIRE(m5206)
> > COLDFIRE port done by Greg Ungerer, g...@moreton.com.au
> > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> > KERNEL -> TEXT=0x01-0x077cb8 DATA=0x077cb8-0x08b0d0
> > BSS=0x08b0d0-0x0a2d58 KERNEL -> ROMFS=0x0a2d58-0x183b10
> > MEM=0x183b10-0x1fff000 STACK=0x1fff000-0x200 qemu-system-m68k:
> > hw/core/ptimer.c:410: ptimer_transaction_begin: Assertion
> > `!s->in_transaction || !s->callback' failed.
> > 
> > Looks like something is still wrong here...

Looking at the code a little bit, I think you missed the early return
in m5206_timer_recalibrate() :

if ((s->tmr & TMR_RST) == 0)
return;

That needs a ptimer_transaction_commit() now, too.

 Thomas

Re: qemu/powernv: coreboot support?

[David Gibson]

On Fri, Oct 18, 2019 at 12:28:29PM -0500, Marty E. Plummer wrote:
> Hello,
> 
> First off, thank you for the work you've done on the ppc64 support, it
> has been very useful. I'm currently working on a coreboot port for the
> talos ii line of systems (which means more ppc64 support, support
> specifically for the power9 sforza chip, and specific mainboard support.
> My plate is very full lol) and have been using qemu to debug the
> bootblock.

Ok.  I'm assuming that's with the powernv machine type?

> It has been very useful for that, but I'm now at the point where I need
> to jump to romstage, and that's where it gets tricky. qemu parses the rom
> image and looks for a ffs header, locates skiboot on it, and jumps straight
> to that. Not exactly ideal for debugging something not produced from
> op-build.

Um.. I'm not sure what code you're talking about.  AFAICT the pnv code
just starts the cpus at address 0x10.

> Do you think it would be within your wheelhouse to provide a generic, non-ffs
> pnor interface for loading arbitary rom images? It would be of great help if
> you could. (This would still hopefully have the bmc support code as
> well, as I'm still needing to support a system using one).

Uh.. and I'm not really sure what you're asking for here.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH 7/8] hw/m68k/mcf5206.c: Switch to transaction-based ptimer API

[Thomas Huth]

Am Sat, 19 Oct 2019 12:48:59 +0200
schrieb Thomas Huth :

> Am Thu, 17 Oct 2019 14:29:04 +0100
> schrieb Peter Maydell :
> 
> > Switch the mcf5206 code away from bottom-half based ptimers to
> > the new transaction-based ptimer API.  This just requires adding
> > begin/commit calls around the various places that modify the ptimer
> > state, and using the new ptimer_init() function to create the timer.
> > 
> > Signed-off-by: Peter Maydell 
> > ---
> >  hw/m68k/mcf5206.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)  
> 
> After applying the patch, I now get an assertion:
> 
> $ qemu-system-m68k -nographic -kernel
> ~/tmp/images/image-an5206-big-2706.bin -M an5206
> 
> uClinux/COLDFIRE(m5206)
> COLDFIRE port done by Greg Ungerer, g...@moreton.com.au
> Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> KERNEL -> TEXT=0x01-0x077cb8 DATA=0x077cb8-0x08b0d0
> BSS=0x08b0d0-0x0a2d58 KERNEL -> ROMFS=0x0a2d58-0x183b10
> MEM=0x183b10-0x1fff000 STACK=0x1fff000-0x200 qemu-system-m68k:
> hw/core/ptimer.c:410: ptimer_transaction_begin: Assertion
> `!s->in_transaction || !s->callback' failed.
> 
> Looks like something is still wrong here...

FWIW, the image for testing can be found here:

https://web.archive.org/web/20181018135822/http://www.uclinux.org/ports/coldfire/image-an5206-big-2706.bin.gz

 Thomas

Re: [PATCH 7/8] hw/m68k/mcf5206.c: Switch to transaction-based ptimer API

[Thomas Huth]

Am Thu, 17 Oct 2019 14:29:04 +0100
schrieb Peter Maydell :

> Switch the mcf5206 code away from bottom-half based ptimers to
> the new transaction-based ptimer API.  This just requires adding
> begin/commit calls around the various places that modify the ptimer
> state, and using the new ptimer_init() function to create the timer.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/m68k/mcf5206.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

After applying the patch, I now get an assertion:

$ qemu-system-m68k -nographic -kernel
~/tmp/images/image-an5206-big-2706.bin -M an5206

uClinux/COLDFIRE(m5206)
COLDFIRE port done by Greg Ungerer, g...@moreton.com.au
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x01-0x077cb8 DATA=0x077cb8-0x08b0d0 BSS=0x08b0d0-0x0a2d58
KERNEL -> ROMFS=0x0a2d58-0x183b10 MEM=0x183b10-0x1fff000 
STACK=0x1fff000-0x200
qemu-system-m68k: hw/core/ptimer.c:410: ptimer_transaction_begin: Assertion 
`!s->in_transaction || !s->callback' failed.

Looks like something is still wrong here...

 Thomas

Re: [PATCH 8/8] hw/m68k/mcf5208.c: Switch to transaction-based ptimer API

[Thomas Huth]

Am Thu, 17 Oct 2019 14:29:05 +0100
schrieb Peter Maydell :

> Switch the mcf5208 code away from bottom-half based ptimers to
> the new transaction-based ptimer API.  This just requires adding
> begin/commit calls around the various places that modify the ptimer
> state, and using the new ptimer_init() function to create the timer.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/m68k/mcf5208.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

This patch seems to work fine.

Tested-by: Thomas Huth 

Re: [PATCH v2 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191018134754.16362-1-phi...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PATCH v2 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX 
northbridge
Type: series
Message-id: 20191018134754.16362-1-phi...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
1f84f10 hw/pci-host/i440fx: Remove the last PIIX3 traces
717a0a4 hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
1294b7c hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
23d43d0 hw/pci-host/piix: Fix code style issues
6e0ce49 hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
d1ac4b6 hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
cb5243e hw/pci-host/piix: Move RCR_IOPORT register definition
d5e122f hw/pci-host/piix: Extract piix3_create()
c544fb9 hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
c3c706e hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
7fad3f2 hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
dde8f42 hw/mips/mips_malta: Create IDE hard drive array dynamically
349a8de piix4: Add a MC146818 RTC Controller as specified in datasheet
2ad1333 piix4: Add a i8254 PIT Controller as specified in datasheet
041f420 piix4: Add a i8257 DMA Controller as specified in datasheet
9cf3651 piix4: Rename PIIX4 object to piix4-isa
a27841e Revert "irq: introduce qemu_irq_proxy()"
7d9534a piix4: Add a i8259 Interrupt Controller as specified in datasheet
6498930 piix4: Add the Reset Control Register
90cd7d4 MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets

=== OUTPUT BEGIN ===
1/20 Checking commit 90cd7d4f5eb5 (MAINTAINERS: Keep PIIX4 South Bridge 
separate from PC Chipsets)
2/20 Checking commit 64989309a9b5 (piix4: Add the Reset Control Register)
3/20 Checking commit 7d9534a284e9 (piix4: Add a i8259 Interrupt Controller as 
specified in datasheet)
4/20 Checking commit a27841e2b3ca (Revert "irq: introduce qemu_irq_proxy()")
5/20 Checking commit 9cf3651f77e2 (piix4: Rename PIIX4 object to piix4-isa)
6/20 Checking commit 041f4205783d (piix4: Add a i8257 DMA Controller as 
specified in datasheet)
7/20 Checking commit 2ad1333a3a5f (piix4: Add a i8254 PIT Controller as 
specified in datasheet)
8/20 Checking commit 349a8deab686 (piix4: Add a MC146818 RTC Controller as 
specified in datasheet)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#194: 
deleted file mode 100644

total: 0 errors, 1 warnings, 166 lines checked

Patch 8/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/20 Checking commit dde8f42302df (hw/mips/mips_malta: Create IDE hard drive 
array dynamically)
10/20 Checking commit 7fad3f28aa86 (hw/mips/mips_malta: Extract the PIIX4 
creation code as piix4_create())
11/20 Checking commit c3c706e79403 (hw/isa/piix4: Move piix4_create() to 
hw/isa/piix4.c)
12/20 Checking commit c544fb98aa67 (hw/i386: Remove obsolete 
LoadStateHandler::load_state_old handlers)
13/20 Checking commit d5e122f286e4 (hw/pci-host/piix: Extract piix3_create())
14/20 Checking commit cb5243e8b4a0 (hw/pci-host/piix: Move RCR_IOPORT register 
definition)
15/20 Checking commit d1ac4b60c55c (hw/pci-host/piix: Define and use the PIIX 
IRQ Route Control Registers)
16/20 Checking commit 6e0ce49c6fb6 (hw/pci-host/piix: Move i440FX declarations 
to hw/pci-host/i440fx.h)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#99: 
new file mode 100644

total: 0 errors, 1 warnings, 101 lines checked

Patch 16/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
17/20 Checking commit 23d43d03d057 (hw/pci-host/piix: Fix code style issues)
18/20 Checking commit 1294b7c961d3 (hw/pci-host/piix: Extract PIIX3 functions 
to hw/isa/piix3.c)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#66: 
new file mode 100644

ERROR: spaces required around that '*' (ctx:VxV)
#315: FILE: hw/isa/piix3.c:245:
+.subsections = (const VMStateDescription*[]) {
 ^

total: 1 errors, 1 warnings, 937 lines checked

Patch 18/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

19/20 Checking commit 717a0a47f89a (hw/pci-host: Rename incorrectly named 
'piix' as 'i440fx')
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#70: 
rename from hw/pci-host/piix.c

total: 0 errors, 1 warnings, 32 

Re: [PATCH v2 2/2] migration: savevm_state_handler_insert: constant-time element insertion

[David Gibson]

On Fri, Oct 18, 2019 at 10:43:52AM +0100, Dr. David Alan Gilbert wrote:
> * Laurent Vivier (lviv...@redhat.com) wrote:
> > On 18/10/2019 10:16, Dr. David Alan Gilbert wrote:
> > > * Scott Cheloha (chel...@linux.vnet.ibm.com) wrote:
> > >> savevm_state's SaveStateEntry TAILQ is a priority queue.  Priority
> > >> sorting is maintained by searching from head to tail for a suitable
> > >> insertion spot.  Insertion is thus an O(n) operation.
> > >>
> > >> If we instead keep track of the head of each priority's subqueue
> > >> within that larger queue we can reduce this operation to O(1) time.
> > >>
> > >> savevm_state_handler_remove() becomes slightly more complex to
> > >> accomodate these gains: we need to replace the head of a priority's
> > >> subqueue when removing it.
> > >>
> > >> With O(1) insertion, booting VMs with many SaveStateEntry objects is
> > >> more plausible.  For example, a ppc64 VM with maxmem=8T has 4 such
> > >> objects to insert.
> > > 
> > > Separate from reviewing this patch, I'd like to understand why you've
> > > got 4 objects.  This feels very very wrong and is likely to cause
> > > problems to random other bits of qemu as well.
> > 
> > I think the 4 objects are the "dr-connectors" that are used to plug
> > peripherals (memory, pci card, cpus, ...).
> 
> Yes, Scott confirmed that in the reply to the previous version.
> IMHO nothing in qemu is designed to deal with that many devices/objects
> - I'm sure that something other than the migration code is going to
> get upset.

It kind of did.  Particularly when there was n^2 and n^3 cubed
behaviour in the property stuff we had some ludicrously long startup
times (hours) with large maxmem values.

Fwiw, the DRCs for PCI slots, DRCs and PHBs aren't really a problem.
The problem is the memory DRCs, there's one for each LMB - each 256MiB
chunk of memory (or possible memory).

> Is perhaps the structure wrong somewhere - should there be a single DRC
> device that knows about all DRCs?

Maybe.  The tricky bit is how to get there from here without breaking
migration or something else along the way.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v5 00/13] Multi-phase reset mechanism

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191018150630.31099-1-damien.he...@greensocs.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  hw/virtio/trace.o
  CC  hw/watchdog/trace.o

Warning, treated as error:
/tmp/qemu-test/src/docs/devel/reset.rst:document isn't included in any toctree
  CC  hw/xen/trace.o
  CC  hw/gpio/trace.o
---
  CC  stubs/bdrv-next-monitor-owned.o
  CC  stubs/blk-commit-all.o
  CC  stubs/blockdev-close-all-bdrv-states.o
make: *** [Makefile:994: docs/devel/index.html] Error 2
make: *** Waiting for unfinished jobs
  CC  stubs/clock-warp.o
Traceback (most recent call last):
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=d026138e19654e3c80d1650d68316bd0', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-if7vrvxd/src/docker-src.2019-10-19-04.59.52.1:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=d026138e19654e3c80d1650d68316bd0
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-if7vrvxd/src'
make: *** [docker-run-test-mingw@fedora] Error 2

real1m44.422s
user0m7.664s


The full log is available at
http://patchew.org/logs/20191018150630.31099-1-damien.he...@greensocs.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v5 1/3] tests/vm: netbsd autoinstall, using serial console

[Thomas Huth]

On 18/10/2019 20.17, Eduardo Habkost wrote:
> From: Gerd Hoffmann 
> 
> Instead of fetching the prebuilt image from patchew download the install
> iso and prepare the image locally.  Install to disk, using the serial
> console.  Create qemu user, configure ssh login.  Install packages
> needed for qemu builds.
> 
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Kamil Rytarowski 
> Tested-by: Thomas Huth 
> [ehabkost: rebased to latest qemu.git master]
> Signed-off-by: Eduardo Habkost 
> ---
>  tests/vm/netbsd | 189 +---
>  1 file changed, 179 insertions(+), 10 deletions(-)
> 
> diff --git a/tests/vm/netbsd b/tests/vm/netbsd
> index ee9eaeab50..49a99477f4 100755
> --- a/tests/vm/netbsd
> +++ b/tests/vm/netbsd
> @@ -2,10 +2,11 @@
>  #
>  # NetBSD VM image
>  #
> -# Copyright 2017 Red Hat Inc.
> +# Copyright 2017-2019 Red Hat Inc.
>  #
>  # Authors:
>  #  Fam Zheng 
> +#  Gerd Hoffmann 
>  #
>  # This code is licensed under the GPL version 2 or later.  See
>  # the COPYING file in the top-level directory.
> @@ -13,30 +14,198 @@
>  
>  import os
>  import sys
> +import time
>  import subprocess
>  import basevm
>  
>  class NetBSDVM(basevm.BaseVM):
>  name = "netbsd"
>  arch = "x86_64"
> +
> +link = 
> "https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.0/images/NetBSD-8.0-amd64.iso";

I'd like to suggest to go immediately with 8.1 instead of 8.0. I tested
it and it worked for me out-of-the-box, without further modifications.

> +
> +if os.path.exists(img):
> +os.remove(img)

These two lines have been removed recently with commit
fcd2060e8efff83b7bdef04323077f87e011fdc4 ... please drop them from the
patch.

 Thanks,
  Thomas