date:20191230

Re: [Bug 1818937] Crash with HV_ERROR on macOS host

2019-12-30 Thread Cameron Esfahani via

Try against 4.2.

Cameron Esfahani
di...@apple.com

"In the elder days of Art, Builders wrought with greatest care each minute and 
unseen part; For the gods see everywhere."

"The Builders", H. W. Longfellow



> On Dec 30, 2019, at 8:41 AM, Alex Fliker  
> wrote:
> 
> Are there any updates? Trying to run the IE11 image from Microsoft
> (based on Windows 8.1) and it is crashing with this error sporadically
> :-\
> 
> -- 
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1818937
> 
> Title:
>  Crash with HV_ERROR on macOS host
> 
> Status in QEMU:
>  New
> 
> Bug description:
>  On macOS host running Windows 10 guest, qemu crashed with error
>  message: Error: HV_ERROR.
> 
>  Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 
> 4278U.
>  QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560
>  QEMU parameter: qemu-system-x86_64 -m 3000 -drive 
> file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3
> 
>  thread list
>  Process 56054 stopped
>thread #1: tid = 0x2ffec8, 0x7fff48d0805a vImage`vLookupTable_Planar16 
> + 970, queue = 'com.apple.main-thread'
>thread #2: tid = 0x2ffecc, 0x7fff79d6d7de 
> libsystem_kernel.dylib`__psynch_cvwait + 10
>thread #3: tid = 0x2ffecd, 0x7fff79d715aa 
> libsystem_kernel.dylib`__select + 10
>thread #4: tid = 0x2ffece, 0x7fff79d71d9a 
> libsystem_kernel.dylib`__sigwait + 10
>  * thread #6: tid = 0x2ffed0, 0x7fff79d7023e 
> libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
>thread #7: tid = 0x2ffed1, 0x7fff79d6d7de 
> libsystem_kernel.dylib`__psynch_cvwait + 10
>thread #8: tid = 0x2ffed2, 0x7fff79d6d7de 
> libsystem_kernel.dylib`__psynch_cvwait + 10
>thread #11: tid = 0x2fff34, 0x7fff79d6a17a 
> libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread'
>thread #30: tid = 0x300c04, 0x7fff79e233f8 
> libsystem_pthread.dylib`start_wqthread
>thread #31: tid = 0x300c16, 0x7fff79e233f8 
> libsystem_pthread.dylib`start_wqthread
>thread #32: tid = 0x300c17, 0x
>thread #33: tid = 0x300c93, 0x7fff79d6d7de 
> libsystem_kernel.dylib`__psynch_cvwait + 10
> 
> 
>  Crashed thread:
> 
>  * thread #6, stop reason = signal SIGABRT
>* frame #0: 0x7fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10
>  frame #1: 0x7fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285
>  frame #2: 0x7fff79cd91c9 libsystem_c.dylib`abort + 127
>  frame #3: 0x00010baa476d 
> qemu-system-x86_64`assert_hvf_ok(ret=) at hvf.c:106 [opt]
>  frame #4: 0x00010baa4c8f 
> qemu-system-x86_64`hvf_vcpu_exec(cpu=0x7f8e5283de00) at hvf.c:681 [opt]
>  frame #5: 0x00010b988423 
> qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x7f8e5283de00) at 
> cpus.c:1636 [opt]
>  frame #6: 0x00010bd9dfce 
> qemu-system-x86_64`qemu_thread_start(args=) at 
> qemu-thread-posix.c:502 [opt]
>  frame #7: 0x7fff79e24305 libsystem_pthread.dylib`_pthread_body + 126
>  frame #8: 0x7fff79e2726f libsystem_pthread.dylib`_pthread_start + 70
>  frame #9: 0x7fff79e23415 libsystem_pthread.dylib`thread_start + 13
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1818937/+subscriptions
>

Re: [PATCH] display/gtk: get proper refreshrate

2019-12-30 Thread Philippe Mathieu-Daudé

Hi Nikola,

Thanks for your patch!

On 12/30/19 6:28 PM, Nikola Pavlica wrote:

 From 70c95b18fa056b2dd0ecc202ab517bc775b986da Mon Sep 17 00:00:00 2001
From: Nikola Pavlica 
Date: Mon, 30 Dec 2019 18:17:35 +0100
Subject: [PATCH] display/gtk: get proper refreshrate

Can you describe here the problem you encountered, and how your patch 
fixes it?

Signed-off-by: Nikola Pavlica 
---
  ui/gtk.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/ui/gtk.c b/ui/gtk.c
index 692ccc7bbb..7a041457f2 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2259,6 +2259,11 @@ static void gtk_display_init(DisplayState *ds,
DisplayOptions *opts)
  opts->u.gtk.grab_on_hover) {
  gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));
  }
+
+GdkDisplay *display = gdk_display_get_default();

Can we use window_display declared earlier instead?

window_display = gtk_widget_get_display(s->window);

If you look at the CODING_STYLE.rst file referenced here:
https://wiki.qemu.org/Contribute/SubmitAPatch#Use_the_QEMU_coding_style
It states:

  Declarations

  Mixed declarations (interleaving statements and declarations
  within blocks) are generally not allowed; declarations should
  be at the beginning of blocks.

So you should move the declaration of both display/monitor variables 
earlier, around line 2192.

+GdkMonitor *monitor = gdk_display_get_primary_monitor(display);
+vc->gfx.dcl.update_interval = 100 /
+gdk_monitor_get_refresh_rate(monitor);

Now looking at this line, I think this should be done in the 
gd_vc_gfx_init() function (line 2029, before the 
register_displaychangelistener() call).

  }

  static void early_gtk_display_init(DisplayOptions *opts)

As suggested on IRC, your patch have more chances to get reviewed if you 
Cc its maintainers. See this help here:

https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer

In this case we get:

$ ./scripts/get_maintainer.pl -f ui/gtk.c
Gerd Hoffmann  (odd fixer:Graphics)
qemu-devel@nongnu.org (open list:All patches CC here)

I'm Cc'ing Gerd for you.

Regards,

Phil.

qemu_set_fd_handler callback is delayed

2019-12-30 Thread Eltahawy, Mahmoud

Hi,

I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for 
qemu_set_fd_handler that the callback for reading from a file descriptor is 
delayed then expected while the file descriptor(socket) has a data to read.

I register a callback for reading from a socket using qemu_set_fd_handler and 
during runtime, this callback is not invoked for about 14msec, however the 
socket has a data available for read. I tested this behavior by just creating a 
pthread which periodically checks the socket for any data using 
ioctl(socket_fd, FIONREAD, ), and for a period of 14ms, I found that the 
pthread indicates there is a data in the socket while the qemu_set_fd_handler 
didn't trigger the read callback.

Any advice?


Thanks
Mahmoud

[Bug 1818937] Re: Crash with HV_ERROR on macOS host

2019-12-30 Thread Alex Fliker

Are there any updates? Trying to run the IE11 image from Microsoft
(based on Windows 8.1) and it is crashing with this error sporadically
:-\

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

Title:
  Crash with HV_ERROR on macOS host

Status in QEMU:
  New

Bug description:
  On macOS host running Windows 10 guest, qemu crashed with error
  message: Error: HV_ERROR.

  Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 
4278U.
  QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560
  QEMU parameter: qemu-system-x86_64 -m 3000 -drive 
file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3

  thread list
  Process 56054 stopped
thread #1: tid = 0x2ffec8, 0x7fff48d0805a vImage`vLookupTable_Planar16 
+ 970, queue = 'com.apple.main-thread'
thread #2: tid = 0x2ffecc, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #3: tid = 0x2ffecd, 0x7fff79d715aa 
libsystem_kernel.dylib`__select + 10
thread #4: tid = 0x2ffece, 0x7fff79d71d9a 
libsystem_kernel.dylib`__sigwait + 10
  * thread #6: tid = 0x2ffed0, 0x7fff79d7023e 
libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
thread #7: tid = 0x2ffed1, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #8: tid = 0x2ffed2, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #11: tid = 0x2fff34, 0x7fff79d6a17a 
libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread'
thread #30: tid = 0x300c04, 0x7fff79e233f8 
libsystem_pthread.dylib`start_wqthread
thread #31: tid = 0x300c16, 0x7fff79e233f8 
libsystem_pthread.dylib`start_wqthread
thread #32: tid = 0x300c17, 0x
thread #33: tid = 0x300c93, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10

  
  Crashed thread:

  * thread #6, stop reason = signal SIGABRT
* frame #0: 0x7fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10
  frame #1: 0x7fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285
  frame #2: 0x7fff79cd91c9 libsystem_c.dylib`abort + 127
  frame #3: 0x00010baa476d 
qemu-system-x86_64`assert_hvf_ok(ret=) at hvf.c:106 [opt]
  frame #4: 0x00010baa4c8f 
qemu-system-x86_64`hvf_vcpu_exec(cpu=0x7f8e5283de00) at hvf.c:681 [opt]
  frame #5: 0x00010b988423 
qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x7f8e5283de00) at 
cpus.c:1636 [opt]
  frame #6: 0x00010bd9dfce 
qemu-system-x86_64`qemu_thread_start(args=) at 
qemu-thread-posix.c:502 [opt]
  frame #7: 0x7fff79e24305 libsystem_pthread.dylib`_pthread_body + 126
  frame #8: 0x7fff79e2726f libsystem_pthread.dylib`_pthread_start + 70
  frame #9: 0x7fff79e23415 libsystem_pthread.dylib`thread_start + 13

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

[PATCH] display/gtk: get proper refreshrate

2019-12-30 Thread Nikola Pavlica

>From 70c95b18fa056b2dd0ecc202ab517bc775b986da Mon Sep 17 00:00:00 2001
From: Nikola Pavlica 
Date: Mon, 30 Dec 2019 18:17:35 +0100
Subject: [PATCH] display/gtk: get proper refreshrate

Signed-off-by: Nikola Pavlica 
---
 ui/gtk.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ui/gtk.c b/ui/gtk.c
index 692ccc7bbb..7a041457f2 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2259,6 +2259,11 @@ static void gtk_display_init(DisplayState *ds,
DisplayOptions *opts)
 opts->u.gtk.grab_on_hover) {
 gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));
 }
+
+GdkDisplay *display = gdk_display_get_default();
+GdkMonitor *monitor = gdk_display_get_primary_monitor(display);
+vc->gfx.dcl.update_interval = 100 /
+gdk_monitor_get_refresh_rate(monitor);
 }
 
 static void early_gtk_display_init(DisplayOptions *opts)
-- 
2.24.0

Re: [PATCH 1/6] tests/boot_linux_console: Add initrd test for the CubieBoard

2019-12-30 Thread Wainer dos Santos Moschetta




On 12/30/19 9:09 AM, Philippe Mathieu-Daudé wrote:

This test boots a Linux kernel on a CubieBoard and verify
the serial output is working.

The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://docs.armbian.com/Developer-Guide_Build-Preparation/

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

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

Alternatively, this test can be run using:

   $ avocado --show=console run -t machine:cubieboard 
tests/acceptance/boot_linux_console.py
   console: Uncompressing Linux... done, booting the kernel.
   console: Booting Linux on physical CPU 0x0
   console: Linux version 4.20.7-sunxi (r...@armbian.com) (gcc version 7.2.1 
20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019
   console: CPU: ARMv7 Processor [410fc080] revision 0 (ARMv7), cr=50c5387d
   console: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
   console: OF: fdt: Machine model: Cubietech Cubieboard
   [...]
   console: Boot successful.
   console: cat /proc/cpuinfo
   console: / # cat /proc/cpuinfo
   console: processor  : 0
   console: model name : ARMv7 Processor rev 0 (v7l)
   console: BogoMIPS   : 832.51
   [...]
   console: Hardware   : Allwinner sun4i/sun5i Families
   console: Revision   : 
   console: Serial : 
   console: cat /proc/iomem
   console: / # cat /proc/iomem
   console: 01c0-01c0002f : system-control@1c0
   console: 01c02000-01c02fff : dma-controller@1c02000
   console: 01c05000-01c05fff : spi@1c05000
   console: 01c0b080-01c0b093 : mdio@1c0b080
   console: 01c0c000-01c0cfff : lcd-controller@1c0c000
   console: 01c0d000-01c0dfff : lcd-controller@1c0d000
   console: 01c0f000-01c0 : mmc@1c0f000
   [...]
   PASS (54.35 s)

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

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 9c6aa2040a..4643f60e37 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -400,6 +400,47 @@ class BootLinuxConsole(Test):
  self.wait_for_console_pattern('Boot successful.')
  # TODO user command, for now the uart is stuck
  
+def test_arm_cubieboard_initrd(self):


Unless you have two tests, one with and without initrd (not the case 
though) the suffix '_initrd' is useless. So I suggest to remove it.



+"""
+:avocado: tags=arch:arm
+:avocado: tags=machine:cubieboard
+"""
+deb_url = ('https://apt.armbian.com/pool/main/l/'
+   'linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb')
+deb_hash = '1334c29c44d984ffa05ed10de8c3361f33d78315'
+deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+kernel_path = self.extract_from_deb(deb_path,
+'/boot/vmlinuz-4.20.7-sunxi')
+dtb_path = '/usr/lib/linux-image-dev-sunxi/sun4i-a10-cubieboard.dtb'
+dtb_path = self.extract_from_deb(deb_path, dtb_path)
+initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
+  '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
+  'arm/rootfs-armv5.cpio.gz')
+initrd_hash = '2b50f1873e113523967806f4da2afe385462ff9b'
+initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
+initrd_path = os.path.join(self.workdir, 'rootfs.cpio')
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
+
+self.vm.set_console()
+kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+   'console=ttyS0,115200 '
+   'usbcore.nousb '
+   'panic=-1 noreboot')
+self.vm.add_args('-kernel', kernel_path,
+ '-dtb', dtb_path,
+ '-initrd', initrd_path,
+ '-append', kernel_command_line,
+ '-no-reboot')
+self.vm.launch()
+self.wait_for_console_pattern('Boot successful.')
+
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'Allwinner sun4i/sun5i')
+exec_command_and_wait_for_pattern(self, 'cat /proc/iomem',
+'system-control@1c0')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')



I ran this test case with success, so:

Tested-by: Wainer dos Santos Moschetta 

With the comment regarding the _initrd suffix:

Reviewed-by: Wainer dos Santos Moschetta 



+

Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine

2019-12-30 Thread Niek Linnenbank

On Mon, Dec 30, 2019 at 3:56 PM Philippe Mathieu-Daudé 
wrote:

> On 12/30/19 12:28 PM, Niek Linnenbank wrote:
> > Hi,
> >
> > Here a short status report of this patch series.
>
> Good idea!
>
> >
> > For V3 update I already prepared the following:
> >   - reworked all review comments from Philippe, except:
> > - patch#8: question for the SID, whether command-line override is
> > required (and how is the best way for machine-specific cli arg?) [1]
>
> Answered recently.
>
Thanks!

>
> > - added BootROM support, allows booting with only specifying -sd 
> > - added SDRAM controller driver, for U-Boot SPL
> > - added Allwinner generic RTC driver (for both Cubieboard and OrangePi
> > PC, supports sun4i, sun6i, sun7i)
> > - small fixes for EMAC
> >
> > My current TODO:
> >   - integrate Philips acceptance tests in the series
>
> You can queue them in your series, adding your Signed-off-by tag after
> mine. See:
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
>The sign-off is a simple line at the end of the explanation for the
> patch, which certifies that you wrote it or otherwise have the right to
> pass it on as an open-source patch.
>
> See point (c).
>
> Ah that certainly helps. I'll read that page.


> >   - integrate Philips work for generalizing the Allwinner timer, and
> > finish it
>
> We can also do that later, and get your work merged first.
>

Ok that sounds very good! Agreed, lets do the timer work later.


>
> >   - test and fix BSD targets (NetBSD, FreeBSD) [2, 3]
> >   - further generalize the series to cover very similar SoCs: H2+, H5
> >
> > Does anyone have more comments/requests for the V3 update?
> >
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04049.html
> > [2] https://wiki.netbsd.org/ports/evbarm/allwinner/
> > [3]
> >
> https://wiki.freebsd.org/action/show/arm/Allwinner?action=show=FreeBSD%2Farm%2FAllwinner
>
>

-- 
Niek Linnenbank

Re: [RFC PATCH 6/6] hw/arm/cubieboard: Disable unsupported M-USB in device tree blob

2019-12-30 Thread Niek Linnenbank

Hey Philippe,

I took a second look at this and, it seems my previous suggestion was only
partly valid.
The kernel error you reported came from the driver in
drivers/usb/musb/sunxi.c. Apparently, this
is an Allwinner specific driver for M-USB. And I don't see it documented in
the A10 user manual.

On the other hand, the USB host interfaces EHCI/OHCI do apply for the A10
SoC and this board.
Linux has them defined in the DTB in arch/arm/boot/dts/sun4i-a10.dtsi
(ehci0/1, ohci0/1).
But probably that is for another patch/commit.

Regards,
Niek

On Mon, Dec 30, 2019 at 2:56 PM Philippe Mathieu-Daudé 
wrote:

> On 12/30/19 12:33 PM, Niek Linnenbank wrote:
> > Hello Philippe,
> >
> > I have a suggestion: probably you can apply (almost) the same patch to
> > get USB
> > working for A10 as I did in the Allwinner H3, in patch #4 "add USB host
> > controller" [1]
> > That way you can avoid the DTB modifications and with low effort get USB
> > working as well for this board.
> > As far as I can see, in Section 21.1 in the A10 user manual [2] has the
> > same description
> > as for the H3. It basically has the standard EHCI and OHCI interfaces.
>
> Oh good news. I guess in the long term we want a AllwinnerSoc parent
> class where all common blocks are mapped, and A10/H3 children with the
> differences. But we'll worry about that after your H3 series get merged.
>
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03266.html
> > [2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf
> >
> > Regards,
> > Niek
>
>

-- 
Niek Linnenbank

[PATCH 2/2] travis.yml: Detach build and test steps

2019-12-30 Thread Wainer dos Santos Moschetta

Currently build and test commands are a single step in a
Travis's `script` block. In order to see the output
of the tests one needs to scroll down the log to find where
the build messages ended and the limit is not clear. If
they were in different steps then Travis would print the
result build command, which can be easily grep'ed.

So this change is made to detach those commands
to ease the visualization of the output.

Note that all steps on the `script` block is executed regardless
if one previous has failed. To overcome it, let's save the
return code of the build then check whether succeed or failed on
the test step.

Signed-off-by: Wainer dos Santos Moschetta 
---
 .travis.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index e7fdcb238c..fcc9de368b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -94,7 +94,8 @@ before_script:
   - mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
   - ${SRC_DIR}/configure ${BASE_CONFIG} ${CONFIG} || { cat config.log && exit 
1; }
 script:
-  - make -j3 && travis_retry ${TEST_CMD}
+  - BUILD_RC=0 && make -j3 || BUILD_RC=$?
+  - if [ "$BUILD_RC" -eq 0 ] ; then travis_retry ${TEST_CMD} ; else $(exit 
$BUILD_RC); fi
 after_script:
   - if command -v ccache ; then ccache --show-stats ; fi
 
-- 
2.23.0

[PATCH 0/2] travis: Improve log browseability

2019-12-30 Thread Wainer dos Santos Moschetta

While I was working on [1] I needed to check what dependencies
were missing on Travis environment to build a kernel. The test was
coded so that a build failure would cancel the test. As a result,
and because all tests pass'ed (or cancel'ed) I could not see
the Avocado logs (consequentely not able to check the missing
packages). That was the main reason for the Patch 01 in this
series. Also it seems pointless to print the log of the tests
that pass.

The patch 02 is a tentative to improve the browsing of build vs
test logs. Honestly I was expecting that Travis was able to
put the output of steps each on toggled text boxes (see the
'before_script' section, each command output has a
toggle). But that isn't the behavior of the 'script'
section. At least it prints the end of the build command
('The command "BUILD_RC=0 && make -j3 || BUILD_RC=$?" exited with 0.')
which can be grep'ed.

Git:
- Tree: https://github.com/wainersm/qemu
- Brach: travis_improved_browse

CI:
- Travis (FAIL): https://travis-ci.org/wainersm/qemu/builds/630948777
  QEMU keep failing with --without-default-devices

References:
[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg663432.html

Wainer dos Santos Moschetta (2):
  travis.yml: avocado: Print logs of non-pass tests only
  travis.yml: Detach build and test steps

 .travis.yml | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

-- 
2.23.0

[PATCH 1/2] travis.yml: avocado: Print logs of non-pass tests only

2019-12-30 Thread Wainer dos Santos Moschetta

The acceptance tests build on Travis is configured to print
the entire Avocado's job log in case any test fail. Usually one is
interested on failed tests only though. So this change the Travis
configuration in order to show the log of tests which status is
different from 'PASS' and 'SKIP' only. Note that 'CANCEL'-ed tests
will have the log printed too because it can help to debug some
condition on CI environment which is not being fulfilled.

Signed-off-by: Wainer dos Santos Moschetta 
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 376b7d6dfa..e7fdcb238c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -262,8 +262,8 @@ matrix:
 - env:
 - CONFIG="--python=/usr/bin/python3 
--target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,ppc-softmmu,ppc64-softmmu,m68k-softmmu,sparc-softmmu"
 - TEST_CMD="make check-acceptance"
-  after_failure:
-- cat tests/results/latest/job.log
+  after_script:
+- python3 -c 'import json; r = 
json.load(open("tests/results/latest/results.json")); [print(t["logfile"]) for 
t in r["tests"] if t["status"] not in ("PASS", "SKIP")]' | xargs cat
   addons:
 apt:
   packages:
-- 
2.23.0

Re: [PATCH v3 0/8] hw/avr: Introduce the Arduino boards

2019-12-30 Thread Michael Rolnik

Hi Philippe.

Thank you for joining the effort.

Regards,
Michael Rolnik


On Mon, Dec 30, 2019 at 12:45 AM Philippe Mathieu-Daudé 
wrote:

> Hi,
>
> This series add the arduino boards, aiming at removing the
> 'sample' board that doesn't follow any specification.
>
> Since v2:
> - rebased on Michael's v40
>
> Since v1:
> - Addressed Igor comments
> - Addressed Aleksandar comments
> - Fixed UART issue (was due to IRQ shifted by 2 in CPU)
>
> TODO after merge is:
> - Extract Timer8 common parts from Timer16
> - Add GPIOs
> - Connect LED to GPIO on Arduino
> - Plug to Scratch (See http://s4a.cat/).
>   (I plan to purpose that as a GSoC idea).
>
> Michael, thank you for having insisted with this port during so long!
>
> Regards,
>
> Phil.
>
> Series available at https://gitlab.com/philmd/qemu/commits/arduino-v3
>
> Regards,
>
> Phil.
>
> Based-on: <20191229215158.5788-1-mrol...@gmail.com>
> https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg05309.html
>
> Philippe Mathieu-Daudé (8):
>   hw/char/avr: Reduce USART I/O size
>   hw/timer/avr_timer16: Rename memory region debugging name
>   hw/avr: Add some ATmega microcontrollers
>   hw/avr: Add some Arduino boards
>   tests/boot-serial-test: Test some Arduino boards (AVR based)
>   tests/acceptance: Do not set the machine type manually
>   tests/acceptance: Keep multilines comment consistent with other tests
>   tests/acceptance: Test the Arduino MEGA2560 board
>
>  hw/avr/atmega.h  |  48 
>  hw/avr/arduino.c | 177 
>  hw/avr/atmega.c  | 464 +++
>  hw/char/avr_usart.c  |   2 +-
>  hw/timer/avr_timer16.c   |   6 +-
>  tests/boot-serial-test.c |   2 +
>  hw/avr/Makefile.objs |   2 +
>  tests/acceptance/machine_avr6.py |  11 +-
>  8 files changed, 701 insertions(+), 11 deletions(-)
>  create mode 100644 hw/avr/atmega.h
>  create mode 100644 hw/avr/arduino.c
>  create mode 100644 hw/avr/atmega.c
>
> --
> 2.21.0
>
>

-- 
Best Regards,
Michael Rolnik

Re: [PATCH v40 20/21] target/avr: Add Avocado test

2019-12-30 Thread Michael Rolnik

Hi Wainer.

thanks for reviewing.

1. when `self.vm.shutdown()` is not called `self.vm.get_log()` returns
`ERROR: argument of type 'NoneType' is not iterable`
2. I will remove the unnecessary imports

Thanks,
Michael Rolnik


On Mon, Dec 30, 2019 at 7:37 PM Wainer dos Santos Moschetta <
waine...@redhat.com> wrote:

> Hi Michael,
>
> On 12/29/19 7:51 PM, Michael Rolnik wrote:
> > The test is based on
> > https://github.com/seharris/qemu-avr-tests/tree/master/free-rtos/Demo
> > demo which. If working correctly, prints 'ABCDEFGHIJKLMNOPQRSTUVWX' out.
> > it also demostrates that timer and IRQ are working
> >
> > Signed-off-by: Michael Rolnik 
> > Reviewed-by: Philippe Mathieu-Daudé 
> > Tested-by: Philippe Mathieu-Daudé 
> > Acked-by: Thomas Huth 
> > ---
> >   tests/acceptance/machine_avr6.py | 58 
> >   1 file changed, 58 insertions(+)
> >   create mode 100644 tests/acceptance/machine_avr6.py
> >
> > diff --git a/tests/acceptance/machine_avr6.py
> b/tests/acceptance/machine_avr6.py
> > new file mode 100644
> > index 00..7a7d8afc29
> > --- /dev/null
> > +++ b/tests/acceptance/machine_avr6.py
> > @@ -0,0 +1,58 @@
> > +#
> > +# QEMU AVR
> > +#
> > +# Copyright (c) 2019 Michael Rolnik 
> > +#
> > +# This program is free software: you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License as published by
> > +# the Free Software Foundation, either version 2 of the License, or
> > +# (at your option) any later version.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License
> > +# along with this program.  If not, see .
> > +#
> > +
> > +import logging
> > +import time
> > +import distutils.spawn
> > +
> > +from avocado import skipUnless
> > +from avocado_qemu import Test
> > +from avocado.utils import process
>
> Please remove unused imports: logging, distutils.spawn, skipUnless and
> process.
>
> > +
> > +class AVR6Machine(Test):
>
> It helps others reading this if you document the test purpose here.
> Besides it makes the pylinter happier. ;)
>
> > +timeout = 5
> > +
> > +def test_freertos(self):
> > +"""
> > +:avocado: tags=arch:avr
> > +:avocado: tags=machine:sample
> > +"""
> > +"""
> > +
> https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
> > +constantly prints out
> 'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
> > +"""
> > +rom_url = 'https://github.com/seharris/qemu-avr-tests'
> > +rom_sha1= '36c3e67b8755dcf37e06af6730ef5d477b8ed16d'
> > +rom_url += '/raw/'
> > +rom_url += rom_sha1
> > +rom_url += '/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf'
> > +rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
> > +rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
> > +
> > +self.vm.set_machine('sample')
> > +self.vm.add_args('-bios', rom_path)
> > +self.vm.add_args('-nographic')
> > +self.vm.launch()
> > +
> > +time.sleep(2)
> > +self.vm.shutdown()
>
> Do you really need to shutdown the VM here? Because it will be shut down
> later on avocado_qemu.Test.tearDown() anyway.
>
> > +
> > +match = 'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
> > +
> > +self.assertIn(match, self.vm.get_log())
>
> It is a matter of taste, but I would simply do:
>
> self.assertIn('ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX',
>
>   self.vm.get_log())
>
> Thanks for writing this acceptance test!
>
> - Wainer
>
>

-- 
Best Regards,
Michael Rolnik

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Paolo Bonzini

Yes, of course (I thought it would be clear from the message, but perhaps
it was a bit implicit).

Paolo

Il lun 30 dic 2019, 16:48 Philippe Mathieu-Daudé  ha
scritto:

> On Mon, Dec 30, 2019 at 3:02 PM Philippe Mathieu-Daudé
>  wrote:
> > On 12/30/19 11:33 AM, Paolo Bonzini wrote:
> > > Il lun 30 dic 2019, 09:59 Philippe Mathieu-Daudé  > > > ha scritto:
> > >
> > >  > I'd prefer not changing those files.
> > >
> > > OK, I'll wait to see what Richard/Markus prefer.
> > >
> > >
> > > I think it's best if you keep the include directives as-is for files
> > > only needed from tcg/, and move the other headers (those that are
> needed
> > > from other directories only) to include/tcg.
>
> Assuming we don't want to add include/tcg/ in the path search list, we
> still need to update the tcg/*.c include directives to use "tcg/":
>
> tcg/tcg-op-gvec.c:21:10: fatal error: tcg.h: No such file or directory
>21 | #include "tcg.h"
>   |  ^~~
> compilation terminated.
> make[1]: *** [rules.mak:69: tcg/tcg-op-gvec.o] Error 1
> make[1]: *** Waiting for unfinished jobs
>   CC  mips64el-softmmu/accel/tcg/translate-all.o
> tcg/optimize.c:27:10: fatal error: tcg-op.h: No such file or directory
>27 | #include "tcg-op.h"
>   |  ^~
> compilation terminated.
> make[1]: *** [rules.mak:69: tcg/optimize.o] Error 1
> tcg/tcg-op-vec.c:22:10: fatal error: tcg.h: No such file or directory
>22 | #include "tcg.h"
>   |  ^~~
> compilation terminated.
> make[1]: *** [rules.mak:69: tcg/tcg-op-vec.o] Error 1
> tcg/tcg-common.c:35:10: fatal error: tcg-opc.h: No such file or directory
>35 | #include "tcg-opc.h"
>   |  ^~~
> compilation terminated.
> make[1]: *** [rules.mak:69: tcg/tcg-common.o] Error 1
> tcg/tcg-op.c:28:10: fatal error: tcg.h: No such file or directory
>28 | #include "tcg.h"
>   |  ^~~
> compilation terminated.
> make[1]: *** [rules.mak:69: tcg/tcg-op.o] Error 1
> tcg/tcg.c:51:10: fatal error: tcg-op.h: No such file or directory
>51 | #include "tcg-op.h"
>   |  ^~
> compilation terminated.
>
> > I thought moving headers to include/tcg would diverge too much from
> > libtcg, but this project already did it, so why not:
> > https://github.com/S2E/libtcg/tree/master/include/tcg
>
>

Re: [PATCH v40 20/21] target/avr: Add Avocado test

2019-12-30 Thread Wainer dos Santos Moschetta


Hi Michael,

On 12/29/19 7:51 PM, Michael Rolnik wrote:

The test is based on
https://github.com/seharris/qemu-avr-tests/tree/master/free-rtos/Demo
demo which. If working correctly, prints 'ABCDEFGHIJKLMNOPQRSTUVWX' out.
it also demostrates that timer and IRQ are working

Signed-off-by: Michael Rolnik 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Acked-by: Thomas Huth 
---
  tests/acceptance/machine_avr6.py | 58 
  1 file changed, 58 insertions(+)
  create mode 100644 tests/acceptance/machine_avr6.py

diff --git a/tests/acceptance/machine_avr6.py b/tests/acceptance/machine_avr6.py
new file mode 100644
index 00..7a7d8afc29
--- /dev/null
+++ b/tests/acceptance/machine_avr6.py
@@ -0,0 +1,58 @@
+#
+# QEMU AVR
+#
+# Copyright (c) 2019 Michael Rolnik 
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import logging
+import time
+import distutils.spawn
+
+from avocado import skipUnless
+from avocado_qemu import Test
+from avocado.utils import process


Please remove unused imports: logging, distutils.spawn, skipUnless and 
process.



+
+class AVR6Machine(Test):


It helps others reading this if you document the test purpose here. 
Besides it makes the pylinter happier. ;)



+timeout = 5
+
+def test_freertos(self):
+"""
+:avocado: tags=arch:avr
+:avocado: tags=machine:sample
+"""
+"""
+
https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
+constantly prints out 
'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
+"""
+rom_url = 'https://github.com/seharris/qemu-avr-tests'
+rom_sha1= '36c3e67b8755dcf37e06af6730ef5d477b8ed16d'
+rom_url += '/raw/'
+rom_url += rom_sha1
+rom_url += '/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf'
+rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
+rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
+
+self.vm.set_machine('sample')
+self.vm.add_args('-bios', rom_path)
+self.vm.add_args('-nographic')
+self.vm.launch()
+
+time.sleep(2)
+self.vm.shutdown()


Do you really need to shutdown the VM here? Because it will be shut down 
later on avocado_qemu.Test.tearDown() anyway.



+
+match = 'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
+
+self.assertIn(match, self.vm.get_log())


It is a matter of taste, but I would simply do:

self.assertIn('ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX',

 self.vm.get_log())

Thanks for writing this acceptance test!

- Wainer

Re: [PATCH] MAINTAINERS: Remove Claudio Fontana bouncing email

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 12:18 PM, Philippe Mathieu-Daudé wrote:

Claudio Fontana Huawei email is bouncing, remove it.

   The message you sent to claudio.font...@huawei.com couldn't be
   delivered due to: Recipient email address is possibly incorrect.

   Further information:
 5.1.1 Error: invalid recipients

Signed-off-by: Philippe Mathieu-Daudé 
---
  MAINTAINERS | 1 -
  1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 387879aebc..8db4de6b9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2383,7 +2383,6 @@ F: plugins/
  F: tests/plugin
  
  AArch64 TCG target

-M: Claudio Fontana 
  M: Claudio Fontana 
  S: Maintained
  L: qemu-...@nongnu.org



Claudio, if you want we can amend to this patch:

-- >8 --
diff --git a/.mailmap b/.mailmap
index 3816e4effe..4ed87fb53f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -43,6 +43,7 @@ Aleksandar Markovic  

 Aleksandar Markovic  


 Aleksandar Rikalo  
 Anthony Liguori  Anthony Liguori 


+Claudio Fontana  
 James Hogan  
 Paul Burton  
 Paul Burton  
---

Simply reply with your Ack-by such "with .mailmap change:"...

Re: [PATCH] MAINTAINERS: Remove Claudio Fontana bouncing email

2019-12-30 Thread Alex Bennée

Reviewed-by: Alex Bennée 

On Mon, 30 Dec 2019, 11:19 Philippe Mathieu-Daudé, 
wrote:

> Claudio Fontana Huawei email is bouncing, remove it.
>
>   The message you sent to claudio.font...@huawei.com couldn't be
>   delivered due to: Recipient email address is possibly incorrect.
>
>   Further information:
> 5.1.1 Error: invalid recipients
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 387879aebc..8db4de6b9a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2383,7 +2383,6 @@ F: plugins/
>  F: tests/plugin
>
>  AArch64 TCG target
> -M: Claudio Fontana 
>  M: Claudio Fontana 
>  S: Maintained
>  L: qemu-...@nongnu.org
> --
> 2.21.0
>
>
>

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Philippe Mathieu-Daudé

On Mon, Dec 30, 2019 at 3:02 PM Philippe Mathieu-Daudé
 wrote:
> On 12/30/19 11:33 AM, Paolo Bonzini wrote:
> > Il lun 30 dic 2019, 09:59 Philippe Mathieu-Daudé  > > ha scritto:
> >
> >  > I'd prefer not changing those files.
> >
> > OK, I'll wait to see what Richard/Markus prefer.
> >
> >
> > I think it's best if you keep the include directives as-is for files
> > only needed from tcg/, and move the other headers (those that are needed
> > from other directories only) to include/tcg.

Assuming we don't want to add include/tcg/ in the path search list, we
still need to update the tcg/*.c include directives to use "tcg/":

tcg/tcg-op-gvec.c:21:10: fatal error: tcg.h: No such file or directory
   21 | #include "tcg.h"
  |  ^~~
compilation terminated.
make[1]: *** [rules.mak:69: tcg/tcg-op-gvec.o] Error 1
make[1]: *** Waiting for unfinished jobs
  CC  mips64el-softmmu/accel/tcg/translate-all.o
tcg/optimize.c:27:10: fatal error: tcg-op.h: No such file or directory
   27 | #include "tcg-op.h"
  |  ^~
compilation terminated.
make[1]: *** [rules.mak:69: tcg/optimize.o] Error 1
tcg/tcg-op-vec.c:22:10: fatal error: tcg.h: No such file or directory
   22 | #include "tcg.h"
  |  ^~~
compilation terminated.
make[1]: *** [rules.mak:69: tcg/tcg-op-vec.o] Error 1
tcg/tcg-common.c:35:10: fatal error: tcg-opc.h: No such file or directory
   35 | #include "tcg-opc.h"
  |  ^~~
compilation terminated.
make[1]: *** [rules.mak:69: tcg/tcg-common.o] Error 1
tcg/tcg-op.c:28:10: fatal error: tcg.h: No such file or directory
   28 | #include "tcg.h"
  |  ^~~
compilation terminated.
make[1]: *** [rules.mak:69: tcg/tcg-op.o] Error 1
tcg/tcg.c:51:10: fatal error: tcg-op.h: No such file or directory
   51 | #include "tcg-op.h"
  |  ^~
compilation terminated.

> I thought moving headers to include/tcg would diverge too much from
> libtcg, but this project already did it, so why not:
> https://github.com/S2E/libtcg/tree/master/include/tcg

Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 12:28 PM, Niek Linnenbank wrote:

Hi,

Here a short status report of this patch series.


Good idea!



For V3 update I already prepared the following:
  - reworked all review comments from Philippe, except:
    - patch#8: question for the SID, whether command-line override is 
required (and how is the best way for machine-specific cli arg?) [1]


Answered recently.


- added BootROM support, allows booting with only specifying -sd 
- added SDRAM controller driver, for U-Boot SPL
- added Allwinner generic RTC driver (for both Cubieboard and OrangePi 
PC, supports sun4i, sun6i, sun7i)

- small fixes for EMAC

My current TODO:
  - integrate Philips acceptance tests in the series


You can queue them in your series, adding your Signed-off-by tag after 
mine. See:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

  The sign-off is a simple line at the end of the explanation for the 
patch, which certifies that you wrote it or otherwise have the right to 
pass it on as an open-source patch.


See point (c).

  - integrate Philips work for generalizing the Allwinner timer, and 
finish it


We can also do that later, and get your work merged first.


  - test and fix BSD targets (NetBSD, FreeBSD) [2, 3]
  - further generalize the series to cover very similar SoCs: H2+, H5

Does anyone have more comments/requests for the V3 update?

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04049.html
[2] https://wiki.netbsd.org/ports/evbarm/allwinner/
[3] 
https://wiki.freebsd.org/action/show/arm/Allwinner?action=show=FreeBSD%2Farm%2FAllwinner

Re: [PATCH v2 08/10] arm: allwinner-h3: add Security Identifier device

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/18/19 9:49 PM, Niek Linnenbank wrote:

Hi Philippe,

On Tue, Dec 17, 2019 at 8:45 AM Philippe Mathieu-Daudé 
mailto:phi...@redhat.com>> wrote:


Hi Niek,

On 12/17/19 12:35 AM, Niek Linnenbank wrote:
 > The Security Identifier device in Allwinner H3 System on Chip
 > gives applications a per-board unique identifier. This commit
 > adds support for the Allwinner H3 Security Identifier using
 > a 128-bit UUID value as input.
 >
 > Signed-off-by: Niek Linnenbank mailto:nieklinnenb...@gmail.com>>
 > ---
 >   include/hw/arm/allwinner-h3.h      |   2 +
 >   include/hw/misc/allwinner-h3-sid.h |  40 +++
 >   hw/arm/allwinner-h3.c              |   7 ++
 >   hw/arm/orangepi.c                  |   4 +
 >   hw/misc/allwinner-h3-sid.c         | 179
+
 >   hw/misc/Makefile.objs              |   1 +
 >   hw/misc/trace-events               |   4 +
 >   7 files changed, 237 insertions(+)
 >   create mode 100644 include/hw/misc/allwinner-h3-sid.h
 >   create mode 100644 hw/misc/allwinner-h3-sid.c
 >
 > diff --git a/include/hw/arm/allwinner-h3.h
b/include/hw/arm/allwinner-h3.h
 > index 8128ae6131..c98c1972a6 100644
 > --- a/include/hw/arm/allwinner-h3.h
 > +++ b/include/hw/arm/allwinner-h3.h
 > @@ -29,6 +29,7 @@
 >   #include "hw/misc/allwinner-h3-clk.h"
 >   #include "hw/misc/allwinner-h3-cpucfg.h"
 >   #include "hw/misc/allwinner-h3-syscon.h"
 > +#include "hw/misc/allwinner-h3-sid.h"
 >   #include "target/arm/cpu.h"
 >
 >   enum {
 > @@ -77,6 +78,7 @@ typedef struct AwH3State {
 >       AwH3ClockState ccu;
 >       AwH3CpuCfgState cpucfg;
 >       AwH3SysconState syscon;
 > +    AwH3SidState sid;
 >       GICState gic;
 >       MemoryRegion sram_a1;
 >       MemoryRegion sram_a2;
 > diff --git a/include/hw/misc/allwinner-h3-sid.h
b/include/hw/misc/allwinner-h3-sid.h
 > new file mode 100644
 > index 00..79c9a24459
 > --- /dev/null
 > +++ b/include/hw/misc/allwinner-h3-sid.h
 > @@ -0,0 +1,40 @@
 > +/*
 > + * Allwinner H3 Security ID emulation
 > + *
 > + * Copyright (C) 2019 Niek Linnenbank mailto:nieklinnenb...@gmail.com>>
 > + *
 > + * This program is free software: you can redistribute it and/or
modify
 > + * it under the terms of the GNU General Public License as
published by
 > + * the Free Software Foundation, either version 2 of the License, or
 > + * (at your option) any later version.
 > + *
 > + * This program is distributed in the hope that it will be useful,
 > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 > + * GNU General Public License for more details.
 > + *
 > + * You should have received a copy of the GNU General Public License
 > + * along with this program.  If not, see
.
 > + */
 > +
 > +#ifndef HW_MISC_ALLWINNER_H3_SID_H
 > +#define HW_MISC_ALLWINNER_H3_SID_H
 > +
 > +#include "hw/sysbus.h"
 > +#include "qemu/uuid.h"
 > +
 > +#define TYPE_AW_H3_SID    "allwinner-h3-sid"
 > +#define AW_H3_SID(obj)    OBJECT_CHECK(AwH3SidState, (obj),
TYPE_AW_H3_SID)
 > +
 > +typedef struct AwH3SidState {
 > +    /*< private >*/
 > +    SysBusDevice parent_obj;
 > +    /*< public >*/
 > +
 > +    MemoryRegion iomem;
 > +    uint32_t control;
 > +    uint32_t rdkey;
 > +    QemuUUID identifier;
 > +} AwH3SidState;
 > +
 > +#endif
 > diff --git a/hw/arm/allwinner-h3.c b/hw/arm/allwinner-h3.c
 > index 1a9748ab2e..ba34f905cd 100644
 > --- a/hw/arm/allwinner-h3.c
 > +++ b/hw/arm/allwinner-h3.c
 > @@ -196,6 +196,9 @@ static void aw_h3_init(Object *obj)
 >
 >       sysbus_init_child_obj(obj, "cpucfg", >cpucfg,
sizeof(s->cpucfg),
 >                             TYPE_AW_H3_CPUCFG);
 > +
 > +    sysbus_init_child_obj(obj, "sid", >sid, sizeof(s->sid),
 > +                          TYPE_AW_H3_SID);

Here add a property alias:

         object_property_add_alias(obj, "identifier", OBJECT(>sid),
                                   "identifier", _abort);

 >   }
 >
 >   static void aw_h3_realize(DeviceState *dev, Error **errp)
 > @@ -332,6 +335,10 @@ static void aw_h3_realize(DeviceState *dev,
Error **errp)
 >       qdev_init_nofail(DEVICE(>cpucfg));
 >       sysbus_mmio_map(SYS_BUS_DEVICE(>cpucfg), 0,
s->memmap[AW_H3_CPUCFG]);
 >
 > +    /* Security Identifier */
 > +    qdev_init_nofail(DEVICE(>sid));
 > +    sysbus_mmio_map(SYS_BUS_DEVICE(>sid), 0,
s->memmap[AW_H3_SID]);
 > +
 >       /* Universal Serial Bus */
 >       sysbus_create_simple(TYPE_AW_H3_EHCI, s->memmap[AW_H3_EHCI0],

Re: [PATCH v3 6/8] tests/acceptance: Do not set the machine type manually

2019-12-30 Thread Wainer dos Santos Moschetta




On 12/29/19 8:45 PM, Philippe Mathieu-Daudé wrote:

Since commit ba21bde93 we don't need to set the machine type
manually, the one set by the ":avocado: tags=machine" will be used.


Correct.



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



Reviewed-by: Wainer dos Santos Moschetta 




diff --git a/tests/acceptance/machine_avr6.py b/tests/acceptance/machine_avr6.py
index 7a7d8afc29..394b3d4f8f 100644
--- a/tests/acceptance/machine_avr6.py
+++ b/tests/acceptance/machine_avr6.py
@@ -45,7 +45,6 @@ class AVR6Machine(Test):
  rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
  rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
  
-self.vm.set_machine('sample')

  self.vm.add_args('-bios', rom_path)
  self.vm.add_args('-nographic')
  self.vm.launch()

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 11:33 AM, Paolo Bonzini wrote:



Il lun 30 dic 2019, 09:59 Philippe Mathieu-Daudé > ha scritto:


 > I'd prefer not changing those files.

OK, I'll wait to see what Richard/Markus prefer.


I think it's best if you keep the include directives as-is for files 
only needed from tcg/, and move the other headers (those that are needed 
from other directories only) to include/tcg.


I thought moving headers to include/tcg would diverge too much from 
libtcg, but this project already did it, so why not:

https://github.com/S2E/libtcg/tree/master/include/tcg

Re: [RFC PATCH 6/6] hw/arm/cubieboard: Disable unsupported M-USB in device tree blob

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 12:33 PM, Niek Linnenbank wrote:

Hello Philippe,

I have a suggestion: probably you can apply (almost) the same patch to 
get USB
working for A10 as I did in the Allwinner H3, in patch #4 "add USB host 
controller" [1]
That way you can avoid the DTB modifications and with low effort get USB 
working as well for this board.
As far as I can see, in Section 21.1 in the A10 user manual [2] has the 
same description

as for the H3. It basically has the standard EHCI and OHCI interfaces.


Oh good news. I guess in the long term we want a AllwinnerSoc parent 
class where all common blocks are mapped, and A10/H3 children with the 
differences. But we'll worry about that after your H3 series get merged.



[1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03266.html
[2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf

Regards,
Niek

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 2:17 PM, Michal Prívozník wrote:

On 12/30/19 10:45 AM, Philippe Mathieu-Daudé wrote:

On 12/30/19 10:35 AM, Michal Prívozník wrote:

On 12/30/19 9:41 AM, Philippe Mathieu-Daudé wrote:

On 12/30/19 9:00 AM, Michal Privoznik wrote:

In v4.2.0-246-ged9e923c3c the SMM property was moved from PC


Typo v4.2.0-246-ged9e923c3c -> ed9e923c3c.


This depends on how you format the hash :-)
I've used 'git describe ed9e923c3c' because I find it more readable for
us humans (at least we see what version the commit was introduced in).
But I don't know what the praxis is in qemu.


Hmm I never used it. Your explanation makes sense, but the tag confused
me because I don't have it locally. However git (and gitk) seems clever
enough to only use the useful part:


The v4.2.0 tag is in origin. I wonder how come you do not have it.



$ git show randomcrap-ged9e923c3c
commit ed9e923c3c9a2c50c4e82ba178b3fb1feba56867
Author: Paolo Bonzini 
Date:   Thu Dec 12 17:28:01 2019 +0100

     x86: move SMM property to X86MachineState

FYI My output is different:

$ git describe ed9e923c3c
pull-target-arm-20191216-1-199-ged9e923c3c


You may want to use 'git describe --tags --match "v*" $commit'


Oh yes I have it :>

$ git describe --tags --match "v*" ed9e923c3c
v4.2.0-246-ged9e923c3c

The difference seems to be I have other tags between v4.2.0 and 
ed9e923c3c, and git-describe choose the closest (newer?).




But again, feel free to change it to whatever you/committer wants.


This is fine, no problem, today I learned something new :)

Re: [PULL 4/8] vfio/pci: Respond to KVM irqchip change notifier

2019-12-30 Thread Eduardo Habkost

On Tue, Nov 26, 2019 at 05:01:47PM +1100, David Gibson wrote:
> VFIO PCI devices already respond to the pci intx routing notifier, in order
> to update kernel irqchip mappings when routing is updated.  However this
> won't handle the case where the irqchip itself is replaced by a different
> model while retaining the same routing.  This case can happen on
> the pseries machine type due to PAPR feature negotiation.
> 
> To handle that case, add a handler for the irqchip change notifier, which
> does much the same thing as the routing notifier, but is unconditional,
> rather than being a no-op when the routing hasn't changed.
> 
> Cc: Alex Williamson 
> Cc: Alexey Kardashevskiy 
> 
> Signed-off-by: David Gibson 
> Tested-by: Alex Williamson 
> Reviewed-by: Alex Williamson 
> Reviewed-by: Greg Kurz 
> Acked-by: Alex Williamson 
> ---
[...]
> @@ -2973,30 +2981,32 @@ static void vfio_realize(PCIDevice *pdev, Error 
> **errp)
>vfio_intx_mmap_enable, 
> vdev);
>  pci_device_set_intx_routing_notifier(>pdev,
>   vfio_intx_routing_notifier);
> +vdev->irqchip_change_notifier.notify = vfio_irqchip_change;
> +kvm_irqchip_add_change_notifier(>irqchip_change_notifier);

This code is conditional on
(vfio_pci_read_config(>pdev, PCI_INTERRUPT_PIN, 1)).

However:

[...]
> -out_teardown:
> +out_deregister:
>  pci_device_set_intx_routing_notifier(>pdev, NULL);
> +kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);
> +out_teardown:
>  vfio_teardown_msi(vdev);
>  vfio_bars_exit(vdev);
>  error:
> @@ -3064,6 +3076,7 @@ static void vfio_exitfn(PCIDevice *pdev)
>  vfio_unregister_req_notifier(vdev);
>  vfio_unregister_err_notifier(vdev);
>  pci_device_set_intx_routing_notifier(>pdev, NULL);
> +kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);

This is unconditional.  This doesn't look safe, and might be the
cause of the crash reported at
https://bugzilla.redhat.com/show_bug.cgi?id=1782678

-- 
Eduardo

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Michal Prívozník

On 12/30/19 10:45 AM, Philippe Mathieu-Daudé wrote:
> On 12/30/19 10:35 AM, Michal Prívozník wrote:
>> On 12/30/19 9:41 AM, Philippe Mathieu-Daudé wrote:
>>> On 12/30/19 9:00 AM, Michal Privoznik wrote:
 In v4.2.0-246-ged9e923c3c the SMM property was moved from PC
>>>
>>> Typo v4.2.0-246-ged9e923c3c -> ed9e923c3c.
>>
>> This depends on how you format the hash :-)
>> I've used 'git describe ed9e923c3c' because I find it more readable for
>> us humans (at least we see what version the commit was introduced in).
>> But I don't know what the praxis is in qemu.
> 
> Hmm I never used it. Your explanation makes sense, but the tag confused
> me because I don't have it locally. However git (and gitk) seems clever
> enough to only use the useful part:

The v4.2.0 tag is in origin. I wonder how come you do not have it.

> 
> $ git show randomcrap-ged9e923c3c
> commit ed9e923c3c9a2c50c4e82ba178b3fb1feba56867
> Author: Paolo Bonzini 
> Date:   Thu Dec 12 17:28:01 2019 +0100
> 
>     x86: move SMM property to X86MachineState
> 
> FYI My output is different:
> 
> $ git describe ed9e923c3c
> pull-target-arm-20191216-1-199-ged9e923c3c

You may want to use 'git describe --tags --match "v*" $commit'

But again, feel free to change it to whatever you/committer wants.

Michal

Re: [PATCH v2] accel/kvm: Make "kernel_irqchip" default on

2019-12-30 Thread Michal Prívozník

On 12/28/19 11:43 AM, Xiaoyao Li wrote:
> Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an
> accelerator property") moves kernel_irqchip property from "-machine" to
> "-accel kvm", but it forgets to set the default value of
> kernel_irqchip_allowed and kernel_irqchip_split.
> 
> Also cleaning up the three useless members (kernel_irqchip_allowed,
> kernel_irqchip_required, kernel_irqchip_split) in struct MachineState.
> 
> Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an 
> accelerator property")
> Reported-by: Vitaly Kuznetsov 
> Signed-off-by: Xiaoyao Li 
> ---
> Changes in v2:
>   - Add Reported-by tag;
>   - Initialize kernel_irqchip_split in init_machine();
> ---
>  accel/kvm/kvm-all.c | 3 +++
>  include/hw/boards.h | 3 ---
>  2 files changed, 3 insertions(+), 3 deletions(-)

Huh, I've just converged to the same patch.

Tested-by: Michal Prívozník 

Michal

Re: [RFC PATCH 6/6] hw/arm/cubieboard: Disable unsupported M-USB in device tree blob

2019-12-30 Thread Niek Linnenbank

Hello Philippe,

I have a suggestion: probably you can apply (almost) the same patch to get
USB
working for A10 as I did in the Allwinner H3, in patch #4 "add USB host
controller" [1]
That way you can avoid the DTB modifications and with low effort get USB
working as well for this board.
As far as I can see, in Section 21.1 in the A10 user manual [2] has the
same description
as for the H3. It basically has the standard EHCI and OHCI interfaces.

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03266.html
[2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf

Regards,
Niek

On Mon, Dec 30, 2019 at 12:10 PM Philippe Mathieu-Daudé 
wrote:

> We do not model the Sunxi Multipoint USB.
> The Linux kernel OOPS when booting:
>
>   [ cut here ]
>   WARNING: CPU: 0 PID: 144 at drivers/usb/musb/sunxi.c:400
> sunxi_musb_ep_offset+0x39/0x3c
>   sunxi_musb_ep_offset called with non 0 offset
>   Modules linked in:
>   CPU: 0 PID: 144 Comm: kworker/0:2 Not tainted 4.20.7-sunxi #5.75
>   Hardware name: Allwinner sun4i/sun5i Families
>   Workqueue: events deferred_probe_work_func
>   [] (unwind_backtrace) from [] (show_stack+0x11/0x14)
>   [] (show_stack) from [] (dump_stack+0x69/0x78)
>   [] (dump_stack) from [] (__warn+0xa1/0xb4)
>   [] (__warn) from [] (warn_slowpath_fmt+0x33/0x48)
>   [] (warn_slowpath_fmt) from []
> (sunxi_musb_ep_offset+0x39/0x3c)
>   [] (sunxi_musb_ep_offset) from []
> (ep_config_from_hw+0x99/0x104)
>   [] (ep_config_from_hw) from []
> (musb_probe+0x765/0xa0c)
>   [] (musb_probe) from []
> (platform_drv_probe+0x33/0x68)
>   [] (platform_drv_probe) from []
> (really_probe+0x16f/0x1e0)
>   [] (really_probe) from []
> (driver_probe_device+0x43/0x11c)
>   [] (driver_probe_device) from []
> (bus_for_each_drv+0x37/0x70)
>   [] (bus_for_each_drv) from []
> (__device_attach+0x83/0xc8)
>   [] (__device_attach) from []
> (bus_probe_device+0x5b/0x60)
>   [] (bus_probe_device) from []
> (device_add+0x2f5/0x474)
>   [] (device_add) from []
> (platform_device_add+0xb7/0x184)
>   [] (platform_device_add) from []
> (platform_device_register_full+0xb3/0xc4)
>   [] (platform_device_register_full) from []
> (sunxi_musb_probe+0x1d7/0x2f4)
>   [] (sunxi_musb_probe) from []
> (platform_drv_probe+0x33/0x68)
>   [] (platform_drv_probe) from []
> (really_probe+0x16f/0x1e0)
>   [] (really_probe) from []
> (driver_probe_device+0x43/0x11c)
>   [] (driver_probe_device) from []
> (bus_for_each_drv+0x37/0x70)
>   [] (bus_for_each_drv) from []
> (__device_attach+0x83/0xc8)
>   [] (__device_attach) from []
> (bus_probe_device+0x5b/0x60)
>   [] (bus_probe_device) from []
> (deferred_probe_work_func+0x4b/0x6c)
>   [] (deferred_probe_work_func) from []
> (process_one_work+0x167/0x384)
>   [] (process_one_work) from []
> (worker_thread+0x251/0x3fc)
>   [] (worker_thread) from [] (kthread+0xfd/0x104)
>   [] (kthread) from [] (ret_from_fork+0x11/0x38)
>   Exception stack(0xc6999fb0 to 0xc6999ff8)
>   9fa0:   
> 
>   9fc0:       
> 
>   9fe0:     0013 
>   ---[ end trace b309edbca98c7de2 ]---
>   musb-sunxi 1c13000.usb: Error unknown readb offset 128
>   musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -22
>   musb-hdrc: probe of musb-hdrc.1.auto failed with error -22
>
> This is not critical but confusing. To avoid the Linux kernel to
> probe this device, mark it disabled in the device tree blob.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> I'm not sure if this is a QEMU anti-pattern or bad practice.
> I know we prefer to be as close to the hardware as possible,
> but here the hardware is not changed, the dtb is. However
> this makes the guest behave differently. At least we don't
> have to manually edit the dts. If this is only annoying for
> acceptance testing, we might consider manually editing the
> dts in the tests setup().
> ---
>  hw/arm/cubieboard.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
> index 6dc2f1d6b6..dd10577696 100644
> --- a/hw/arm/cubieboard.c
> +++ b/hw/arm/cubieboard.c
> @@ -22,10 +22,34 @@
>  #include "hw/sysbus.h"
>  #include "hw/boards.h"
>  #include "hw/arm/allwinner-a10.h"
> +#include 
> +
> +static void cubieboard_modify_dtb(const struct arm_boot_info *info, void
> *fdt)
> +{
> +static const char unsupported_compat[] = "allwinner,sun4i-a10-musb";
> +char node_path[72];
> +int offset;
> +
> +offset = fdt_node_offset_by_compatible(fdt, -1, unsupported_compat);
> +while (offset >= 0) {
> +int r = fdt_get_path(fdt, offset, node_path, sizeof(node_path));
> +assert(r >= 0);
> +r = fdt_setprop_string(fdt, offset, "status", "disabled");
> +if (r < 0) {
> +error_report("%s: Couldn't disable %s: %s", __func__,
> +

Re: [PATCH] 9p: local: fix memory leak

2019-12-30 Thread Christian Schoenebeck

On Montag, 30. Dezember 2019 03:23:47 CET Yan Wang wrote:
> Signed-off-by: Yan Wang 
> ---
>  hw/9pfs/9p-local.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index ca641390fb..d0592c3b45 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -947,7 +947,7 @@ static int local_link(FsContext *ctx, V9fsPath *oldpath,
> if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
>  local_is_mapped_file_metadata(ctx, name)) {
>  errno = EINVAL;
> -return -1;
> +goto out;
>  }
> 
>  odirfd = local_opendir_nofollow(ctx, odirpath);

This issue was already addressed 10 days ago and is scheduled for merge on 
Greg's 9p-next branch:

https://github.com/gkurz/qemu/commit/ac5987075f42e44419a461846fdefde8ab4dd624

https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04774.html

Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine

2019-12-30 Thread Niek Linnenbank

Hi,

Here a short status report of this patch series.

For V3 update I already prepared the following:
 - reworked all review comments from Philippe, except:
   - patch#8: question for the SID, whether command-line override is
required (and how is the best way for machine-specific cli arg?) [1]
- added BootROM support, allows booting with only specifying -sd 
- added SDRAM controller driver, for U-Boot SPL
- added Allwinner generic RTC driver (for both Cubieboard and OrangePi PC,
supports sun4i, sun6i, sun7i)
- small fixes for EMAC

My current TODO:
 - integrate Philips acceptance tests in the series
 - integrate Philips work for generalizing the Allwinner timer, and finish
it
 - test and fix BSD targets (NetBSD, FreeBSD) [2, 3]
 - further generalize the series to cover very similar SoCs: H2+, H5

Does anyone have more comments/requests for the V3 update?

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04049.html
[2] https://wiki.netbsd.org/ports/evbarm/allwinner/
[3]
https://wiki.freebsd.org/action/show/arm/Allwinner?action=show=FreeBSD%2Farm%2FAllwinner

On Tue, Dec 17, 2019 at 12:35 AM Niek Linnenbank 
wrote:

> Dear QEMU developers,
>
> Hereby I would like to contribute the following set of patches to QEMU
> which add support for the Allwinner H3 System on Chip and the
> Orange Pi PC machine. The following features and devices are supported:
>
>  * SMP (Quad Core Cortex A7)
>  * Generic Interrupt Controller configuration
>  * SRAM mappings
>  * Timer device (re-used from Allwinner A10)
>  * UART
>  * SD/MMC storage controller
>  * EMAC ethernet connectivity
>  * USB 2.0 interfaces
>  * Clock Control Unit
>  * System Control module
>  * Security Identifier device
>
> Functionality related to graphical output such as HDMI, GPU,
> Display Engine and audio are not included. Recently released
> mainline Linux kernels (4.19 up to latest master) and mainline U-Boot
> are known to work. The SD/MMC code is tested using bonnie++ and
> various tools such as fsck, dd and fdisk. The EMAC is verified with iperf3
> using -netdev socket.
>
> To build a Linux mainline kernel that can be booted by the Orange Pi PC
> machine, simply configure the kernel using the sunxi_defconfig
> configuration:
>  $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make mrproper
>  $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make sunxi_defconfig
>
> To be able to use USB storage, you need to manually enable the
> corresponding
> configuration item. Start the kconfig configuration tool:
>  $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make menuconfig
>
> Navigate to the following item, enable it and save your configuration:
>  Device Drivers > USB support > USB Mass Storage support
>
> Build the Linux kernel with:
>  $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j5
>
> To boot the newly build linux kernel in QEMU with the Orange Pi PC
> machine, use:
>  $ qemu-system-arm -M orangepi-pc -m 512 -nic user -nographic \
>  -kernel /path/to/linux/arch/arm/boot/zImage \
>  -append 'console=ttyS0,115200' \
>  -dtb /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb
>
> Note that this kernel does not have a root filesystem. You may provide it
> with an official Orange Pi PC image [1] either as an SD card or as
> USB mass storage. To boot using the Orange Pi PC Debian image on SD card,
> simply add the -sd argument and provide the proper root= kernel parameter:
>  $ qemu-system-arm -M orangepi-pc -m 512 -nic user -nographic \
>  -kernel /path/to/linux/arch/arm/boot/zImage \
>  -append 'console=ttyS0,115200 root=/dev/mmcblk0p2' \
>  -dtb /path/to/linux/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dtb \
>  -sd OrangePi_pc_debian_stretch_server_linux5.3.5_v1.0.img
>
> Alternatively, you can also choose to build and boot a recent buildroot [2]
> using the orangepi_pc_defconfig or Armbian image [3] for Orange Pi PC.
> To attach an USB mass storage device to the machine, simply append to the
> command:
>  -drive if=none,id=stick,file=myimage.img \
>  -device usb-storage,bus=usb-bus.0,drive=stick
>
> U-Boot mainline can be build and configured using the orangepi_pc_defconfig
> using similar commands as describe above for Linux. To start U-Boot using
> the Orange Pi PC machine, provide the u-boot binary to the -kernel
> argument:
>  $ qemu-system-arm -M orangepi-pc -m 512 -nic user -nographic \
>  -kernel /path/to/uboot/u-boot -sd disk.img
>
> Use the following U-boot commands to load and boot a Linux kernel from SD
> card:
>  -> setenv bootargs console=ttyS0,115200
>  -> ext2load mmc 0 0x4200 zImage
>  -> ext2load mmc 0 0x4300 sun8i-h3-orangepi-pc.dtb
>  -> bootz 0x4200 - 0x4300
>
> Looking forward to your review comments. I will do my best
> to update the patches where needed.
>
> = CHANGELOG =
>
> v2:
>  * hw/arm/allwinner-h3.c: use cpus array in AwH3State instead of
> object_new()
>  * hw/arm/allwinner-h3.c: use error_abort in aw_h3_realize()
>  * hw/arm/allwinner-h3.c: use

[PATCH] MAINTAINERS: Remove Claudio Fontana bouncing email

2019-12-30 Thread Philippe Mathieu-Daudé

Claudio Fontana Huawei email is bouncing, remove it.

  The message you sent to claudio.font...@huawei.com couldn't be
  delivered due to: Recipient email address is possibly incorrect.

  Further information:
5.1.1 Error: invalid recipients

Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 387879aebc..8db4de6b9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2383,7 +2383,6 @@ F: plugins/
 F: tests/plugin
 
 AArch64 TCG target
-M: Claudio Fontana 
 M: Claudio Fontana 
 S: Maintained
 L: qemu-...@nongnu.org
-- 
2.21.0

[RFC PATCH 6/6] hw/arm/cubieboard: Disable unsupported M-USB in device tree blob

2019-12-30 Thread Philippe Mathieu-Daudé

We do not model the Sunxi Multipoint USB.
The Linux kernel OOPS when booting:

  [ cut here ]
  WARNING: CPU: 0 PID: 144 at drivers/usb/musb/sunxi.c:400 
sunxi_musb_ep_offset+0x39/0x3c
  sunxi_musb_ep_offset called with non 0 offset
  Modules linked in:
  CPU: 0 PID: 144 Comm: kworker/0:2 Not tainted 4.20.7-sunxi #5.75
  Hardware name: Allwinner sun4i/sun5i Families
  Workqueue: events deferred_probe_work_func
  [] (unwind_backtrace) from [] (show_stack+0x11/0x14)
  [] (show_stack) from [] (dump_stack+0x69/0x78)
  [] (dump_stack) from [] (__warn+0xa1/0xb4)
  [] (__warn) from [] (warn_slowpath_fmt+0x33/0x48)
  [] (warn_slowpath_fmt) from [] 
(sunxi_musb_ep_offset+0x39/0x3c)
  [] (sunxi_musb_ep_offset) from [] 
(ep_config_from_hw+0x99/0x104)
  [] (ep_config_from_hw) from [] (musb_probe+0x765/0xa0c)
  [] (musb_probe) from [] (platform_drv_probe+0x33/0x68)
  [] (platform_drv_probe) from [] (really_probe+0x16f/0x1e0)
  [] (really_probe) from [] (driver_probe_device+0x43/0x11c)
  [] (driver_probe_device) from [] 
(bus_for_each_drv+0x37/0x70)
  [] (bus_for_each_drv) from [] (__device_attach+0x83/0xc8)
  [] (__device_attach) from [] (bus_probe_device+0x5b/0x60)
  [] (bus_probe_device) from [] (device_add+0x2f5/0x474)
  [] (device_add) from [] (platform_device_add+0xb7/0x184)
  [] (platform_device_add) from [] 
(platform_device_register_full+0xb3/0xc4)
  [] (platform_device_register_full) from [] 
(sunxi_musb_probe+0x1d7/0x2f4)
  [] (sunxi_musb_probe) from [] 
(platform_drv_probe+0x33/0x68)
  [] (platform_drv_probe) from [] (really_probe+0x16f/0x1e0)
  [] (really_probe) from [] (driver_probe_device+0x43/0x11c)
  [] (driver_probe_device) from [] 
(bus_for_each_drv+0x37/0x70)
  [] (bus_for_each_drv) from [] (__device_attach+0x83/0xc8)
  [] (__device_attach) from [] (bus_probe_device+0x5b/0x60)
  [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x4b/0x6c)
  [] (deferred_probe_work_func) from [] 
(process_one_work+0x167/0x384)
  [] (process_one_work) from [] (worker_thread+0x251/0x3fc)
  [] (worker_thread) from [] (kthread+0xfd/0x104)
  [] (kthread) from [] (ret_from_fork+0x11/0x38)
  Exception stack(0xc6999fb0 to 0xc6999ff8)
  9fa0:    
  9fc0:        
  9fe0:     0013 
  ---[ end trace b309edbca98c7de2 ]---
  musb-sunxi 1c13000.usb: Error unknown readb offset 128
  musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -22
  musb-hdrc: probe of musb-hdrc.1.auto failed with error -22

This is not critical but confusing. To avoid the Linux kernel to
probe this device, mark it disabled in the device tree blob.

Signed-off-by: Philippe Mathieu-Daudé 
---
I'm not sure if this is a QEMU anti-pattern or bad practice.
I know we prefer to be as close to the hardware as possible,
but here the hardware is not changed, the dtb is. However
this makes the guest behave differently. At least we don't
have to manually edit the dts. If this is only annoying for
acceptance testing, we might consider manually editing the
dts in the tests setup().
---
 hw/arm/cubieboard.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
index 6dc2f1d6b6..dd10577696 100644
--- a/hw/arm/cubieboard.c
+++ b/hw/arm/cubieboard.c
@@ -22,10 +22,34 @@
 #include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/arm/allwinner-a10.h"
+#include 
+
+static void cubieboard_modify_dtb(const struct arm_boot_info *info, void *fdt)
+{
+static const char unsupported_compat[] = "allwinner,sun4i-a10-musb";
+char node_path[72];
+int offset;
+
+offset = fdt_node_offset_by_compatible(fdt, -1, unsupported_compat);
+while (offset >= 0) {
+int r = fdt_get_path(fdt, offset, node_path, sizeof(node_path));
+assert(r >= 0);
+r = fdt_setprop_string(fdt, offset, "status", "disabled");
+if (r < 0) {
+error_report("%s: Couldn't disable %s: %s", __func__,
+ unsupported_compat, fdt_strerror(r));
+exit(1);
+}
+warn_report("cubieboard: disabled unsupported node %s (%s) "
+"in device tree", node_path, unsupported_compat);
+offset = fdt_node_offset_by_compatible(fdt, offset, 
unsupported_compat);
+}
+}
 
 static struct arm_boot_info cubieboard_binfo = {
 .loader_start = AW_A10_SDRAM_BASE,
 .board_id = 0x1008,
+.modify_dtb = cubieboard_modify_dtb,
 };
 
 typedef struct CubieBoardState {
-- 
2.21.0

[PATCH 5/6] hw/arm/allwinner-a10: Remove local qemu_irq variables

2019-12-30 Thread Philippe Mathieu-Daudé

We won't reuse the CPU IRQ/FIQ variables. Simplify by calling
qdev_get_gpio_in() in place.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/allwinner-a10.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
index 966fbd4a6e..1cde165611 100644
--- a/hw/arm/allwinner-a10.c
+++ b/hw/arm/allwinner-a10.c
@@ -55,7 +55,6 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 {
 AwA10State *s = AW_A10(dev);
 SysBusDevice *sysbusdev;
-qemu_irq fiq, irq;
 Error *err = NULL;
 
 object_property_set_bool(OBJECT(>cpu), true, "realized", );
@@ -63,8 +62,6 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 error_propagate(errp, err);
 return;
 }
-irq = qdev_get_gpio_in(DEVICE(>cpu), ARM_CPU_IRQ);
-fiq = qdev_get_gpio_in(DEVICE(>cpu), ARM_CPU_FIQ);
 
 object_property_set_bool(OBJECT(>intc), true, "realized", );
 if (err != NULL) {
@@ -73,8 +70,10 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 }
 sysbusdev = SYS_BUS_DEVICE(>intc);
 sysbus_mmio_map(sysbusdev, 0, AW_A10_PIC_REG_BASE);
-sysbus_connect_irq(sysbusdev, 0, irq);
-sysbus_connect_irq(sysbusdev, 1, fiq);
+sysbus_connect_irq(sysbusdev, 0,
+   qdev_get_gpio_in(DEVICE(>cpu), ARM_CPU_IRQ));
+sysbus_connect_irq(sysbusdev, 1,
+   qdev_get_gpio_in(DEVICE(>cpu), ARM_CPU_FIQ));
 qdev_pass_gpios(DEVICE(>intc), dev, NULL);
 
 object_property_set_bool(OBJECT(>timer), true, "realized", );
-- 
2.21.0

[PATCH 4/6] hw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()

2019-12-30 Thread Philippe Mathieu-Daudé

By calling qdev_pass_gpios() we don't need to hold a copy of the
IRQs from the INTC into the SoC state.
Instead of filling an array of qemu_irq and passing it around, we
can now directly call qdev_get_gpio_in() on the SoC.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/arm/allwinner-a10.h |  1 -
 hw/arm/allwinner-a10.c | 24 +++-
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/include/hw/arm/allwinner-a10.h b/include/hw/arm/allwinner-a10.h
index 941c61e533..40d0b1d9c0 100644
--- a/include/hw/arm/allwinner-a10.h
+++ b/include/hw/arm/allwinner-a10.h
@@ -23,7 +23,6 @@ typedef struct AwA10State {
 /*< public >*/
 
 ARMCPU cpu;
-qemu_irq irq[AW_A10_PIC_INT_NR];
 AwA10PITState timer;
 AwA10PICState intc;
 AwEmacState emac;
diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
index 0f1af5a880..966fbd4a6e 100644
--- a/hw/arm/allwinner-a10.c
+++ b/hw/arm/allwinner-a10.c
@@ -55,7 +55,6 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 {
 AwA10State *s = AW_A10(dev);
 SysBusDevice *sysbusdev;
-uint8_t i;
 qemu_irq fiq, irq;
 Error *err = NULL;
 
@@ -76,9 +75,7 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 sysbus_mmio_map(sysbusdev, 0, AW_A10_PIC_REG_BASE);
 sysbus_connect_irq(sysbusdev, 0, irq);
 sysbus_connect_irq(sysbusdev, 1, fiq);
-for (i = 0; i < AW_A10_PIC_INT_NR; i++) {
-s->irq[i] = qdev_get_gpio_in(DEVICE(>intc), i);
-}
+qdev_pass_gpios(DEVICE(>intc), dev, NULL);
 
 object_property_set_bool(OBJECT(>timer), true, "realized", );
 if (err != NULL) {
@@ -87,12 +84,12 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 }
 sysbusdev = SYS_BUS_DEVICE(>timer);
 sysbus_mmio_map(sysbusdev, 0, AW_A10_PIT_REG_BASE);
-sysbus_connect_irq(sysbusdev, 0, s->irq[22]);
-sysbus_connect_irq(sysbusdev, 1, s->irq[23]);
-sysbus_connect_irq(sysbusdev, 2, s->irq[24]);
-sysbus_connect_irq(sysbusdev, 3, s->irq[25]);
-sysbus_connect_irq(sysbusdev, 4, s->irq[67]);
-sysbus_connect_irq(sysbusdev, 5, s->irq[68]);
+sysbus_connect_irq(sysbusdev, 0, qdev_get_gpio_in(dev, 22));
+sysbus_connect_irq(sysbusdev, 1, qdev_get_gpio_in(dev, 23));
+sysbus_connect_irq(sysbusdev, 2, qdev_get_gpio_in(dev, 24));
+sysbus_connect_irq(sysbusdev, 3, qdev_get_gpio_in(dev, 25));
+sysbus_connect_irq(sysbusdev, 4, qdev_get_gpio_in(dev, 67));
+sysbus_connect_irq(sysbusdev, 5, qdev_get_gpio_in(dev, 68));
 
 memory_region_init_ram(>sram_a, OBJECT(dev), "sram A", 48 * KiB,
_fatal);
@@ -111,7 +108,7 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 }
 sysbusdev = SYS_BUS_DEVICE(>emac);
 sysbus_mmio_map(sysbusdev, 0, AW_A10_EMAC_BASE);
-sysbus_connect_irq(sysbusdev, 0, s->irq[55]);
+sysbus_connect_irq(sysbusdev, 0, qdev_get_gpio_in(dev, 55));
 
 object_property_set_bool(OBJECT(>sata), true, "realized", );
 if (err) {
@@ -119,10 +116,11 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
 return;
 }
 sysbus_mmio_map(SYS_BUS_DEVICE(>sata), 0, AW_A10_SATA_BASE);
-sysbus_connect_irq(SYS_BUS_DEVICE(>sata), 0, s->irq[56]);
+sysbus_connect_irq(SYS_BUS_DEVICE(>sata), 0, qdev_get_gpio_in(dev, 56));
 
 /* FIXME use a qdev chardev prop instead of serial_hd() */
-serial_mm_init(get_system_memory(), AW_A10_UART0_REG_BASE, 2, s->irq[1],
+serial_mm_init(get_system_memory(), AW_A10_UART0_REG_BASE, 2,
+   qdev_get_gpio_in(dev, 1),
115200, serial_hd(0), DEVICE_NATIVE_ENDIAN);
 }
 
-- 
2.21.0

[PATCH 0/6] hw/arm/cubieboard: Few cleanups, add acceptance tests

2019-12-30 Thread Philippe Mathieu-Daudé

After looking at Niek Linnenbank implementation of the
Allwinner H3 [1], I looked what is common in the A10 [2].

Add some tests before modifying the code further.

[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg665532.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg666809.html

Philippe Mathieu-Daudé (6):
  tests/boot_linux_console: Add initrd test for the CubieBoard
  tests/boot_linux_console: Add a SD card test for the CubieBoard
  hw/arm/allwinner-a10: Move SoC definitions out of header
  hw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()
  hw/arm/allwinner-a10: Remove local qemu_irq variables
  hw/arm/cubieboard: Disable unsupported M-USB in device tree blob [RFC]

 include/hw/arm/allwinner-a10.h |  7 ---
 hw/arm/allwinner-a10.c | 39 ++--
 hw/arm/cubieboard.c| 24 
 tests/acceptance/boot_linux_console.py | 85 ++
 4 files changed, 130 insertions(+), 25 deletions(-)

-- 
2.21.0

[PATCH 2/6] tests/boot_linux_console: Add a SD card test for the CubieBoard

2019-12-30 Thread Philippe Mathieu-Daudé

The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://docs.armbian.com/Developer-Guide_Build-Preparation/

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

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

Alternatively, this test can be run using:

  $ avocado --show=console run -t machine:cubieboard 
tests/acceptance/boot_linux_console.py
  console: Uncompressing Linux... done, booting the kernel.
  console: Booting Linux on physical CPU 0x0
  console: Linux version 4.20.7-sunxi (r...@armbian.com) (gcc version 7.2.1 
20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019
  [...]
  console: ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.4
  console: ahci-sunxi 1c18000.sata: controller can't do 64bit DMA, forcing 32bit
  console: ahci-sunxi 1c18000.sata: AHCI 0001. 32 slots 1 ports 1.5 Gbps 
0x1 impl platform mode
  console: ahci-sunxi 1c18000.sata: flags: ncq only
  console: scsi host0: ahci-sunxi
  console: ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 
irq 27
  console: of_cfs_init
  console: of_cfs_init: OK
  console: vcc3v0: disabling
  console: vcc5v0: disabling
  console: usb1-vbus: disabling
  console: usb2-vbus: disabling
  console: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  console: ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
  console: ata1.00: 40960 sectors, multi 16: LBA48 NCQ (depth 32)
  console: ata1.00: applying bridge limits
  console: ata1.00: configured for UDMA/100
  console: scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK2.5+ PQ: 0 
ANSI: 5
  console: sd 0:0:0:0: Attached scsi generic sg0 type 0
  console: sd 0:0:0:0: [sda] 40960 512-byte logical blocks: (21.0 MB/20.0 MiB)
  console: sd 0:0:0:0: [sda] Write Protect is off
  console: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
  console: sd 0:0:0:0: [sda] Attached SCSI disk
  console: EXT4-fs (sda): mounting ext2 file system using the ext4 subsystem
  console: EXT4-fs (sda): mounted filesystem without journal. Opts: (null)
  console: VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
  [...]
  console: cat /proc/partitions
  console: / # cat /proc/partitions
  console: major minor  #blocks  name
  console: 10   4096 ram0
  console: 11   4096 ram1
  console: 12   4096 ram2
  console: 13   4096 ram3
  console: 80  20480 sda
  console: reboot
  console: / # reboot
  [...]
  console: sd 0:0:0:0: [sda] Synchronizing SCSI cache
  console: reboot: Restarting system
  PASS (48.39 s)

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

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 4643f60e37..e40b84651b 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -441,6 +441,50 @@ class BootLinuxConsole(Test):
 exec_command_and_wait_for_pattern(self, 'reboot',
 'reboot: Restarting system')
 
+def test_arm_cubieboard_sata(self):
+"""
+:avocado: tags=arch:arm
+:avocado: tags=machine:cubieboard
+"""
+deb_url = ('https://apt.armbian.com/pool/main/l/'
+   'linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb')
+deb_hash = '1334c29c44d984ffa05ed10de8c3361f33d78315'
+deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+kernel_path = self.extract_from_deb(deb_path,
+'/boot/vmlinuz-4.20.7-sunxi')
+dtb_path = '/usr/lib/linux-image-dev-sunxi/sun4i-a10-cubieboard.dtb'
+dtb_path = self.extract_from_deb(deb_path, dtb_path)
+rootfs_url = ('https://github.com/groeck/linux-build-test/raw/'
+  '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
+  'arm/rootfs-armv5.ext2.gz')
+rootfs_hash = '093e89d2b4d982234bf528bc9fb2f2f17a9d1f93'
+rootfs_path_gz = self.fetch_asset(rootfs_url, asset_hash=rootfs_hash)
+rootfs_path = os.path.join(self.workdir, 'rootfs.cpio')
+archive.gzip_uncompress(rootfs_path_gz, rootfs_path)
+
+self.vm.set_console()
+kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+   'console=ttyS0,115200 '
+   'usbcore.nousb '
+   'root=/dev/sda ro '
+   'panic=-1 noreboot')
+self.vm.add_args('-kernel', kernel_path,
+ '-dtb', dtb_path,
+ '-drive', 'if=none,format=raw,id=disk0,file='
+   +

[PATCH 1/6] tests/boot_linux_console: Add initrd test for the CubieBoard

2019-12-30 Thread Philippe Mathieu-Daudé

This test boots a Linux kernel on a CubieBoard and verify
the serial output is working.

The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://docs.armbian.com/Developer-Guide_Build-Preparation/

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

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

Alternatively, this test can be run using:

  $ avocado --show=console run -t machine:cubieboard 
tests/acceptance/boot_linux_console.py
  console: Uncompressing Linux... done, booting the kernel.
  console: Booting Linux on physical CPU 0x0
  console: Linux version 4.20.7-sunxi (r...@armbian.com) (gcc version 7.2.1 
20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019
  console: CPU: ARMv7 Processor [410fc080] revision 0 (ARMv7), cr=50c5387d
  console: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
  console: OF: fdt: Machine model: Cubietech Cubieboard
  [...]
  console: Boot successful.
  console: cat /proc/cpuinfo
  console: / # cat /proc/cpuinfo
  console: processor  : 0
  console: model name : ARMv7 Processor rev 0 (v7l)
  console: BogoMIPS   : 832.51
  [...]
  console: Hardware   : Allwinner sun4i/sun5i Families
  console: Revision   : 
  console: Serial : 
  console: cat /proc/iomem
  console: / # cat /proc/iomem
  console: 01c0-01c0002f : system-control@1c0
  console: 01c02000-01c02fff : dma-controller@1c02000
  console: 01c05000-01c05fff : spi@1c05000
  console: 01c0b080-01c0b093 : mdio@1c0b080
  console: 01c0c000-01c0cfff : lcd-controller@1c0c000
  console: 01c0d000-01c0dfff : lcd-controller@1c0d000
  console: 01c0f000-01c0 : mmc@1c0f000
  [...]
  PASS (54.35 s)

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

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index 9c6aa2040a..4643f60e37 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -400,6 +400,47 @@ class BootLinuxConsole(Test):
 self.wait_for_console_pattern('Boot successful.')
 # TODO user command, for now the uart is stuck
 
+def test_arm_cubieboard_initrd(self):
+"""
+:avocado: tags=arch:arm
+:avocado: tags=machine:cubieboard
+"""
+deb_url = ('https://apt.armbian.com/pool/main/l/'
+   'linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb')
+deb_hash = '1334c29c44d984ffa05ed10de8c3361f33d78315'
+deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+kernel_path = self.extract_from_deb(deb_path,
+'/boot/vmlinuz-4.20.7-sunxi')
+dtb_path = '/usr/lib/linux-image-dev-sunxi/sun4i-a10-cubieboard.dtb'
+dtb_path = self.extract_from_deb(deb_path, dtb_path)
+initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
+  '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
+  'arm/rootfs-armv5.cpio.gz')
+initrd_hash = '2b50f1873e113523967806f4da2afe385462ff9b'
+initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
+initrd_path = os.path.join(self.workdir, 'rootfs.cpio')
+archive.gzip_uncompress(initrd_path_gz, initrd_path)
+
+self.vm.set_console()
+kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+   'console=ttyS0,115200 '
+   'usbcore.nousb '
+   'panic=-1 noreboot')
+self.vm.add_args('-kernel', kernel_path,
+ '-dtb', dtb_path,
+ '-initrd', initrd_path,
+ '-append', kernel_command_line,
+ '-no-reboot')
+self.vm.launch()
+self.wait_for_console_pattern('Boot successful.')
+
+exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
+'Allwinner sun4i/sun5i')
+exec_command_and_wait_for_pattern(self, 'cat /proc/iomem',
+'system-control@1c0')
+exec_command_and_wait_for_pattern(self, 'reboot',
+'reboot: Restarting system')
+
 def test_s390x_s390_ccw_virtio(self):
 """
 :avocado: tags=arch:s390x
-- 
2.21.0

[PATCH 3/6] hw/arm/allwinner-a10: Move SoC definitions out of header

2019-12-30 Thread Philippe Mathieu-Daudé

These definitions are specific to the A10 SoC and don't need
to be exported to the different Allwinner peripherals.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/arm/allwinner-a10.h | 6 --
 hw/arm/allwinner-a10.c | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/hw/arm/allwinner-a10.h b/include/hw/arm/allwinner-a10.h
index 7d2d215630..941c61e533 100644
--- a/include/hw/arm/allwinner-a10.h
+++ b/include/hw/arm/allwinner-a10.h
@@ -12,12 +12,6 @@
 #include "target/arm/cpu.h"
 
 
-#define AW_A10_PIC_REG_BASE 0x01c20400
-#define AW_A10_PIT_REG_BASE 0x01c20c00
-#define AW_A10_UART0_REG_BASE   0x01c28000
-#define AW_A10_EMAC_BASE0x01c0b000
-#define AW_A10_SATA_BASE0x01c18000
-
 #define AW_A10_SDRAM_BASE   0x4000
 
 #define TYPE_AW_A10 "allwinner-a10"
diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
index 118032c8c7..0f1af5a880 100644
--- a/hw/arm/allwinner-a10.c
+++ b/hw/arm/allwinner-a10.c
@@ -25,6 +25,12 @@
 #include "hw/misc/unimp.h"
 #include "sysemu/sysemu.h"
 
+#define AW_A10_PIC_REG_BASE 0x01c20400
+#define AW_A10_PIT_REG_BASE 0x01c20c00
+#define AW_A10_UART0_REG_BASE   0x01c28000
+#define AW_A10_EMAC_BASE0x01c0b000
+#define AW_A10_SATA_BASE0x01c18000
+
 static void aw_a10_init(Object *obj)
 {
 AwA10State *s = AW_A10(obj);
-- 
2.21.0

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Paolo Bonzini

Il lun 30 dic 2019, 09:59 Philippe Mathieu-Daudé  ha
scritto:

> > I'd prefer not changing those files.
>
> OK, I'll wait to see what Richard/Markus prefer.
>

I think it's best if you keep the include directives as-is for files only
needed from tcg/, and move the other headers (those that are needed from
other directories only) to include/tcg.

Thanks and happy new year!

Paolo

>
> > Regards and best wished for 2020
>
> Thanks ;)
>
>

Re: PCI memory sync question (kvm,dpdk,e1000,packet stalled)

2019-12-30 Thread ASM

> It could be a bug in QEMU's e1000 emulation - maybe it's not doing
> things in the correct order and causes a race condition with the DPDK
> polling driver - or it could be a bug in the DPDK e1000 driver regarding
> the order in which the descriptor ring and RX Head/Tail MMIO registers
> are updated.


What did I understand:
* DPDK and Kernel drivers work like simular with ring. It don't
analize Head, but check STATUS.
This is a bit strange but completely correct driver behavior. If the
driver writes to memory, it expects
this value to be written. The problem is definitely not in the DPDK
and in the kernel driver.
* This problem appears on KVM, but not appears on tcg.
* Most similar to a bug in QEMU e1000 emulation. The e1000 emulation
read and writes to some
memory and same times, same as dpdk driver.


As I understand it, KVM explicitly prohibits access to shared memory.
It is obvious that us need to
protect (RCU) all STATUS registers of all buffers. There can be a lot
of buffers and they can be
scattered throughout the memory.

>
> Did you find the root cause?

I think yes, see above, but I can't understand how I can fix it.

For those who are interested in this problem, I made a project that
easily repeats this error:
https://github.com/BASM/qemu_dpdk_e1000_test

Unfortunately I don’t think that I can fix it on my own, without any help.

---
Best regards,
Leonid Myravjev

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Philippe Mathieu-Daudé


Hi Stefan,

On 12/30/19 10:53 AM, Stefan Weil wrote:

Am 30.12.19 um 10:08 schrieb Philippe Mathieu-Daudé:

[...]


  tcg/tcg-op.h  | 2 +-
  tcg/tcg.h | 4 ++--
  tcg/tcg-common.c  | 2 +-
  tcg/tcg-op-gvec.c | 8 
  tcg/tcg-op-vec.c  | 6 +++---
  tcg/tcg-op.c  | 6 +++---
  tcg/tcg.c | 2 +-
  tcg/tci.c | 2 +-



Source files in the tcg directory should not need any change because
they find include files in the same directory without searching.

If we add a tcg/ include file prefix for them as well, that has the
advantage that it might look prettier and more uniform, but it has the
disadvantage of requiring a search by the preprocessor.


Yeah, I was not sure about these specific files. My first attempt was 
without modifying them, but then I thought it would be better to keep 
the codebase uniform, as you said.




I'd prefer not changing those files.


OK, I'll wait to see what Richard/Markus prefer.


Regards and best wished for 2020


Thanks ;)

Re: [PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Stefan Weil

Am 30.12.19 um 10:08 schrieb Philippe Mathieu-Daudé:

[...]

>  tcg/tcg-op.h  | 2 +-
>  tcg/tcg.h | 4 ++--
>  tcg/tcg-common.c  | 2 +-
>  tcg/tcg-op-gvec.c | 8 
>  tcg/tcg-op-vec.c  | 6 +++---
>  tcg/tcg-op.c  | 6 +++---
>  tcg/tcg.c | 2 +-
>  tcg/tci.c | 2 +-


Source files in the tcg directory should not need any change because
they find include files in the same directory without searching.

If we add a tcg/ include file prefix for them as well, that has the
advantage that it might look prettier and more uniform, but it has the
disadvantage of requiring a search by the preprocessor.

I'd prefer not changing those files.

Regards and best wished for 2020
Stefan

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 10:35 AM, Michal Prívozník wrote:

On 12/30/19 9:41 AM, Philippe Mathieu-Daudé wrote:

On 12/30/19 9:00 AM, Michal Privoznik wrote:

In v4.2.0-246-ged9e923c3c the SMM property was moved from PC


Typo v4.2.0-246-ged9e923c3c -> ed9e923c3c.


This depends on how you format the hash :-)
I've used 'git describe ed9e923c3c' because I find it more readable for
us humans (at least we see what version the commit was introduced in).
But I don't know what the praxis is in qemu.


Hmm I never used it. Your explanation makes sense, but the tag confused 
me because I don't have it locally. However git (and gitk) seems clever 
enough to only use the useful part:


$ git show randomcrap-ged9e923c3c
commit ed9e923c3c9a2c50c4e82ba178b3fb1feba56867
Author: Paolo Bonzini 
Date:   Thu Dec 12 17:28:01 2019 +0100

x86: move SMM property to X86MachineState

FYI My output is different:

$ git describe ed9e923c3c
pull-target-arm-20191216-1-199-ged9e923c3c


machine class to x86 machine class. Makes sense, but the change
was too aggressive: in target/i386/kvm.c:kvm_arch_init() it
altered check which sets SMRAM if given machine has SMM enabled.
The line that detects whether given machine object is class of
PC_MACHINE was removed from the check. This makes qemu try to
enable SMRAM for all machine types, which is not what we want.



Fixes: ed9e923c3c
Reviewed-by: Philippe Mathieu-Daudé 


Thanks,
Michal

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Michal Prívozník

On 12/30/19 9:41 AM, Philippe Mathieu-Daudé wrote:
> On 12/30/19 9:00 AM, Michal Privoznik wrote:
>> In v4.2.0-246-ged9e923c3c the SMM property was moved from PC
> 
> Typo v4.2.0-246-ged9e923c3c -> ed9e923c3c.

This depends on how you format the hash :-)
I've used 'git describe ed9e923c3c' because I find it more readable for
us humans (at least we see what version the commit was introduced in).
But I don't know what the praxis is in qemu.

> 
>> machine class to x86 machine class. Makes sense, but the change
>> was too aggressive: in target/i386/kvm.c:kvm_arch_init() it
>> altered check which sets SMRAM if given machine has SMM enabled.
>> The line that detects whether given machine object is class of
>> PC_MACHINE was removed from the check. This makes qemu try to
>> enable SMRAM for all machine types, which is not what we want.
>>
> 
> Fixes: ed9e923c3c
> Reviewed-by: Philippe Mathieu-Daudé 

Thanks,
Michal

[PATCH 2/2] configure: Remove tcg/ from the preprocessor include search list

2019-12-30 Thread Philippe Mathieu-Daudé

All tcg includes are relative to the repository root directory,
we can safely remove the tcg/ directory from the include search
path list.

Signed-off-by: Philippe Mathieu-Daudé 
---
 configure | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure b/configure
index 940bf9e87a..74dad08580 100755
--- a/configure
+++ b/configure
@@ -7436,7 +7436,6 @@ elif test "$ARCH" = "riscv32" || test "$ARCH" = "riscv64" 
; then
 else
   QEMU_INCLUDES="-iquote \$(SRC_PATH)/tcg/\$(ARCH) $QEMU_INCLUDES"
 fi
-QEMU_INCLUDES="-iquote \$(SRC_PATH)/tcg $QEMU_INCLUDES"
 
 echo "TOOLS=$tools" >> $config_host_mak
 echo "ROMS=$roms" >> $config_host_mak
-- 
2.21.0

[PATCH 1/2] tcg: Search includes from the project root source directory

2019-12-30 Thread Philippe Mathieu-Daudé

We currently search both the root and the tcg/ directories for tcg
files:

  $ git grep '#include "tcg/' | wc -l
  28

  $ git grep '#include "tcg[^/]' | wc -l
  94

To simplify the preprocessor search path, unify by expliciting the
tcg/ directory.

Patch created mechanically by running:

  $ for x in $(ls tcg/*.{c,h} | sed s,tcg/,,); do \
sed -i "s,#include \"$x\",#include \"tcg/$x\"," \
  $(git grep -l "#include \"$x\""); \
done

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu_ldst.h   | 2 +-
 tcg/i386/tcg-target.h | 2 +-
 tcg/tcg-op.h  | 2 +-
 tcg/tcg.h | 4 ++--
 accel/tcg/cpu-exec.c  | 2 +-
 accel/tcg/tcg-runtime-gvec.c  | 2 +-
 accel/tcg/translate-all.c | 2 +-
 accel/tcg/user-exec.c | 2 +-
 bsd-user/main.c   | 2 +-
 cpus.c| 2 +-
 exec.c| 2 +-
 linux-user/main.c | 2 +-
 target/alpha/translate.c  | 2 +-
 target/arm/helper-a64.c   | 2 +-
 target/arm/translate-a64.c| 4 ++--
 target/arm/translate-sve.c| 6 +++---
 target/arm/translate.c| 4 ++--
 target/cris/translate.c   | 2 +-
 target/hppa/translate.c   | 2 +-
 target/i386/mem_helper.c  | 2 +-
 target/i386/translate.c   | 2 +-
 target/lm32/translate.c   | 2 +-
 target/m68k/translate.c   | 2 +-
 target/microblaze/translate.c | 2 +-
 target/mips/translate.c   | 2 +-
 target/moxie/translate.c  | 2 +-
 target/nios2/translate.c  | 2 +-
 target/openrisc/translate.c   | 2 +-
 target/ppc/mem_helper.c   | 2 +-
 target/ppc/translate.c| 4 ++--
 target/riscv/cpu_helper.c | 2 +-
 target/riscv/translate.c  | 2 +-
 target/s390x/translate.c  | 4 ++--
 target/sh4/translate.c| 2 +-
 target/sparc/ldst_helper.c| 2 +-
 target/sparc/translate.c  | 2 +-
 target/tilegx/translate.c | 2 +-
 target/tricore/translate.c| 2 +-
 target/unicore32/translate.c  | 2 +-
 target/xtensa/translate.c | 2 +-
 tcg/aarch64/tcg-target.inc.c  | 4 ++--
 tcg/arm/tcg-target.inc.c  | 4 ++--
 tcg/i386/tcg-target.inc.c | 4 ++--
 tcg/mips/tcg-target.inc.c | 2 +-
 tcg/optimize.c| 2 +-
 tcg/ppc/tcg-target.inc.c  | 4 ++--
 tcg/riscv/tcg-target.inc.c| 4 ++--
 tcg/s390/tcg-target.inc.c | 4 ++--
 tcg/sparc/tcg-target.inc.c| 2 +-
 tcg/tcg-common.c  | 2 +-
 tcg/tcg-op-gvec.c | 8 
 tcg/tcg-op-vec.c  | 6 +++---
 tcg/tcg-op.c  | 6 +++---
 tcg/tcg.c | 2 +-
 tcg/tci.c | 2 +-
 55 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
index fd499f7e2f..9c637f6e89 100644
--- a/include/exec/cpu_ldst.h
+++ b/include/exec/cpu_ldst.h
@@ -153,7 +153,7 @@ static inline void clear_helper_retaddr(void)
 #else
 
 /* The memory helpers for tcg-generated code need tcg_target_long etc.  */
-#include "tcg.h"
+#include "tcg/tcg.h"
 
 static inline target_ulong tlb_addr_write(const CPUTLBEntry *entry)
 {
diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 928e8b87bb..bfb3f5f6e9 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -223,7 +223,7 @@ static inline void tb_target_set_jmp_target(uintptr_t 
tc_ptr,
  * The x86 has a pretty strong memory ordering which only really
  * allows for some stores to be re-ordered after loads.
  */
-#include "tcg-mo.h"
+#include "tcg/tcg-mo.h"
 
 #define TCG_TARGET_DEFAULT_MO (TCG_MO_ALL & ~TCG_MO_ST_LD)
 
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index 4af272daa5..230db6e022 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -25,7 +25,7 @@
 #ifndef TCG_TCG_OP_H
 #define TCG_TCG_OP_H
 
-#include "tcg.h"
+#include "tcg/tcg.h"
 #include "exec/helper-proto.h"
 #include "exec/helper-gen.h"
 
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 92ca10dffc..bb59027240 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -31,7 +31,7 @@
 #include "qemu/bitops.h"
 #include "qemu/plugin.h"
 #include "qemu/queue.h"
-#include "tcg-mo.h"
+#include "tcg/tcg-mo.h"
 #include "tcg-target.h"
 #include "qemu/int128.h"
 
@@ -211,7 +211,7 @@ typedef uint64_t TCGRegSet;
 
 typedef enum TCGOpcode {
 #define DEF(name, oargs, iargs, cargs, flags) INDEX_op_ ## name,
-#include "tcg-opc.h"
+#include "tcg/tcg-opc.h"
 #undef DEF
 NB_OPS,
 } TCGOpcode;
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 62068d10c3..2560c90eec 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -23,7 +23,7 @@
 #include "trace.h"
 #include "disas/disas.h"
 #include "exec/exec-all.h"
-#include "tcg.h"
+#include "tcg/tcg.h"
 #include "qemu/atomic.h"
 #include "sysemu/qtest.h"
 #include "qemu/timer.h"
diff --git a/accel/tcg/tcg-runtime-gvec.c b/accel/tcg/tcg-runtime-gvec.c
index 51cb29ca79..5b1902d591 100644
--- a/accel/tcg/tcg-runtime-gvec.c
+++ b/accel/tcg/tcg-runtime-gvec.c
@@ -21,7 +21,7 @@
 #include "qemu/host-utils.h"
 #include "cpu.h"
 #include

[PATCH 0/2] tcg: Include tcg files using tcg/ dirname, reduce cpp search path list

2019-12-30 Thread Philippe Mathieu-Daudé

Noticed we could clean this while reviewing Richard patch last night:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg667606.html

Philippe Mathieu-Daudé (2):
  tcg: Search includes from the project root source directory
  configure: Remove tcg/ from the preprocessor include search list

 configure | 1 -
 include/exec/cpu_ldst.h   | 2 +-
 tcg/i386/tcg-target.h | 2 +-
 tcg/tcg-op.h  | 2 +-
 tcg/tcg.h | 4 ++--
 accel/tcg/cpu-exec.c  | 2 +-
 accel/tcg/tcg-runtime-gvec.c  | 2 +-
 accel/tcg/translate-all.c | 2 +-
 accel/tcg/user-exec.c | 2 +-
 bsd-user/main.c   | 2 +-
 cpus.c| 2 +-
 exec.c| 2 +-
 linux-user/main.c | 2 +-
 target/alpha/translate.c  | 2 +-
 target/arm/helper-a64.c   | 2 +-
 target/arm/translate-a64.c| 4 ++--
 target/arm/translate-sve.c| 6 +++---
 target/arm/translate.c| 4 ++--
 target/cris/translate.c   | 2 +-
 target/hppa/translate.c   | 2 +-
 target/i386/mem_helper.c  | 2 +-
 target/i386/translate.c   | 2 +-
 target/lm32/translate.c   | 2 +-
 target/m68k/translate.c   | 2 +-
 target/microblaze/translate.c | 2 +-
 target/mips/translate.c   | 2 +-
 target/moxie/translate.c  | 2 +-
 target/nios2/translate.c  | 2 +-
 target/openrisc/translate.c   | 2 +-
 target/ppc/mem_helper.c   | 2 +-
 target/ppc/translate.c| 4 ++--
 target/riscv/cpu_helper.c | 2 +-
 target/riscv/translate.c  | 2 +-
 target/s390x/translate.c  | 4 ++--
 target/sh4/translate.c| 2 +-
 target/sparc/ldst_helper.c| 2 +-
 target/sparc/translate.c  | 2 +-
 target/tilegx/translate.c | 2 +-
 target/tricore/translate.c| 2 +-
 target/unicore32/translate.c  | 2 +-
 target/xtensa/translate.c | 2 +-
 tcg/aarch64/tcg-target.inc.c  | 4 ++--
 tcg/arm/tcg-target.inc.c  | 4 ++--
 tcg/i386/tcg-target.inc.c | 4 ++--
 tcg/mips/tcg-target.inc.c | 2 +-
 tcg/optimize.c| 2 +-
 tcg/ppc/tcg-target.inc.c  | 4 ++--
 tcg/riscv/tcg-target.inc.c| 4 ++--
 tcg/s390/tcg-target.inc.c | 4 ++--
 tcg/sparc/tcg-target.inc.c| 2 +-
 tcg/tcg-common.c  | 2 +-
 tcg/tcg-op-gvec.c | 8 
 tcg/tcg-op-vec.c  | 6 +++---
 tcg/tcg-op.c  | 6 +++---
 tcg/tcg.c | 2 +-
 tcg/tci.c | 2 +-
 56 files changed, 75 insertions(+), 76 deletions(-)

-- 
2.21.0

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Philippe Mathieu-Daudé


On 12/30/19 9:00 AM, Michal Privoznik wrote:

In v4.2.0-246-ged9e923c3c the SMM property was moved from PC


Typo v4.2.0-246-ged9e923c3c -> ed9e923c3c.


machine class to x86 machine class. Makes sense, but the change
was too aggressive: in target/i386/kvm.c:kvm_arch_init() it
altered check which sets SMRAM if given machine has SMM enabled.
The line that detects whether given machine object is class of
PC_MACHINE was removed from the check. This makes qemu try to
enable SMRAM for all machine types, which is not what we want.



Fixes: ed9e923c3c
Reviewed-by: Philippe Mathieu-Daudé 


Signed-off-by: Michal Privoznik 
---
  target/i386/kvm.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 0b511906e3..7ee3202634 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -2173,6 +2173,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
  }
  
  if (kvm_check_extension(s, KVM_CAP_X86_SMM) &&

+object_dynamic_cast(OBJECT(ms), TYPE_X86_MACHINE) &&
  x86_machine_is_smm_enabled(X86_MACHINE(ms))) {
  smram_machine_done.notify = register_smram_listener;
  qemu_add_machine_init_done_notifier(_machine_done);

Re: [PATCH] 9p: local: fix memory leak

2019-12-30 Thread Philippe Mathieu-Daudé


Please describe the memory leak, and if possible how you noticed it.

Indeed the previous 2 calls to g_path_get_dirname() aren't free'd.

On 12/30/19 3:23 AM, Yan Wang wrote:

Signed-off-by: Yan Wang 
---
  hw/9pfs/9p-local.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index ca641390fb..d0592c3b45 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -947,7 +947,7 @@ static int local_link(FsContext *ctx, V9fsPath *oldpath,
  if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
  local_is_mapped_file_metadata(ctx, name)) {
  errno = EINVAL;
-return -1;
+goto out;


As the rest of this function... OK.
With some love this function could get clever by only allocating 
variables it will use.


With better commit description:
Reviewed-by: Philippe Mathieu-Daudé 


  }
  
  odirfd = local_opendir_nofollow(ctx, odirpath);

[Bug 1857449] Re: QEMU x86_64 -nographic full system breaks host Bash terminal line wrapping state after simulation ends, requires reset or "tput smam" to fix it

2019-12-30 Thread Ciro Santilli 六四事件法轮功

Ah, thanks for looking into this and identifying it to guest code
Philippe. I don't know much about terminals, but yes, they are such
archaic interfaces, maybe there is no API for it :-(

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

Title:
  QEMU x86_64 -nographic full system breaks host Bash terminal line
  wrapping state after simulation ends, requires reset or "tput smam" to
  fix it

Status in QEMU:
  New

Bug description:
  QEMU 4.2.0 compiled from source, Ubuntu 19.10, open a fresh new gnome
  terminal.

  If you print 1000 = chars on the host terminal, then they do wrap
  around the end of the terminal:

  printf "=%.0s" {0..1000}

  However, if you first run QEMU:

  x86_64-softmmu/qemu-system-x86_64 -nographic

  and then quit it in any way, e.g. with Ctrl + A, and then re-run on
  the host terminal:

  printf "=%.0s" {0..1000}

  then the signs don't wrap around anymore, they just go "off the
  terminal to the right".

  This can be fixed with either:

  reset
  tpam smam

  but unfortunately those don't work in tmux for some reason:
  https://github.com/tmux/tmux/issues/969

  I consider this buggy behavior, QEMU should restore the original
  terminal state if possible.

  Related: https://github.com/cirosantilli/linux-kernel-module-
  cheat/issues/110

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

[PATCH] scripts/git.orderfile: Display decodetree before C source

2019-12-30 Thread Philippe Mathieu-Daudé

To avoid scrolling each instruction when reviewing tcg
helpers written for the decodetree script, display the
.decode files (similar to header declarations) before
the C source (implementation of previous declarations).

Signed-off-by: Philippe Mathieu-Daudé 
---
 scripts/git.orderfile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/git.orderfile b/scripts/git.orderfile
index e89790941c..1f747b583a 100644
--- a/scripts/git.orderfile
+++ b/scripts/git.orderfile
@@ -25,5 +25,8 @@ qga/*.json
 # headers
 *.h
 
+# decoding tree specification
+*.decode
+
 # code
 *.c
-- 
2.21.0

Re: [Qemu-devel] [PATCH] RISCV: support riscv vector extension 0.7.1

2019-12-30 Thread LIU Zhiwei





On 2019/12/28 9:14, Richard Henderson wrote:

On 12/25/19 8:36 PM, LIU Zhiwei wrote:

struct {

     uint64_t vreg[32 * RV_VLEN_MAX / 64] QEMU_ALIGNED(16);
     target_ulong vxrm;
     target_ulong vxsat;
     target_ulong vl;
     target_ulong vstart;
     target_ulong vtype;
     } vext;

Is it OK?

I don't think there's a good reason for the vext structure -- I would drop
that.  Otherwise it looks good.


However, there are still some differences from SVE.

1)cpu_env must be used as a parameter for helper function.

     The helpers need  use env->vext.vl and env->vext.vstart.  Thus it will be
difficult to use out of line tcg_gen_gvec_ool.

Sure.  That's also true of any of the fp operations, which will want to
accumulate ieee exceptions.

See tcg_gen_gvec_*_ptr(), which allows you to pass in cpu_env.

Thanks. The tcg_gen_gvec_*_ptr is good.



2）simd_desc is not proper.

     I also need to transfer some members of DisasContext to helpers.

     (Data, Vlmax, Mlen) is my current choice. Vlmax is the num of elements of
this operation, so it will defined as ctx->lmul * ctx->vlen / ctx->sew;

The oprsz & maxsz parameters to tcg_gen_gvec_* should be given (ctx->lmul *
ctx->vlen).  The sew parameter should be implied by the helper function called,
each helper function using a different type.  Therefore vlmax can be trivially
computed within the helper from oprsz / sizeof(type).
It's clear that the oprsz & maxsz paramenters should be given (ctx->lmul 
* ctx->vlen) for tcg_gen_gvec_add.


However It's not clear when use tcg_gen_gvec_*_ptr or tcg_gen_gvec_ool. 
I think the meaning of oprsz is the
the bits of active elements.  Therefore , oprsz is  8 * env->vext.vl in 
RISC-V and it can't be fetched  from

TB_FLAGS like SVE.

Probably oprsz field will be not be used in RISC-V vector extension.

Data is reserved to expand.  Mlen is mask length for one elment, so it will
defined as ctx->sew/ctx->lmul. As with Mlen, a active element will

be selected by

 static inline int vext_elem_mask(void *v0, int mlen, int index)
 {
     int idx = (index * mlen) / 8;
     int pos = (index * mlen) % 8;

     return (v0[idx] >> pos) & 0x1;
 }

     So I may have to implement vext_desc instead of use the simd_desc, which
will be another redundant. Maybe a better way to mask elements?

I think you will want to define your own vext_desc, building upon simd_desc,
such that lg2(mlen) is passed in the first N bits of simd_data.

Good. It's a good way to use the tcg_gen_gvec_*_ptr or tcg_gen_gvec_ool API.

Best Regards,
Zhiwei


r~

Re: [PATCH] x86: Check for machine state object class before typecasting it

2019-12-30 Thread no-reply

Patchew URL: 
https://patchew.org/QEMU/7cc91bab3191bfd7e071bdd3fdf7fe2a2991deb0.1577692822.git.mpriv...@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 ===




The full log is available at
http://patchew.org/logs/7cc91bab3191bfd7e071bdd3fdf7fe2a2991deb0.1577692822.git.mpriv...@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] x86: Check for machine state object class before typecasting it

2019-12-30 Thread Michal Privoznik

In v4.2.0-246-ged9e923c3c the SMM property was moved from PC
machine class to x86 machine class. Makes sense, but the change
was too aggressive: in target/i386/kvm.c:kvm_arch_init() it
altered check which sets SMRAM if given machine has SMM enabled.
The line that detects whether given machine object is class of
PC_MACHINE was removed from the check. This makes qemu try to
enable SMRAM for all machine types, which is not what we want.

Signed-off-by: Michal Privoznik 
---
 target/i386/kvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 0b511906e3..7ee3202634 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -2173,6 +2173,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 }
 
 if (kvm_check_extension(s, KVM_CAP_X86_SMM) &&
+object_dynamic_cast(OBJECT(ms), TYPE_X86_MACHINE) &&
 x86_machine_is_smm_enabled(X86_MACHINE(ms))) {
 smram_machine_done.notify = register_smram_listener;
 qemu_add_machine_init_done_notifier(_machine_done);
-- 
2.24.1

54 matches

Mail list logo