Re: [Qemu-devel] [PATCH] intel_iommu: Correct caching-mode error message

[Peter Xu]

On Tue, Mar 26, 2019 at 05:05:38PM -0600, Alex Williamson wrote:
> If we try to use the intel-iommu device with vfio-pci devices without
> caching mode enabled, we're told:
> 
>   qemu-system-x86_64: We need to set caching-mode=1 for intel-iommu to enable
>   device assignment with IOMMU protection.
> 
> But to enable caching mode, the option is actually "caching-mode=on".
> 
> Signed-off-by: Alex Williamson 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [Qemu-devel] [PULL 02/29] ppc/spapr: Receive and store device tree blob from SLOF

[David Gibson]

On Tue, Mar 26, 2019 at 08:09:53AM +0100, Greg Kurz wrote:
> On Tue, 26 Mar 2019 10:47:15 +1100
> David Gibson  wrote:
> 
> > On Mon, Mar 25, 2019 at 05:33:21PM +0100, Greg Kurz wrote:
> > > On Mon, 25 Mar 2019 11:53:47 +1100
> > > David Gibson  wrote:
> > >   
> > > > On Sun, Mar 24, 2019 at 12:03:54AM -0400, Brad Smith wrote:  
> > > > > Now that I am checking out 4.0.0 rc's I see this diff is broken and
> > > > > depends on a function libfdt does not expose. The breakage is
> > > > > hidden by the fallback check in the configure script.
> > > > 
> > > > Ah, bother.  That keeps happening, unfortunately.  I think it's
> > > > because so many people use libfdt embedded, rather than as a shared
> > > > library that we tend not to notice.
> > > >   
> > > 
> > > It's a bit more complicated. I do have latest libfdt packages on my 
> > > laptop:
> > > 
> > > libfdt-1.4.7-2.fc28.x86_64
> > > libfdt-devel-1.4.7-2.fc28.x86_64
> > > 
> > > but I still end up using the embedded one and the build doesn't spot
> > > the missing symbols.  
> > 
> > Sorry, I wasn't clear.  I wasn't meaning in the context of qemu, but
> > for dtc generally.  A large portion of the users are things like
> > u-boot that have to use dtc embedded, rather than as a shared
> > library.  That's why we tend not to notice missing symbols from the
> > version script upstream.
> > 
> 
> Ok, I get it.
> 
> > > This happens because of several reasons:
> > > 
> > > 1) configure unconditionally falls back to embedded if an error occurs 
> > > with
> > >the system packages. And, as reported by Brad, the current 1.4.7 
> > > packages
> > >are broken indeed:
> > > 
> > > $ objdump -T /usr/lib64/libfdt-1.4.7.so | grep fdt_check_full
> > > $ 
> > > 
> > > 2) when building embedded, we only build the archive, not the shared lib.
> > >   
> > > > I guess we should figure out how to force the testsuite to link
> > > > against the shared library rather than static to test for this.  I'll
> > > > look into it if I have time (which is a big if).
> > > >   
> > > 
> > > I think we should rather build the embedded shared library using
> > > the 'libfdt' rule of the top-level makefile of the dtc sub-module
> > > and have QEMU to be linked against this share library instead of
> > > the static one. AFAIK, this is what gcc does when it finds both
> > > .a and .so.  
> > 
> > Actually, I don't think this is a good idea.  It means the resulting
> > qemu build would have to be installed with the libfdt image as well.
> > As well as complicating the install path, that means that the qemu
> > build will now actively conflict with a packaged libfdt, rather than
> > merely suboptimally failing to use it.
> 
> Yes you're right: the resulting QEMU shouldn't be installed, especially
> if it has a RPATH poiting to the build directory.
> 
> This being said, if someone wants to build AND install QEMU, shouldn't
> she rely exclusively on installed libfdt packages ? In other words,
> shouldn't the embedded libfdt be a QEMU developper only thing ? What
> are the real life use cases for embedded libfdt ?

I don't think we should insist on that, although it's certainly the
way distros will usually work.  If someone wants to build and install
qemu locally, I don't think we should insist they first work out how
to install a new enough libfdt for it to use.

Likewise a limited purpose distro for whom qemu is the only user of
libfdt might not want to package it separately.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH for-4.0?] exec: Only count mapped memory backends for qemu_getrampagesize()

[David Gibson]

On Tue, Mar 26, 2019 at 03:08:20PM +0100, Igor Mammedov wrote:
> On Tue, 26 Mar 2019 14:50:58 +1100
> David Gibson  wrote:
> 
> > qemu_getrampagesize() works out the minimum host page size backing any of
> > guest RAM.  This is required in a few places, such as for POWER8 PAPR KVM
> > guests, because limitations of the hardware virtualization mean the guest
> > can't use pagesizes larger than the host pages backing its memory.
> > 
> > However, it currently checks against *every* memory backend, whether or not
> > it is actually mapped into guest memory at the moment.  This is incorrect.
> > 
> > This can cause a problem attempting to add memory to a POWER8 pseries KVM
> > guest which is configured to allow hugepages in the guest (e.g.
> > -machine cap-hpt-max-page-size=16m).  If you attempt to add non-hugepage,
> > you can (correctly) create a memory backend, however it (correctly) will
> > throw an error when you attempt to map that memory into the guest by
> > 'device_add'ing a pc-dimm.
> > 
> > What's not correct is that if you then reset the guest a startup check
> > against qemu_getrampagesize() will cause a fatal error because of the new
> > memory object, even though it's not mapped into the guest.
> I'd say that backend should be remove by mgmt app since device_add failed
> instead of leaving it to hang around. (but fatal error either not a nice
> behavior on QEMU part)

I agree, but reset could be guest initiated, so even if management is
doing the right thing there's a window where it could break.

> > This patch corrects the problem by adjusting find_max_supported_pagesize()
> > (called from qemu_getrampagesize() via object_child_foreach) to exclude
> > non-mapped memory backends.
> I'm not sure about if it's ok do so. It depends on where from
> qemu_getrampagesize() is called. For example s390 calls it rather early
> when initializing KVM, so there isn't anything mapped yet.

Oh.  Drat.

> And once I replace -mem-path with hostmem backend and drop
> qemu_mempath_getpagesize(mem_path) /which btw aren't guarantied to be mapped 
> either/
> this patch might lead to incorrect results for initial memory as
> well.

Uh.. I don't immediately see why.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] target/ppc: Improve comment of bcctr used for spectre v2 mitigation

[David Gibson]

On Tue, Mar 26, 2019 at 11:21:11AM +0100, Greg Kurz wrote:
> Signed-off-by: Greg Kurz 

Applied, thanks.

> ---
>  target/ppc/translate.c |   10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 576210d901ad..badc1ae1a35d 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -3753,7 +3753,15 @@ static void gen_bcond(DisasContext *ctx, int type)
>   * All ISAs up to v3 describe this form of bcctr as invalid but
>   * some processors, ie. 64-bit server processors compliant with
>   * arch 2.x, do implement a "test and decrement" logic instead,
> - * as described in their respective UMs.
> + * as described in their respective UMs. This logic involves CTR
> + * to act as both the branch target and a counter, which makes
> + * it basically useless and thus never used in real code.
> + *
> + * This form was hence chosen to trigger extra 
> micro-architectural
> + * side-effect on real HW needed for the Spectre v2 workaround.
> + * It is up to guests that implement such workaround, ie. linux, 
> to
> + * use this form in a way it just triggers the side-effect 
> without
> + * doing anything else harmful.
>   */
>  if (unlikely(!is_book3s_arch2x(ctx))) {
>  gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
> 

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [qemu-s390x] [PATCH for-4.0?] exec: Only count mapped memory backends for qemu_getrampagesize()

[David Gibson]

On Tue, Mar 26, 2019 at 06:02:51PM +0100, David Hildenbrand wrote:
> On 26.03.19 15:08, Igor Mammedov wrote:
> > On Tue, 26 Mar 2019 14:50:58 +1100
> > David Gibson  wrote:
> > 
> >> qemu_getrampagesize() works out the minimum host page size backing any of
> >> guest RAM.  This is required in a few places, such as for POWER8 PAPR KVM
> >> guests, because limitations of the hardware virtualization mean the guest
> >> can't use pagesizes larger than the host pages backing its memory.
> >>
> >> However, it currently checks against *every* memory backend, whether or not
> >> it is actually mapped into guest memory at the moment.  This is incorrect.
> >>
> >> This can cause a problem attempting to add memory to a POWER8 pseries KVM
> >> guest which is configured to allow hugepages in the guest (e.g.
> >> -machine cap-hpt-max-page-size=16m).  If you attempt to add non-hugepage,
> >> you can (correctly) create a memory backend, however it (correctly) will
> >> throw an error when you attempt to map that memory into the guest by
> >> 'device_add'ing a pc-dimm.
> >>
> >> What's not correct is that if you then reset the guest a startup check
> >> against qemu_getrampagesize() will cause a fatal error because of the new
> >> memory object, even though it's not mapped into the guest.
> > I'd say that backend should be remove by mgmt app since device_add failed
> > instead of leaving it to hang around. (but fatal error either not a nice
> > behavior on QEMU part)
> 
> Indeed, it should be removed. Depending on the options (huge pages with
> prealloc?) memory might be consumed for unused memory. Undesired.

Right, but if the guest initiates a reboot before the management gets
to that, we'll have a crash.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH for 4.0 v1 1/1] MAINTAINERS: Update the device tree maintainers

[da...@gibson.dropbear.id.au]

On Tue, Mar 26, 2019 at 08:59:23PM +, Alistair Francis wrote:
> Remove Alex as a Device Tree maintainer as requested by him. Add myself
> as a maintainer to avoid it being orphaned. Also add David as a
> Reviewer (R) as he is the libfdt and DTC maintainer.
> 
> Signed-off-by: Alistair Francis 

Acked-by: David Gibson 

> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 85d7d764e5..c2ad5062f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1813,7 +1813,8 @@ F: qom/cpu.c
>  F: include/qom/cpu.h
>  
>  Device Tree
> -M: Alexander Graf 
> +M: Alistair Francis 
> +R: David Gibson 
>  S: Maintained
>  F: device_tree.c
>  F: include/sysemu/device_tree.h

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


signature.asc
Description: PGP signature

[Qemu-devel] [Bug 1821839] [NEW] qemu 4.0 doesnt support glsl 3.0 but yes older versions, that have no sense IMO

[salvador liébana]

Public bug reported:

tested on qemu 4.0.rc1 on rpi3, mesa 19.x
maybe I am a bit confused, but why it can use and older version from my mesa 
driver, it should pickup the right version instead of going to the latest.

pi@pi:~/Desktop/armbian/windows_95_vdi $ qemu-system-i386 -cpu qemu32  -m 32 
-display sdl,gl=on -device virtio-vga,virgl=on -soundhw sb16 
qemu_gl_create_compile_shader: compile vertex error
0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 
1.20, and 1.00 ES

qemu_gl_create_compile_shader: compile fragment error
0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 
1.20, and 1.00 ES

qemu_gl_create_compile_shader: compile vertex error
0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 
1.20, and 1.00 ES

qemu_gl_create_compile_shader: compile fragment error
0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 
1.20, and 1.00 ES

the sames happen on mesa 13.x (default mesa included on raspbian)

GLXINFO

pi@pi:~/Desktop/armbian/windows_95_vdi $ glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, 
GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_SGI_make_current_read, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, 
GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Broadcom (0x14e4)
Device: VC4 V3D 2.1 (0x)
Version: 19.1.0
Accelerated: yes
Video memory: 938MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Broadcom
OpenGL renderer string: VC4 V3D 2.1
OpenGL version string: 2.1 Mesa 19.1.0-devel (git-f1122f78b7)
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_AMD_shader_trinary_minmax, GL_APPLE_packed_pixels, 
GL_ARB_ES2_compatibility, GL_ARB_buffer_storage, 
GL_ARB_clear_buffer_object, GL_ARB_color_buffer_float, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, 
GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, 
GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, 
GL_ARB_explicit_uniform_location, GL_ARB_fragment_coord_conventions, 
GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, 
GL_ARB_get_texture_sub_image, GL_ARB_half_float_pixel, 
GL_ARB_half_float_vertex, GL_ARB_internalformat_query, 
GL_ARB_internalformat_query2, GL_ARB_invalidate_subdata, 

Re: [Qemu-devel] [PATCH] SiFive RISC-V GPIO Device

[Palmer Dabbelt]

On Tue, 26 Mar 2019 10:49:11 PDT (-0700), chout...@adacore.com wrote:

Hi Palmer,

On 26/03/2019 09:58, Palmer Dabbelt wrote:

Do you have anything that actually glues this to a machine so I can test it?



In this patch I do instantiate the device in sifive_e machine.


OK, that's what I thought but I couldn't figure out how to actually talk to the 
device.  Hopefully it's just an issue on my end.

Re: [Qemu-devel] [PATCH V2 RFT] vhost_net: don't set backend for the uninitialized virtqueue

[Jason Wang]

On 2019/3/26 下午8:49, Michael S. Tsirkin wrote:

On Tue, Mar 26, 2019 at 02:59:19PM +0800, Jason Wang wrote:

On 2019/3/25 下午8:32, Michael S. Tsirkin wrote:

On Mon, Mar 25, 2019 at 11:56:13AM +0800, Jason Wang wrote:

We used to set backend unconditionally, this won't work for some
guests (e.g windows driver) who may not initialize all virtqueues. For
kernel backend, this will fail since it may try to validate the rings
during setting backend.

Fixing this by simply skipping the backend set when we find desc is
not ready.

Signed-off-by: Jason Wang
---
   hw/net/vhost_net.c | 15 +++
   1 file changed, 15 insertions(+)

diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index be3cc88370..04fd924d15 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -221,6 +221,7 @@ static int vhost_net_start_one(struct vhost_net *net,
  VirtIODevice *dev)
   {
   struct vhost_vring_file file = { };
+hwaddr a;
   int r;
   net->dev.nvqs = 2;
@@ -244,6 +245,13 @@ static int vhost_net_start_one(struct vhost_net *net,
   qemu_set_fd_handler(net->backend, NULL, NULL, NULL);
   file.fd = net->backend;
   for (file.index = 0; file.index < net->dev.nvqs; ++file.index) {
+a = virtio_queue_get_desc_addr(dev,
+   net->dev.vq_index +
+   file.index);
+if (a == 0) {
+/* Queue might not be ready for start */
+continue;
+}
   r = vhost_net_set_backend(>dev, );
   if (r < 0) {
   r = -errno;
@@ -256,6 +264,13 @@ fail:
   file.fd = -1;
   if (net->nc->info->type == NET_CLIENT_DRIVER_TAP) {
   while (file.index-- > 0) {
+a = virtio_queue_get_desc_addr(dev,
+   net->dev.vq_index +
+   file.index);
+if (a == 0) {
+/* Queue might not be ready for start */
+continue;
+}
   int r = vhost_net_set_backend(>dev, );
   assert(r >= 0);
   }

I think we want an API that explicitly says "queue is enabled".
For 0.X it will return !!addr. For 1.X it will return enabled.

For 1.x, desc.addr won't be set until queue_enabled is set through
virtio_queue_set_vrings(). And it looks to me ccw did something similar of
CMD_SET_VQ.

So we're ok actually?

Thanks


OK maybe but why can't we use an explicit API?
0.X can use addr != 0 trick since there's no queue_enabled.



If I understand correctly, you want something similar to what V1 did? A 
bus specific queue_enable() method.


Thanks

Re: [Qemu-devel] [PATCH] ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input device

[Chen Zhang via Qemu-devel]

> On Mar 27, 2019, at 12:20 AM, Peter Maydell  wrote:
> 
> On Thu, 21 Mar 2019 at 07:10, Chen Zhang  wrote:
>> 
>> In fullscreen mode, the window property of cocoaView may not be the key
>> window, and the current implementation would not grab mouse in
>> fullscreen mode after left clicks on relative input devices.
>> 
>> This patch used isFullscreen value as a short-cirtuit condition for
>> relative input device grabbing.
>> 
>> Note that this patch should be tested after applying a previous patch
>> which fixed event location conversion for relative input devices.
>> 
>> Signed-off-by: Chen Zhang 
> 
> Can you explain in more detail when this patch makes a
> difference, please? (for instance, a set of instructions
> for reproducing the issue).
> 

> I'm confused, because in the toggleFullScreen method, when
> we switch to full screen mode (which is the only place where
> we set isFullscreen to true) we always do a [self grabMouse].
> So if we get into the event handling function and isFullscreen
> is true, I think the mouse should already be grabbed. What
> am I missing ?
Hi,

In fullscreen mode, when the mouse is un-grabbed by pressing Cmd-Opt-g, it 
would not be re-grabbed by clicks in the view, as the window of the view would 
not be key window by then.

BTW, the Ctrl-Alt-Xs in ui/cocoa.m was confusing in the context. Should they be 
replaced by Cmd-Opt-Xs?
> 
> thanks
> -- PMM

Best Regards,

[Qemu-devel] [PATCH] migration: not necessary to check ops again

[Wei Yang]

During each iteration, se->ops is checked before each loop. So it is not
necessary to check it again and simplify the following check a little.

Signed-off-by: Wei Yang 
---
 migration/savevm.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 1415001d1c..5f0ca7fac2 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1157,15 +1157,13 @@ int qemu_savevm_state_iterate(QEMUFile *f, bool 
postcopy)
 if (!se->ops || !se->ops->save_live_iterate) {
 continue;
 }
-if (se->ops && se->ops->is_active) {
-if (!se->ops->is_active(se->opaque)) {
-continue;
-}
+if (se->ops->is_active &&
+!se->ops->is_active(se->opaque)) {
+continue;
 }
-if (se->ops && se->ops->is_active_iterate) {
-if (!se->ops->is_active_iterate(se->opaque)) {
-continue;
-}
+if (se->ops->is_active_iterate &&
+!se->ops->is_active_iterate(se->opaque)) {
+continue;
 }
 /*
  * In the postcopy phase, any device that doesn't know how to
-- 
2.19.1

Re: [Qemu-devel] [PATCH v2] ui/cocoa: Fix absolute input device grabbing issues on Mojave

[Chen Zhang via Qemu-devel]

> On Mar 27, 2019, at 12:15 AM, Peter Maydell  wrote:
> 
> On Tue, 19 Mar 2019 at 03:51, Chen Zhang  > wrote:
>> 
>> On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
>> the cursor in re-entry into the virtual screen area. In some cases,
>> the `window` property of NSEvent object is nil, after exit of cursor,
>> meaning that the `-locationInWindow` method would return value in screen
>> coordinates. Current implementation used raw locations from NSEvent
>> without considering whether the value was for the window coordinates or
>> the macOS screen coordinates, nor was the zooming factor for Zoom-to-Fit
>> included for fullscreen mode.
>> 
>> In fullscreen mode, the fullscreen cocoa window might not be the key
>> window, therefore location of event in virtual coordinates should suffice
>> for the condition of grabbing.
>> 
>> This patch fixed boundary check methods for cursor in normal and fullscreen
>> with/without Zoom-to-Fit on macOS Mojave.
>> 
>> Signed-off-by: Chen Zhang 
>> ---
>> ui/cocoa.m | 39 +--
>> 1 file changed, 37 insertions(+), 2 deletions(-)
>> 
> 
> Hi; this doesn't compile for me, I'm afraid. I've appended the full
> compiler error log, but the problem seems to be that
> the convertPointFromScreen method of NSWindow doesn't exist.
> I'm not entirely sure why, since the API docs say that method
> was introduced in OSX 10.12 and I'm running 10.13.6, but
> at least at the moment our minimum OSX version is 10.10,
> so we need something to handle that anyway.
Hi,

Just double-checked on a MacMini mid 2011 with macOS 10.13.6, Xcode 10.1. This 
NSWindow API did exist, and the patch could be built without error.
Searching convertPointFromScreen in Xcode.app’s platform SDK showed that it was 
defined at line 440 in NSWindow.h of AppKit.framework.

May I ask what build environment did you use (as printed by `xcode-select -p`)?
> 
> (http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html 
> 
> suggests that maybe the docs are wrong and this method
> was only added in 10.14; that would certainly fit the symptoms.)
> 
> 
> /Users/pm215/src/qemu/ui/cocoa.m:414:35: warning: instance method
> '-convertPointFromScreen:' not found
>  (return type defaults to 'id') [-Wobjc-method-access]
>return [[self window] convertPointFromScreen:[ev 
> locationInWindow]];
>  ^~
> /System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:191:12:
> note: receiver is instance of class declared here
> @interface NSWindow : NSResponder  NSUserInterfaceValidations, NSUserInterfaceItemIdenti...
>   ^
> /Users/pm215/src/qemu/ui/cocoa.m:414:20: error: returning 'id' from a
> function with incompatible result type 'CGPoint'
>  (aka 'struct CGPoint')
>return [[self window] convertPointFromScreen:[ev 
> locationInWindow]];
>   ^~~~
> /Users/pm215/src/qemu/ui/cocoa.m:416:61: warning: instance method
> '-convertPointFromScreen:' not found
>  (return type defaults to 'id') [-Wobjc-method-access]
>CGPoint loc = [self convertPoint:[[self window]
> convertPointFromScreen:[ev locationInWindow]] fromView:nil];
> 
> ^~
> /System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:191:12:
> note: receiver is instance of class declared here
> @interface NSWindow : NSResponder  NSUserInterfaceValidations, NSUserInterfaceItemIdenti...
>   ^
> /Users/pm215/src/qemu/ui/cocoa.m:416:46: error: sending 'id' to
> parameter of incompatible type 'NSPoint' (aka 'struct CGPoint')
>CGPoint loc = [self convertPoint:[[self window]
> convertPointFromScreen:[ev locationInWindow]] fromView:nil];
> 
> ^~~~
> /System/Library/Frameworks/AppKit.framework/Headers/NSView.h:196:34:
> note: passing argument to parameter 'point' here
> - (NSPoint)convertPoint:(NSPoint)point fromView:(nullable NSView *)view;
> ^
> /Users/pm215/src/qemu/ui/cocoa.m:435:67: warning: instance method
> '-convertPointToScreen:' not found
>  (return type defaults to 'id') [-Wobjc-method-access]
>return [[self window] convertPointFromScreen:[eventWindow
> convertPointToScreen:[ev locationInWindow]]];
> 
> ^~~~
> /System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:191:12:
> note: receiver is instance of class declared here
> @interface NSWindow : NSResponder  NSUserInterfaceValidations, NSUserInterfaceItemIdenti...
>   ^
> /Users/pm215/src/qemu/ui/cocoa.m:435:31: warning: instance method
> '-convertPointFromScreen:' not found
>  (return type defaults to 'id') [-Wobjc-method-access]
>return [[self window] convertPointFromScreen:[eventWindow
> convertPointToScreen:[ev 

Re: [Qemu-devel] [PATCH for 4.0 v1 1/1] MAINTAINERS: Update the device tree maintainers

[Alexander Graf]

> Am 27.03.2019 um 03:59 schrieb Alistair Francis :
> 
> Remove Alex as a Device Tree maintainer as requested by him. Add myself
> as a maintainer to avoid it being orphaned. Also add David as a
> Reviewer (R) as he is the libfdt and DTC maintainer.
> 
> Signed-off-by: Alistair Francis 

Reviewed-by: Alexander Graf 

Alex

> ---
> MAINTAINERS | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 85d7d764e5..c2ad5062f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1813,7 +1813,8 @@ F: qom/cpu.c
> F: include/qom/cpu.h
> 
> Device Tree
> -M: Alexander Graf 
> +M: Alistair Francis 
> +R: David Gibson 
> S: Maintained
> F: device_tree.c
> F: include/sysemu/device_tree.h
> -- 
> 2.21.0
> 

Re: [Qemu-devel] [PATCH] migration: avoid copying ignore-shared ramblock when in incoming migration

[Catherine Ho]

Hi all, thanks for the comments, I am digging into another potential
error in the
ignore-shared live migration. After that, I will send out the v2 asap
B.R.
Catherine


On Mon, 25 Mar 2019 at 11:39, Peter Xu  wrote:
>
> On Fri, Mar 22, 2019 at 10:12:11AM +, Dr. David Alan Gilbert wrote:
>
> [...]
>
> > > In general, when we reset the system, we want to bring it
> > > back to exactly the state that it was in when QEMU was
> > > first started. That means we need to reload all the rom blob
> > > data into memory (because the guest might have modified
> > > that memory while it was running).
> > >
> > > If I understand correctly from other threads, the idea is
> > > that some of the RAM is shared between source and destination
> > > so it does not need to be manually copied during migration.
> > > If that is correct, then perhaps the right thing is that
> > > in the rom_reset code:
> > >  * if this rom blob is being loaded into a "shared" ram block
> > >  * and this reset is happening specifically before an
> > >inbound migration
> > >  * then skip loading the rom blob data
> > >
> > > ?
> > >
> > > I don't know the right way to determine either the "is this
> > > a shared ram area" or "is this the reset prior to inbound
> > > migration", but perhaps you can fill that in.
> >
> > Right, so in Catherine's patch there's a simple in_incoming_migration
> > and checking ramblock_is_ignored;  it might be better to use the
> > qemu_ram_is_shared() call and I wonder if we can just check for being in
> > RUN_STATE_INMIGRATE - if that's early enough.
>
> Yes I feel like runstate_check(RUN_STATE_INMIGRATE) should be enough
> to replace the new variable.  And I'm even thinking whether we need to
> check qemu_ram_is_shared() at all... if rom_reset() simply refills the
> ROM data into the RAMs, then IIUC that operation could be skipped for
> all incoming migrations because all those ROM data (no matter they are
> filled into shared RAM or not) should already have been filled on the
> source side and:
>
> - if the ROM data's RAMBlock is shared backend, the latest data should
>   already been there on the shared backend files, or,
>
> - if the ROM data's RAMBlock is not shared backend, they'll eventually
>   be migrated to the destination later on after this rom_reset() on
>   destination by the general RAM migration code.
>
> Regards,
>
> --
> Peter Xu

Re: [Qemu-devel] [Qemu-block] [PATCH] vmdk: Set vmdk parent backing_format to vmdk

[Eric Blake]

On 3/26/19 2:58 PM, Sam Eiderman wrote:
> Commit fb2105b ("vmdk: Support version=3 in VMDK descriptor files") fixed
> the probe function to correctly guess vmdk descriptors with version=3.

All patches need to cc qemu-devel in addition to their maintainers (I've
added that now).

> 
> This solves the issue where vmdk snapshot with parent vmdk descriptor
> containing "version=3" would be treated as raw instead vmdk.
> 
> In the future case where a new vmdk version is introduced, we will again
> experience this issue, even if the user will provide "-f vmdk" it will
> only apply to the tip image and not to the underlying "misprobed" parent
> image.
> 
> The code in vmdk.c already assumes that the backing file of vmdk must be
> vmdk (see vmdk_is_cid_valid which returns 0 if backing file is not
> vmdk).
> 
> So let's make it official by supplying the backing_format as vmdk.
> 
> Reviewed-by: Mark Kanda 
> Reviewed-By: Liran Alon 
> Reviewed-by: Arbel Moshe 
> Signed-off-by: Shmuel Eiderman 
> ---
>  block/vmdk.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/block/vmdk.c b/block/vmdk.c
> index 8dec6ef767..de8cb859f8 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -397,6 +397,8 @@ static int vmdk_parent_open(BlockDriverState *bs)
>  pstrcpy(bs->auto_backing_file, end_name - p_name + 1, p_name);
>  pstrcpy(bs->backing_file, sizeof(bs->backing_file),
>  bs->auto_backing_file);
> +pstrcpy(bs->backing_format, sizeof(bs->backing_format),
> +"vmdk");
>  }

Reviewed-by: Eric Blake 

Makes sense for 4.0-rc2.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH for 4.0 v1 5/5] riscv: plic: Log guest errors

[Philippe Mathieu-Daudé]

Le jeu. 21 mars 2019 02:00, Alistair Francis  a
écrit :

> Instead of using error_report() to print guest errors let's use
> qemu_log_mask(LOG_GUEST_ERROR,...) to log the error.
>
> Signed-off-by: Alistair Francis 
> ---
>  hw/riscv/sifive_plic.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
> index 70a85cd075..7f373d6c9d 100644
> --- a/hw/riscv/sifive_plic.c
> +++ b/hw/riscv/sifive_plic.c
> @@ -262,7 +262,9 @@ static uint64_t sifive_plic_read(void *opaque, hwaddr
> addr, unsigned size)
>  }
>
>  err:
> -error_report("plic: invalid register read: %08x", (uint32_t)addr);
> +qemu_log_mask(LOG_GUEST_ERROR,
> +  "%s: Invalid register read 0x%" HWADDR_PRIx "\n",
> +  __func__, addr);
>  return 0;
>  }
>
> @@ -289,7 +291,9 @@ static void sifive_plic_write(void *opaque, hwaddr
> addr, uint64_t value,
>  } else if (addr >= plic->pending_base && /* 1 bit per source */
> addr < plic->pending_base + (plic->num_sources >> 3))
>  {
> -error_report("plic: invalid pending write: %08x", (uint32_t)addr);
> +qemu_log_mask(LOG_GUEST_ERROR,
> +  "%s: invalid pending write: 0x%" HWADDR_PRIx "",
> +  __func__, addr);
>  return;
>  } else if (addr >= plic->enable_base && /* 1 bit per source */
>  addr < plic->enable_base + plic->num_addrs * plic->enable_stride)
> @@ -339,7 +343,9 @@ static void sifive_plic_write(void *opaque, hwaddr
> addr, uint64_t value,
>  }
>
>  err:
> -error_report("plic: invalid register write: %08x", (uint32_t)addr);
> +qemu_log_mask(LOG_GUEST_ERROR,
> +  "%s: Invalid register write 0x%" HWADDR_PRIx "\n",
> +  __func__, addr);
>  }
>
>  static const MemoryRegionOps sifive_plic_ops = {
> --
> 2.21.0
>

Reviewed-by: Philippe Mathieu-Daudé 

>

[Qemu-devel] [PATCH] intel_iommu: Correct caching-mode error message

[Alex Williamson]

If we try to use the intel-iommu device with vfio-pci devices without
caching mode enabled, we're told:

  qemu-system-x86_64: We need to set caching-mode=1 for intel-iommu to enable
  device assignment with IOMMU protection.

But to enable caching mode, the option is actually "caching-mode=on".

Signed-off-by: Alex Williamson 
---
 hw/i386/intel_iommu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index b90de6c66461..b62badd4f08d 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2919,7 +2919,7 @@ static void 
vtd_iommu_notify_flag_changed(IOMMUMemoryRegion *iommu,
 IntelIOMMUState *s = vtd_as->iommu_state;
 
 if (!s->caching_mode && new & IOMMU_NOTIFIER_MAP) {
-error_report("We need to set caching-mode=1 for intel-iommu to enable "
+error_report("We need to set caching-mode=on for intel-iommu to enable 
"
  "device assignment with IOMMU protection.");
 exit(1);
 }

[Qemu-devel] [RFC PATCH] pci: Use PCI aliases when determining device IOMMU address space

[Alex Williamson]

Conventional PCI buses pre-date requester IDs.  An IOMMU cannot
distinguish by devfn & bus between devices in a conventional PCI
topology and therefore we cannot assign them separate AddressSpaces.
By taking this requester ID aliasing into account, QEMU better matches
the bare metal behavior and restrictions, and enables shared
AddressSpace configurations that are otherwise not possible with
guest IOMMU support.

For the latter case, given any example where an IOMMU group on the
host includes multiple devices:

  $ ls  /sys/kernel/iommu_groups/1/devices/
  :00:01.0  :01:00.0  :01:00.1

If we incorporate a vIOMMU into the VM configuration, we're restricted
that we can only assign one of the endpoints to the guest because a
second endpoint will attempt to use a different AddressSpace.  VFIO
only supports IOMMU group level granularity at the container level,
preventing this second endpoint from being assigned:

qemu-system-x86_64 -machine q35... \
  -device intel-iommu,intremap=on \
  -device pcie-root-port,addr=1e.0,id=pcie.1 \
  -device vfio-pci,host=1:00.0,bus=pcie.1,addr=0.0,multifunction=on \
  -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1

qemu-system-x86_64: -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1: vfio \
:01:00.1: group 1 used in multiple address spaces

However, when QEMU incorporates proper aliasing, we can make use of a
PCIe-to-PCI bridge to mask the requester ID, resulting in a hack that
provides the downstream devices with the same AddressSpace, ex:

qemu-system-x86_64 -machine q35... \
  -device intel-iommu,intremap=on \
  -device pcie-pci-bridge,addr=1e.0,id=pci.1 \
  -device vfio-pci,host=1:00.0,bus=pci.1,addr=1.0,multifunction=on \
  -device vfio-pci,host=1:00.1,bus=pci.1,addr=1.1

While the utility of this hack may be limited, this AddressSpace
aliasing is the correct behavior for QEMU to emulate bare metal.

Signed-off-by: Alex Williamson 
---
 hw/pci/pci.c |   33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 35451c1e9987..38467e676f1f 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2594,12 +2594,41 @@ AddressSpace *pci_device_iommu_address_space(PCIDevice 
*dev)
 {
 PCIBus *bus = pci_get_bus(dev);
 PCIBus *iommu_bus = bus;
+uint8_t devfn = dev->devfn;
 
 while(iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
-iommu_bus = pci_get_bus(iommu_bus->parent_dev);
+PCIBus *parent_bus = pci_get_bus(iommu_bus->parent_dev);
+
+/*
+ * Determine which requester ID alias should be used for the device
+ * based on the PCI topology.  There are no requester IDs on 
convetional
+ * PCI buses, therefore we push the alias up to the parent on each non-
+ * express bus.  Which alias we use depends on whether this is a legacy
+ * PCI bridge or PCIe-to-PCI/X bridge as in chapter 2.3 of the PCIe-to-
+ * PCI bridge spec.  Note that we cannot use pci_requester_id() here
+ * because the resulting BDF depends on the secondary bridge register
+ * programming.  We also cannot lookup the PCIBus from the bus number
+ * at this point for the iommu_fn.  Also, requester_id_cache is the
+ * alias to the root bus, which is usually, but not necessarily always
+ * where we'll find our iommu_fn.
+ */
+if (!pci_bus_is_express(iommu_bus)) {
+PCIDevice *parent = iommu_bus->parent_dev;
+
+if (pci_is_express(parent) &&
+pcie_cap_get_type(parent) == PCI_EXP_TYPE_PCI_BRIDGE) {
+devfn = PCI_DEVFN(0, 0);
+bus = iommu_bus;
+} else {
+devfn = parent->devfn;
+bus = parent_bus;
+}
+}
+
+iommu_bus = parent_bus;
 }
 if (iommu_bus && iommu_bus->iommu_fn) {
-return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, dev->devfn);
+return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, devfn);
 }
 return _space_memory;
 }

Re: [Qemu-devel] [PATCH for 4.0 v1 0/5] Update the QEMU PLIC addresses

[Alistair Francis]

On Wed, Mar 20, 2019 at 5:45 PM Alistair Francis
 wrote:
>
> This series updates the PLIC address to match the documentation.
>
> This fixes: https://github.com/riscv/opensbi/issues/97
>
> Alistair Francis (5):
>   riscv: plic: Fix incorrect irq calculation
>   riscv: sifive_u: Fix PLIC priority base offset and numbering
>   riscv: sifive_e: Fix PLIC priority base offset
>   riscv: virt: Fix PLIC priority base offset
>   riscv: plic: Log guest errors

Ping! Can this make it into 4.0?

Alistair

>
>  hw/riscv/sifive_plic.c  | 16 +++-
>  hw/riscv/sifive_u.c |  2 +-
>  include/hw/riscv/sifive_e.h |  2 +-
>  include/hw/riscv/sifive_u.h |  4 ++--
>  include/hw/riscv/virt.h |  2 +-
>  5 files changed, 16 insertions(+), 10 deletions(-)
>
> --
> 2.21.0
>

Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

[Philippe Mathieu-Daudé]

Le mar. 26 mars 2019 15:34, Jag Raman  a écrit :

>
>
> On 3/26/2019 4:08 AM, Stefan Hajnoczi wrote:
> > On Fri, Mar 08, 2019 at 09:50:36AM +, Stefan Hajnoczi wrote:
> >> On Thu, Mar 07, 2019 at 03:29:41PM -0800, John G Johnson wrote:
>  On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi 
> wrote:
>  On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote:
> > On Thu, Mar 07, 2019 at 02:26:09PM +, Stefan Hajnoczi wrote:
> >> On Wed, Mar 06, 2019 at 11:22:53PM -0800,
> elena.ufimts...@oracle.com wrote:
> >>> diff --git a/docs/devel/qemu-multiprocess.txt
> b/docs/devel/qemu-multiprocess.txt
> >>> new file mode 100644
> >>> index 000..e29c6c8
> >>> --- /dev/null
> >>> +++ b/docs/devel/qemu-multiprocess.txt
> >>
> >> Thanks for this document and the interesting work that you are
> doing.
> >> I'd like to discuss the security advantages gained by disaggregating
> >> QEMU in more detail.
> >>
> >> The security model for VMs managed by libvirt (most production x86,
> ppc,
> >> s390 guests) is that the QEMU process is untrusted and only has
> access
> >> to resources belonging to the guest.  SELinux is used to restrict
> the
> >> process from accessing other files, processes, etc on the host.
> >
> > NB it doesn't have to be SELinux. Libvirt also supports AppArmor and
> > can even do isolation with traditional DAC by putting each QEMU under
> > a distinct UID/GID and having libvirtd set ownership on resources
> each
> > VM is permitted to use.
> >
> >> QEMU does not hold privileged resources that must be kept away from
> the
> >> guest.  An escaped guest can access its image file, tap file
> descriptor,
> >> etc but they are the same resources it could already access via
> device
> >> emulation.
> >>
> >> Can you give specific examples of how disaggregation improves
> security?
> 
>  Elena & collaborators: Dan has posted some ideas but please share
> yours
>  so the security benefits of this patch series can be better
> understood.
> 
> >>>
> >>> Dan covered the main point.  The security regime we use (selinux)
> >>> constrains the actions of processes on objects, so having multiple
> processes
> >>> allows us to apply more fine-grained policies.
> >>
> >> Please share the SELinux policy files, containerization scripts, etc.
> >> There is probably a home for them in qemu.git, libvirt.git, or elsewhere
> >> upstream.
> >>
> >> We need to find a way to make the sandboxing improvements available to
> >> users besides yourself and easily reusable for developers who wish to
> >> convert additional device models.
>

Also for testing this series.

>
> > Ping?
> >
> > Without the scripts/policies there is no security benefit from this
> > patch series.
>
> Hi Stefan,
>
> We are working on this. We'll get back to you once we have this
> available.
>
> Thanks!
> --
> Jag
>
> >
> > Stefan
> >
>
>

Re: [Qemu-devel] [PATCH V2] RISC-V: fix single stepping over ret and other branching instructions

[Alistair Francis]

On Mon, Mar 25, 2019 at 9:59 AM Richard Henderson
 wrote:
>
> On 3/25/19 4:45 AM, Fabien Chouteau wrote:
> > This patch introduces wrappers around the tcg_gen_exit_tb() and
> > tcg_gen_lookup_and_goto_ptr() functions that handle single stepping,
> > i.e. call gen_exception_debug() when single stepping is enabled.
> >
> > Theses functions are then used instead of the originals, bringing single
> > stepping handling in places where it was previously ignored such as jalr
> > and system branch instructions (ecall, mret, sret, etc.).
> >
> > Signed-off-by: Fabien Chouteau 
> > ---
> >  .../riscv/insn_trans/trans_privileged.inc.c   |  8 ++---
> >  target/riscv/insn_trans/trans_rvi.inc.c   |  6 ++--
> >  target/riscv/translate.c  | 30 +++
> >  3 files changed, 32 insertions(+), 12 deletions(-)
>
> Reviewed-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

>
>
> r~
>

Re: [Qemu-devel] [PATCH for 4.0 v1 1/1] MAINTAINERS: Update the device tree maintainers

[Philippe Mathieu-Daudé]

Le mar. 26 mars 2019 21:59, Alistair Francis  a
écrit :

> Remove Alex as a Device Tree maintainer as requested by him. Add myself
> as a maintainer to avoid it being orphaned. Also add David as a
> Reviewer (R) as he is the libfdt and DTC maintainer.
>
> Signed-off-by: Alistair Francis 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 85d7d764e5..c2ad5062f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1813,7 +1813,8 @@ F: qom/cpu.c
>  F: include/qom/cpu.h
>
>  Device Tree
> -M: Alexander Graf 
> +M: Alistair Francis 
> +R: David Gibson 
>  S: Maintained
>  F: device_tree.c
>  F: include/sysemu/device_tree.h
> --
> 2.21.0
>

Reviewed-by: Philippe Mathieu-Daudé 

>

[Qemu-devel] [PATCH v3 1/3] block: introducing 'bdrv_co_delete_file' interface

[Daniel Henrique Barboza]

Adding to Block Drivers the capability of being able to clean up
its created files can be useful in certain situations. For the
LUKS driver, for instance, a failure in one of its authentication
steps can leave files in the host that weren't there before.

This patch adds the 'bdrv_co_delete_file' interface to block
drivers and add it to the 'file' driver in file-posix.c. The
implementation is given by 'raw_co_delete_file'. The helper
'bdrv_path_is_regular_file' is being used only in raw_co_delete_file
at this moment, but it will be used inside LUKS in a later patch.
Foreseeing this future use, let's put it in block.c and make it
public.

Suggested-by: Daniel P. Berrangé 
Signed-off-by: Daniel Henrique Barboza 
---
 block.c   | 11 +++
 block/file-posix.c| 28 
 include/block/block.h |  1 +
 include/block/block_int.h |  6 ++
 4 files changed, 46 insertions(+)

diff --git a/block.c b/block.c
index 0a93ee9ac8..227362b282 100644
--- a/block.c
+++ b/block.c
@@ -621,6 +621,17 @@ int get_tmp_filename(char *filename, int size)
 #endif
 }
 
+/**
+ * Helper that checks if a given string represents a regular
+ * local file.
+ */
+bool bdrv_path_is_regular_file(const char *path)
+{
+struct stat st;
+
+return (stat(path, ) == 0) && S_ISREG(st.st_mode);
+}
+
 /*
  * Detect host devices. By convention, /dev/cdrom[N] is always
  * recognized as a host CDROM.
diff --git a/block/file-posix.c b/block/file-posix.c
index d102f3b222..09d84bab37 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -2342,6 +2342,33 @@ static int coroutine_fn raw_co_create_opts(const char 
*filename, QemuOpts *opts,
 return raw_co_create(, errp);
 }
 
+/**
+ * Co-routine function that erases a regular file.
+ */
+static int coroutine_fn raw_co_delete_file(const char *filename,
+   Error **errp)
+{
+int ret;
+
+/* Skip file: protocol prefix */
+strstart(filename, "file:", );
+
+if (!bdrv_path_is_regular_file(filename)) {
+ret = -ENOENT;
+error_setg_errno(errp, -ret, "%s is not a regular file", filename);
+goto done;
+}
+
+ret = unlink(filename);
+if (ret < 0) {
+ret = -errno;
+error_setg_errno(errp, -ret, "Error when deleting file %s", filename);
+}
+
+done:
+return ret;
+}
+
 /*
  * Find allocation range in @bs around offset @start.
  * May change underlying file descriptor's file offset.
@@ -2867,6 +2894,7 @@ BlockDriver bdrv_file = {
 .bdrv_co_block_status = raw_co_block_status,
 .bdrv_co_invalidate_cache = raw_co_invalidate_cache,
 .bdrv_co_pwrite_zeroes = raw_co_pwrite_zeroes,
+.bdrv_co_delete_file = raw_co_delete_file,
 
 .bdrv_co_preadv = raw_co_preadv,
 .bdrv_co_pwritev= raw_co_pwritev,
diff --git a/include/block/block.h b/include/block/block.h
index e452988b66..820643f96d 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -363,6 +363,7 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
BlockDriverState *base,
   Error **errp);
 void bdrv_unfreeze_backing_chain(BlockDriverState *bs, BlockDriverState *base);
 
+bool bdrv_path_is_regular_file(const char *path);
 
 typedef struct BdrvCheckResult {
 int corruptions;
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 01e855a066..74abb78ce7 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -309,6 +309,12 @@ struct BlockDriver {
  */
 int coroutine_fn (*bdrv_co_flush)(BlockDriverState *bs);
 
+/*
+ * Delete a local created file.
+ */
+int coroutine_fn (*bdrv_co_delete_file)(const char *filename,
+Error **errp);
+
 /*
  * Flushes all data that was already written to the OS all the way down to
  * the disk (for example file-posix.c calls fsync()).
-- 
2.20.1

[Qemu-devel] [PATCH v3 0/3] delete created files when block_crypto_co_create_opts_luks fails

[Daniel Henrique Barboza]

In this new interation, the following changes were made from
the previous version [1]:
- moved the 'generic' code from block.c to file-posix.c
- moved the file delete call from qemu_img to the error path
of block_crypto_co_create_opts_luks

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06444.html


Daniel Henrique Barboza (3):
  block: introducing 'bdrv_co_delete_file' interface
  block.c: adding bdrv_delete_file
  crypto.c: cleanup created file when block_crypto_co_create_opts_luks
fails

 block.c   | 82 +++
 block/crypto.c| 31 +++
 block/file-posix.c| 28 +
 include/block/block.h |  3 ++
 include/block/block_int.h |  6 +++
 5 files changed, 150 insertions(+)

-- 
2.20.1

[Qemu-devel] [PATCH v3 3/3] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails

[Daniel Henrique Barboza]

When using a non-UTF8 secret to create a volume using qemu-img, the
following error happens:

$ qemu-img create -f luks --object 
secret,id=vol_1_encrypt0,file=vol_resize_pool.vol_1.secret.qzVQrI -o 
key-secret=vol_1_encrypt0 /var/tmp/pool_target/vol_1 10240K

Formatting '/var/tmp/pool_target/vol_1', fmt=luks size=10485760 
key-secret=vol_1_encrypt0
qemu-img: /var/tmp/pool_target/vol_1: Data from secret vol_1_encrypt0 is not 
valid UTF-8

However, the created file /var/tmp/pool_target/vol_1 is left behind in the
file system after the failure. This behavior can be observed when creating
the volume using Libvirt, via 'virsh vol-create', and then getting "volume
target path already exist" errors when trying to re-create the volume.

The volume file is created inside block_crypto_co_create_opts_luks, in
block/crypto.c. If the bdrv_create_file() call is successful but any
succeeding step fails*, the existing 'fail' label does not take into
account the created file, leaving it behind.

This patch changes block_crypto_co_create_opts_luks to check if @filename
is an existing file before bdrv_create_file is called. In case of failure,
if @filename didn't exist before, check again for its existence and,
if affirmative, erase it by calling bdrv_delete_file.

* in our case, block_crypto_co_create_generic calls qcrypto_block_create,
which calls qcrypto_block_luks_create, and this function fails when
calling qcrypto_secret_lookup_as_utf8.

Reported-by: Srikanth Aithal 
Suggested-by: Kevin Wolf 
Signed-off-by: Daniel Henrique Barboza 
---
 block/crypto.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/block/crypto.c b/block/crypto.c
index 3af46b805f..7c1b80616c 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -29,6 +29,7 @@
 #include "qapi/qobject-input-visitor.h"
 #include "qapi/error.h"
 #include "qemu/option.h"
+#include "qemu/cutils.h"
 #include "crypto.h"
 
 typedef struct BlockCrypto BlockCrypto;
@@ -533,6 +534,8 @@ static int coroutine_fn 
block_crypto_co_create_opts_luks(const char *filename,
 BlockDriverState *bs = NULL;
 QDict *cryptoopts;
 int64_t size;
+const char *path;
+bool file_already_existed = false;
 int ret;
 
 /* Parse options */
@@ -549,6 +552,15 @@ static int coroutine_fn 
block_crypto_co_create_opts_luks(const char *filename,
 goto fail;
 }
 
+/*
+ * Check if 'filename' represents a local file that already
+ * exists in the file system prior to bdrv_create_file. Strip
+ * the leading 'file:' from the filename if it exists.
+ */
+path = filename;
+strstart(path, "file:", );
+file_already_existed = bdrv_path_is_regular_file(path);
+
 /* Create protocol layer */
 ret = bdrv_create_file(filename, opts, errp);
 if (ret < 0) {
@@ -573,6 +585,25 @@ fail:
 bdrv_unref(bs);
 qapi_free_QCryptoBlockCreateOptions(create_opts);
 qobject_unref(cryptoopts);
+
+/*
+ * If an error occurred and we ended up creating a bogus
+ * 'filename' file, delete it
+ */
+if (ret && !file_already_existed && bdrv_path_is_regular_file(path)) {
+Error *local_err;
+int r_del = bdrv_delete_file(path, _err);
+/*
+ * ENOTSUP will happen if the block driver doesn't support
+ * 'bdrv_co_delete_file'. ENOENT will happen if the file
+ * doesn't exist. Both are predictable and shouldn't be
+ * reported back to the user.
+ */
+if ((r_del < 0) && (r_del != -ENOTSUP) && (r_del != -ENOENT)) {
+error_reportf_err(local_err, "%s: ", path);
+}
+}
+
 return ret;
 }
 
-- 
2.20.1

[Qemu-devel] [PATCH v3 2/3] block.c: adding bdrv_delete_file

[Daniel Henrique Barboza]

Using the new 'bdrv_co_delete_file' interface, bdrv_delete_file
can be used in a way similar of the existing bdrv_create_file to
to clean up a created file.

The logic is also similar to what is already done in bdrv_create_file:
a qemu_coroutine is created if needed, a specialized function
bdrv_delete_co_entry is used to call the bdrv_co_delete_file
co-routine of the driver, if the driver implements it.

Suggested-by: Daniel P. Berrangé 
Signed-off-by: Daniel Henrique Barboza 
---
 block.c   | 71 +++
 include/block/block.h |  2 ++
 2 files changed, 73 insertions(+)

diff --git a/block.c b/block.c
index 227362b282..4eb9d27863 100644
--- a/block.c
+++ b/block.c
@@ -547,6 +547,77 @@ int bdrv_create_file(const char *filename, QemuOpts *opts, 
Error **errp)
 return ret;
 }
 
+static void coroutine_fn bdrv_delete_co_entry(void *opaque)
+{
+Error *local_err = NULL;
+int ret;
+
+CreateCo *cco = opaque;
+assert(cco->drv);
+
+ret = cco->drv->bdrv_co_delete_file(cco->filename, _err);
+error_propagate(>err, local_err);
+cco->ret = ret;
+}
+
+int bdrv_delete_file(const char *filename, Error **errp)
+{
+
+BlockDriver *drv = bdrv_find_protocol(filename, true, errp);
+CreateCo cco = {
+.drv = drv,
+.filename = g_strdup(filename),
+.ret = NOT_DONE,
+.err = NULL,
+};
+Coroutine *co;
+int ret;
+
+if (!drv) {
+error_setg(errp, "File '%s' has unknown format", filename);
+ret = -ENOENT;
+goto out;
+}
+
+if (!drv->bdrv_co_delete_file) {
+error_setg(errp, "Driver '%s' does not support image delete",
+   drv->format_name);
+ret = -ENOTSUP;
+goto out;
+}
+
+if (!drv->bdrv_co_delete_file) {
+error_setg(errp, "Driver '%s' does not support image delete",
+   drv->format_name);
+ret = -ENOTSUP;
+goto out;
+}
+
+if (qemu_in_coroutine()) {
+/* Fast-path if already in coroutine context */
+bdrv_delete_co_entry();
+} else {
+co = qemu_coroutine_create(bdrv_delete_co_entry, );
+qemu_coroutine_enter(co);
+while (cco.ret == NOT_DONE) {
+aio_poll(qemu_get_aio_context(), true);
+}
+}
+
+ret = cco.ret;
+if (ret < 0) {
+if (cco.err) {
+error_propagate(errp, cco.err);
+} else {
+error_setg_errno(errp, -ret, "Could not delete image");
+}
+}
+
+out:
+g_free(cco.filename);
+return ret;
+}
+
 /**
  * Try to get @bs's logical and physical block size.
  * On success, store them in @bsz struct and return 0.
diff --git a/include/block/block.h b/include/block/block.h
index 820643f96d..76901a63de 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -364,6 +364,8 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
BlockDriverState *base,
 void bdrv_unfreeze_backing_chain(BlockDriverState *bs, BlockDriverState *base);
 
 bool bdrv_path_is_regular_file(const char *path);
+int bdrv_delete_file(const char *filename, Error **errp);
+
 
 typedef struct BdrvCheckResult {
 int corruptions;
-- 
2.20.1

[Qemu-devel] [PATCH for 4.0 v1 1/1] MAINTAINERS: Update the device tree maintainers

[Alistair Francis]

Remove Alex as a Device Tree maintainer as requested by him. Add myself
as a maintainer to avoid it being orphaned. Also add David as a
Reviewer (R) as he is the libfdt and DTC maintainer.

Signed-off-by: Alistair Francis 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 85d7d764e5..c2ad5062f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1813,7 +1813,8 @@ F: qom/cpu.c
 F: include/qom/cpu.h
 
 Device Tree
-M: Alexander Graf 
+M: Alistair Francis 
+R: David Gibson 
 S: Maintained
 F: device_tree.c
 F: include/sysemu/device_tree.h
-- 
2.21.0

Re: [Qemu-devel] [PATCH] MAINTAINERS: DT: Remove myself and degrade

[Alistair Francis]

On Sat, Mar 23, 2019 at 6:29 PM David Gibson
 wrote:
>
> On Sat, Mar 23, 2019 at 11:20:39AM +0100, Philippe Mathieu-Daudé wrote:
> > Le sam. 23 mars 2019 07:50, Alistair Francis  a
> > écrit :
> >
> > > On Thu, Mar 21, 2019 at 11:49 PM Peter Maydell 
> > > wrote:
> > > >
> > > > Alex and I just noticed that we didn't pick up this
> > > > MAINTAINERS patch for the "Device Tree" section.
> > > > In the interim Peter Crosthwaite has also removed himself
> > > > from maintainership, so by default this will move into
> > > > the "Orphan" state. Is anybody interested in taking up
> > > > the maintainership role here? In practice it doesn't really
> > > > need much care as mostly it's dealt with by the people
> > > > who maintain the boards that use the dtb utility code
> > > > (currently arm, ppc, riscv) and there's not much change
> > > > in this area.
> > >
> > > I am happy to take this over. I have a fair bit of experience with
> > > device trees so it should be straight forward.
> > >
> >
> > I'm glad you step in for this :) I was thinking about volunteering
> > you ;)
>
> If you want, you can add me as a reviewer (R:).  I don't actually work
> that much with the generic dev tree code in qemu, but as libfdt
> maintainer I have some perspective on it.

Thanks David, I'll add you as a reviewer.

Alistair

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

Re: [Qemu-devel] [PATCH 06/35] cpu: Replace ENV_GET_CPU with env_cpu

[Alistair Francis]

On Sat, Mar 23, 2019 at 12:52 PM Richard Henderson
 wrote:
>
> Now that we have both ArchCPU and CPUArchState, we can define
> this generically instead of via macro in each target's cpu.h.
>
> Signed-off-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  accel/tcg/atomic_template.h   |  8 ++--
>  accel/tcg/softmmu_template.h  | 20 +-
>  include/exec/cpu-all.h| 12 ++
>  include/exec/cpu_ldst_template.h  |  6 +--
>  include/exec/cpu_ldst_useronly_template.h |  6 +--
>  include/exec/softmmu-semi.h   | 16 
>  linux-user/cpu_loop-common.h  |  2 +-
>  target/alpha/cpu.h|  2 -
>  target/arm/cpu.h  |  2 -
>  target/cris/cpu.h |  2 -
>  target/hppa/cpu.h |  1 -
>  target/i386/cpu.h |  2 -
>  target/lm32/cpu.h |  2 -
>  target/m68k/cpu.h |  2 -
>  target/microblaze/cpu.h   |  2 -
>  target/mips/cpu.h |  2 -
>  target/moxie/cpu.h|  2 -
>  target/nios2/cpu.h|  2 -
>  target/openrisc/cpu.h |  2 -
>  target/ppc/cpu.h  |  2 -
>  target/riscv/cpu.h|  1 -
>  target/s390x/cpu.h|  2 -
>  target/sh4/cpu.h  |  2 -
>  target/sparc/cpu.h|  2 -
>  target/tilegx/cpu.h   |  2 -
>  target/tricore/cpu.h  |  2 -
>  target/unicore32/cpu.h|  2 -
>  target/xtensa/cpu.h   |  2 -
>  accel/tcg/cputlb.c| 22 +--
>  accel/tcg/tcg-runtime.c   |  4 +-
>  accel/tcg/translate-all.c |  2 +-
>  accel/tcg/user-exec.c |  2 +-
>  bsd-user/syscall.c|  6 +--
>  linux-user/arm/cpu_loop.c |  2 +-
>  linux-user/cris/cpu_loop.c|  2 +-
>  linux-user/elfload.c  |  6 +--
>  linux-user/m68k/cpu_loop.c|  2 +-
>  linux-user/main.c |  2 +-
>  linux-user/mips/cpu_loop.c|  2 +-
>  linux-user/nios2/cpu_loop.c   |  2 +-
>  linux-user/riscv/cpu_loop.c   |  2 +-
>  linux-user/signal.c   |  8 ++--
>  linux-user/syscall.c  | 18 -
>  linux-user/uname.c|  2 +-
>  target/arm/helper.c   | 42 ++--
>  target/hppa/op_helper.c   |  2 +-
>  target/i386/hax-all.c |  6 +--
>  target/i386/hvf/x86_decode.c  | 22 +--
>  target/i386/hvf/x86_emu.c | 48 +++
>  target/i386/mem_helper.c  |  4 +-
>  target/m68k/op_helper.c   |  2 +-
>  target/nios2/mmu.c|  4 +-
>  target/nios2/op_helper.c  |  2 +-
>  target/ppc/mmu_helper.c   |  2 +-
>  target/s390x/gdbstub.c| 24 ++--
>  target/s390x/mem_helper.c |  2 +-
>  target/sh4/op_helper.c|  2 +-
>  docs/devel/tracing.txt|  4 +-
>  scripts/tracetool/format/tcg_helper_c.py  |  2 +-
>  59 files changed, 167 insertions(+), 195 deletions(-)
>
> diff --git a/accel/tcg/atomic_template.h b/accel/tcg/atomic_template.h
> index 685602b076..5aaf186253 100644
> --- a/accel/tcg/atomic_template.h
> +++ b/accel/tcg/atomic_template.h
> @@ -62,21 +62,21 @@
>  #define ATOMIC_TRACE_RMW do {   \
>  uint8_t info = glue(trace_mem_build_info_no_se, MEND)(SHIFT, false); 
> \
>  \
> -trace_guest_mem_before_exec(ENV_GET_CPU(env), addr, info);  \
> -trace_guest_mem_before_exec(ENV_GET_CPU(env), addr, \
> +trace_guest_mem_before_exec(env_cpu(env), addr, info);  \
> +trace_guest_mem_before_exec(env_cpu(env), addr, \
>  info | TRACE_MEM_ST);   \
>  } while (0)
>
>  #define ATOMIC_TRACE_LD do {\
>  uint8_t info = glue(trace_mem_build_info_no_se, MEND)(SHIFT, false); 
> \
>  \
> -trace_guest_mem_before_exec(ENV_GET_CPU(env), addr, info);  \
> +trace_guest_mem_before_exec(env_cpu(env), addr, info);  \
>  } while (0)
>
>  # define ATOMIC_TRACE_ST do {   \
>  uint8_t info = glue(trace_mem_build_info_no_se, MEND)(SHIFT, true); \
> 

Re: [Qemu-devel] [PATCH 05/35] cpu: Define ArchCPU

[Alistair Francis]

On Sat, Mar 23, 2019 at 12:48 PM Richard Henderson
 wrote:
>
> For all targets, do this just before including exec/cpu-all.h.
>
> Signed-off-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  target/alpha/cpu.h  | 1 +
>  target/arm/cpu.h| 1 +
>  target/cris/cpu.h   | 1 +
>  target/hppa/cpu.h   | 1 +
>  target/i386/cpu.h   | 1 +
>  target/lm32/cpu.h   | 1 +
>  target/m68k/cpu.h   | 1 +
>  target/microblaze/cpu.h | 1 +
>  target/mips/cpu.h   | 1 +
>  target/moxie/cpu.h  | 1 +
>  target/nios2/cpu.h  | 1 +
>  target/openrisc/cpu.h   | 1 +
>  target/ppc/cpu.h| 1 +
>  target/riscv/cpu.h  | 1 +
>  target/s390x/cpu.h  | 1 +
>  target/sh4/cpu.h| 1 +
>  target/sparc/cpu.h  | 1 +
>  target/tilegx/cpu.h | 1 +
>  target/tricore/cpu.h| 1 +
>  target/unicore32/cpu.h  | 1 +
>  target/xtensa/cpu.h | 1 +
>  21 files changed, 21 insertions(+)
>
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index fac622aa02..6629b869d2 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -301,6 +301,7 @@ void alpha_cpu_do_unaligned_access(CPUState *cpu, vaddr 
> addr,
>  #define cpu_signal_handler cpu_alpha_signal_handler
>
>  typedef CPUAlphaState CPUArchState;
> +typedef AlphaCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 89fb92a032..5a8a3f7f7d 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -3055,6 +3055,7 @@ static inline bool 
> arm_cpu_data_is_big_endian(CPUARMState *env)
>  }
>
>  typedef CPUARMState CPUArchState;
> +typedef ARMCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/cris/cpu.h b/target/cris/cpu.h
> index 95662c36b2..bcd17bf88b 100644
> --- a/target/cris/cpu.h
> +++ b/target/cris/cpu.h
> @@ -285,6 +285,7 @@ int cris_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int size, int rw,
>  #define SFR_RW_MM_TLB_HI   env->pregs[PR_SRS]][6
>
>  typedef CPUCRISState CPUArchState;
> +typedef CRISCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index 7c1d1e0a0e..f90b11dd0b 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -231,6 +231,7 @@ static inline HPPACPU *hppa_env_get_cpu(CPUHPPAState *env)
>  #define ENV_OFFSET  offsetof(HPPACPU, env)
>
>  typedef CPUHPPAState CPUArchState;
> +typedef HPPACPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 84ca69ea1a..bb1464d451 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1750,6 +1750,7 @@ static inline target_long lshift(target_long x, int n)
>  void tcg_x86_init(void);
>
>  typedef CPUX86State CPUArchState;
> +typedef X86CPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>  #include "svm.h"
> diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
> index 5b24cfcc1f..5eef4ccfc5 100644
> --- a/target/lm32/cpu.h
> +++ b/target/lm32/cpu.h
> @@ -257,6 +257,7 @@ int lm32_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int size, int rw,
>int mmu_idx);
>
>  typedef CPULM32State CPUArchState;
> +typedef LM32CPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> index 48c051c7d2..5db18909cc 100644
> --- a/target/m68k/cpu.h
> +++ b/target/m68k/cpu.h
> @@ -536,6 +536,7 @@ void m68k_cpu_unassigned_access(CPUState *cs, hwaddr addr,
>  unsigned size);
>
>  typedef CPUM68KState CPUArchState;
> +typedef M68kCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/microblaze/cpu.h b/target/microblaze/cpu.h
> index 58e165..d7c1846e49 100644
> --- a/target/microblaze/cpu.h
> +++ b/target/microblaze/cpu.h
> @@ -366,6 +366,7 @@ int mb_cpu_handle_mmu_fault(CPUState *cpu, vaddr address, 
> int size, int rw,
>  int mmu_idx);
>
>  typedef CPUMBState CPUArchState;
> +typedef MicroBlazeCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 608ae23289..8c5a40b5ad 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1091,6 +1091,7 @@ static inline int cpu_mmu_index (CPUMIPSState *env, 
> bool ifetch)
>  }
>
>  typedef CPUMIPSState CPUArchState;
> +typedef MIPSCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/moxie/cpu.h b/target/moxie/cpu.h
> index 10ba6aa7be..4bc5e07af9 100644
> --- a/target/moxie/cpu.h
> +++ b/target/moxie/cpu.h
> @@ -119,6 +119,7 @@ static inline int cpu_mmu_index(CPUMoxieState *env, bool 
> ifetch)
>  }
>
>  typedef CPUMoxieState CPUArchState;
> +typedef MoxieCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> diff --git a/target/nios2/cpu.h b/target/nios2/cpu.h
> index 2b4bd25d65..272ab10e67 100644
> --- a/target/nios2/cpu.h
> +++ b/target/nios2/cpu.h
> @@ -244,6 +244,7 @@ static inline int cpu_interrupts_enabled(CPUNios2State 
> *env)
>  }
>
>  typedef CPUNios2State CPUArchState;
> +typedef Nios2CPU ArchCPU;
>
>  

Re: [Qemu-devel] [PATCH 04/35] cpu: Define CPUArchState with typedef

[Alistair Francis]

On Sat, Mar 23, 2019 at 12:54 PM Richard Henderson
 wrote:
>
> For all targets, do this just before including exec/cpu-all.h.
>
> Signed-off-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  target/alpha/cpu.h  | 4 ++--
>  target/arm/cpu.h| 4 ++--
>  target/cris/cpu.h   | 4 ++--
>  target/hppa/cpu.h   | 4 ++--
>  target/i386/cpu.h   | 5 ++---
>  target/lm32/cpu.h   | 5 ++---
>  target/m68k/cpu.h   | 4 ++--
>  target/microblaze/cpu.h | 5 ++---
>  target/mips/cpu.h   | 6 ++
>  target/moxie/cpu.h  | 4 ++--
>  target/nios2/cpu.h  | 5 ++---
>  target/openrisc/cpu.h   | 4 ++--
>  target/ppc/cpu.h| 4 ++--
>  target/riscv/cpu.h  | 4 ++--
>  target/s390x/cpu.h  | 8 
>  target/sh4/cpu.h| 4 ++--
>  target/sparc/cpu.h  | 4 ++--
>  target/tilegx/cpu.h | 4 ++--
>  target/tricore/cpu.h| 6 +-
>  target/unicore32/cpu.h  | 4 ++--
>  target/xtensa/cpu.h | 4 ++--
>  21 files changed, 43 insertions(+), 53 deletions(-)
>
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index e4aacbe5a3..fac622aa02 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -26,8 +26,6 @@
>
>  #define ALIGNED_ONLY
>
> -#define CPUArchState struct CPUAlphaState
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>
> @@ -302,6 +300,8 @@ void alpha_cpu_do_unaligned_access(CPUState *cpu, vaddr 
> addr,
>  #define cpu_list alpha_cpu_list
>  #define cpu_signal_handler cpu_alpha_signal_handler
>
> +typedef CPUAlphaState CPUArchState;
> +
>  #include "exec/cpu-all.h"
>
>  enum {
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 497f973543..89fb92a032 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -29,8 +29,6 @@
>  /* ARM processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>
> -#define CPUArchState struct CPUARMState
> -
>  #define EXCP_UDEF1   /* undefined instruction */
>  #define EXCP_SWI 2   /* software interrupt */
>  #define EXCP_PREFETCH_ABORT  3
> @@ -3056,6 +3054,8 @@ static inline bool 
> arm_cpu_data_is_big_endian(CPUARMState *env)
>  }
>  }
>
> +typedef CPUARMState CPUArchState;
> +
>  #include "exec/cpu-all.h"
>
>  /* Bit usage in the TB flags field: bit 31 indicates whether we are
> diff --git a/target/cris/cpu.h b/target/cris/cpu.h
> index 832796d457..95662c36b2 100644
> --- a/target/cris/cpu.h
> +++ b/target/cris/cpu.h
> @@ -25,8 +25,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define CPUArchState struct CPUCRISState
> -
>  #define EXCP_NMI1
>  #define EXCP_GURU   2
>  #define EXCP_BUSFAULT   3
> @@ -286,6 +284,8 @@ int cris_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int size, int rw,
>  #define SFR_RW_MM_TLB_LO   env->pregs[PR_SRS]][5
>  #define SFR_RW_MM_TLB_HI   env->pregs[PR_SRS]][6
>
> +typedef CPUCRISState CPUArchState;
> +
>  #include "exec/cpu-all.h"
>
>  static inline void cpu_get_tb_cpu_state(CPUCRISState *env, target_ulong *pc,
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index fe97786de1..7c1d1e0a0e 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -31,8 +31,6 @@
> basis.  It's probably easier to fall back to a strong memory model.  */
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>
> -#define CPUArchState struct CPUHPPAState
> -
>  #define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
> @@ -232,6 +230,8 @@ static inline HPPACPU *hppa_env_get_cpu(CPUHPPAState *env)
>  #define ENV_GET_CPU(e)  CPU(hppa_env_get_cpu(e))
>  #define ENV_OFFSET  offsetof(HPPACPU, env)
>
> +typedef CPUHPPAState CPUArchState;
> +
>  #include "exec/cpu-all.h"
>
>  static inline int cpu_mmu_index(CPUHPPAState *env, bool ifetch)
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 6716958276..84ca69ea1a 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1,4 +1,3 @@
> -
>  /*
>   * i386 virtual CPU header
>   *
> @@ -44,8 +43,6 @@
>  #define ELF_MACHINE_UNAME "i686"
>  #endif
>
> -#define CPUArchState struct CPUX86State
> -
>  enum {
>  R_EAX = 0,
>  R_ECX = 1,
> @@ -1752,6 +1749,8 @@ static inline target_long lshift(target_long x, int n)
>  /* translate.c */
>  void tcg_x86_init(void);
>
> +typedef CPUX86State CPUArchState;
> +
>  #include "exec/cpu-all.h"
>  #include "svm.h"
>
> diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
> index 3c9c8a904c..5b24cfcc1f 100644
> --- a/target/lm32/cpu.h
> +++ b/target/lm32/cpu.h
> @@ -24,9 +24,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define CPUArchState struct CPULM32State
> -
> -struct CPULM32State;
>  typedef struct CPULM32State CPULM32State;
>
>  static inline int cpu_mmu_index(CPULM32State *env, bool ifetch)
> @@ -259,6 +256,8 @@ bool lm32_cpu_do_semihosting(CPUState *cs);
>  int lm32_cpu_handle_mmu_fault(CPUState *cpu, vaddr address, int size, int rw,
>int mmu_idx);

Re: [Qemu-devel] [PATCH 03/35] tcg: Create struct CPUTLB

[Alistair Francis]

On Sat, Mar 23, 2019 at 12:47 PM Richard Henderson
 wrote:
>
> Move all softmmu tlb data into this structure.  Arrange the
> members so that we are able to place mask+table together and
> at a smaller absolute offset from ENV.
>
> Signed-off-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  accel/tcg/softmmu_template.h |   4 +-
>  include/exec/cpu-defs.h  |  61 ---
>  include/exec/cpu_ldst.h  |   6 +-
>  accel/tcg/cputlb.c   | 147 ++-
>  target/arm/translate-a64.c   |   2 +-
>  tcg/aarch64/tcg-target.inc.c |  10 +--
>  tcg/arm/tcg-target.inc.c |  10 +--
>  tcg/i386/tcg-target.inc.c|   4 +-
>  tcg/mips/tcg-target.inc.c|  12 +--
>  tcg/ppc/tcg-target.inc.c |   8 +-
>  tcg/riscv/tcg-target.inc.c   |  12 +--
>  tcg/s390/tcg-target.inc.c|   8 +-
>  tcg/sparc/tcg-target.inc.c   |  12 +--
>  13 files changed, 135 insertions(+), 161 deletions(-)
>
> diff --git a/accel/tcg/softmmu_template.h b/accel/tcg/softmmu_template.h
> index e970a8b378..fc6371aed1 100644
> --- a/accel/tcg/softmmu_template.h
> +++ b/accel/tcg/softmmu_template.h
> @@ -102,7 +102,7 @@ static inline DATA_TYPE glue(io_read, 
> SUFFIX)(CPUArchState *env,
>bool recheck,
>MMUAccessType access_type)
>  {
> -CPUIOTLBEntry *iotlbentry = >iotlb[mmu_idx][index];
> +CPUIOTLBEntry *iotlbentry = _tlb(env)->d[mmu_idx].iotlb[index];
>  return io_readx(env, iotlbentry, mmu_idx, addr, retaddr, recheck,
>  access_type, DATA_SIZE);
>  }
> @@ -273,7 +273,7 @@ static inline void glue(io_write, SUFFIX)(CPUArchState 
> *env,
>uintptr_t retaddr,
>bool recheck)
>  {
> -CPUIOTLBEntry *iotlbentry = >iotlb[mmu_idx][index];
> +CPUIOTLBEntry *iotlbentry = _tlb(env)->d[mmu_idx].iotlb[index];
>  return io_writex(env, iotlbentry, mmu_idx, val, addr, retaddr,
>   recheck, DATA_SIZE);
>  }
> diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
> index 2694481769..fbe8945606 100644
> --- a/include/exec/cpu-defs.h
> +++ b/include/exec/cpu-defs.h
> @@ -78,6 +78,7 @@ typedef uint64_t target_ulong;
>  #endif
>
>  #if !defined(CONFIG_USER_ONLY) && defined(CONFIG_TCG)
> +
>  /* use a fully associative victim tlb of 8 entries */
>  #define CPU_VTLB_SIZE 8
>
> @@ -147,6 +148,10 @@ typedef struct CPUIOTLBEntry {
>  MemTxAttrs attrs;
>  } CPUIOTLBEntry;
>
> +/*
> + * Data elements that are per MMU mode, minus the bits accessed by
> + * the TCG fast path.
> + */
>  typedef struct CPUTLBDesc {
>  /*
>   * Describe a region covering all of the large pages allocated
> @@ -160,16 +165,31 @@ typedef struct CPUTLBDesc {
>  int64_t window_begin_ns;
>  /* maximum number of entries observed in the window */
>  size_t window_max_entries;
> +size_t n_used_entries;
>  /* The next index to use in the tlb victim table.  */
>  size_t vindex;
> -size_t n_used_entries;
> +/* The tlb victim table, in two parts.  */
> +CPUTLBEntry vtable[CPU_VTLB_SIZE];
> +CPUIOTLBEntry viotlb[CPU_VTLB_SIZE];
> +/* The iotlb.  */
> +CPUIOTLBEntry *iotlb;
>  } CPUTLBDesc;
>
> +/*
> + * Data elements that are per MMU mode, accessed by the fast path.
> + */
> +typedef struct CPUTLBDescFast {
> +/* Contains (n_entries - 1) << CPU_TLB_ENTRY_BITS */
> +uintptr_t mask;
> +/* The array of tlb entries itself. */
> +CPUTLBEntry *table;
> +} CPUTLBDescFast;
> +
>  /*
>   * Data elements that are shared between all MMU modes.
>   */
>  typedef struct CPUTLBCommon {
> -/* Serialize updates to tlb_table and tlb_v_table, and others as noted. 
> */
> +/* Serialize updates to tlb_table and vtable, and others as noted. */
>  QemuSpin lock;
>  /*
>   * Within dirty, for each bit N, modifications have been made to
> @@ -187,35 +207,24 @@ typedef struct CPUTLBCommon {
>  size_t elide_flush_count;
>  } CPUTLBCommon;
>
> -# define CPU_TLB\
> -/* tlb_mask[i] contains (n_entries - 1) << CPU_TLB_ENTRY_BITS */\
> -uintptr_t tlb_mask[NB_MMU_MODES];   \
> -CPUTLBEntry *tlb_table[NB_MMU_MODES];
> -# define CPU_IOTLB  \
> -CPUIOTLBEntry *iotlb[NB_MMU_MODES];
> -
>  /*
> + * The entire softmmu tlb, for all MMU modes.
>   * The meaning of each of the MMU modes is defined in the target code.
> - * Note that NB_MMU_MODES is not yet defined; we can only reference it
> - * within preprocessor defines that will be expanded later.
>   */
> -#define CPU_COMMON_TLB \
> -CPUTLBCommon tlb_c; \
> -CPUTLBDesc tlb_d[NB_MMU_MODES]; \
> -CPU_TLB

Re: [Qemu-devel] [PATCH 02/35] tcg: Split out target/arch/cpu-param.h

[Alistair Francis]

On Sat, Mar 23, 2019 at 12:44 PM Richard Henderson
 wrote:
>
> For all targets, into this new file move TARGET_LONG_BITS,
> TARGET_PAGE_BITS, TARGET_PHYS_ADDR_SPACE_BITS,
> TARGET_VIRT_ADDR_SPACE_BITS, and NB_MMU_MODES.
>
> Include this new file from exec/cpu-defs.h.
>
> This now removes the somewhat odd requirement that target/arch/cpu.h
> defines TARGET_LONG_BITS before including exec/cpu-defs.h, so push the
> bulk of the includes within target/arch/cpu.h to the top.
>
> Signed-off-by: Richard Henderson 

For RISC-V:

Acked-by: Alistair Francis 

Alistair

> ---
>  include/exec/cpu-defs.h   | 22 +-
>  target/alpha/cpu-param.h  | 19 +++
>  target/alpha/cpu.h| 23 +--
>  target/arm/cpu-param.h| 22 ++
>  target/arm/cpu.h  | 33 +++--
>  target/cris/cpu-param.h   |  5 +
>  target/cris/cpu.h | 11 +--
>  target/hppa/cpu-param.h   | 22 ++
>  target/hppa/cpu.h | 24 +---
>  target/i386/cpu-param.h   | 14 ++
>  target/i386/cpu.h | 21 -
>  target/lm32/cpu-param.h   |  5 +
>  target/lm32/cpu.h | 12 +++-
>  target/m68k/cpu-param.h   |  9 +
>  target/m68k/cpu.h | 16 ++--
>  target/microblaze/cpu-param.h |  6 ++
>  target/microblaze/cpu.h   | 14 ++
>  target/mips/cpu-param.h   | 18 ++
>  target/mips/cpu.h |  3 +--
>  target/mips/mips-defs.h   | 15 ---
>  target/moxie/cpu-param.h  |  5 +
>  target/moxie/cpu.h| 12 +---
>  target/nios2/cpu-param.h  |  9 +
>  target/nios2/cpu.h| 17 ++---
>  target/openrisc/cpu-param.h   |  5 +
>  target/openrisc/cpu.h | 14 +++---
>  target/ppc/cpu-param.h| 25 +
>  target/ppc/cpu.h  | 35 ++-
>  target/riscv/cpu-param.h  | 11 +++
>  target/riscv/cpu.h| 21 -
>  target/s390x/cpu-param.h  |  5 +
>  target/s390x/cpu.h| 11 +--
>  target/sh4/cpu-param.h|  9 +
>  target/sh4/cpu.h  | 14 +-
>  target/sparc/cpu-param.h  | 17 +
>  target/sparc/cpu.h| 20 ++--
>  target/tilegx/cpu-param.h |  5 +
>  target/tilegx/cpu.h   |  9 +
>  target/tricore/cpu-param.h|  5 +
>  target/tricore/cpu.h  |  4 +---
>  target/tricore/tricore-defs.h |  5 -
>  target/unicore32/cpu-param.h  |  5 +
>  target/unicore32/cpu.h| 10 +-
>  target/xtensa/cpu-param.h |  9 +
>  target/xtensa/cpu.h   | 21 +
>  45 files changed, 289 insertions(+), 328 deletions(-)
>  create mode 100644 target/alpha/cpu-param.h
>  create mode 100644 target/arm/cpu-param.h
>  create mode 100644 target/cris/cpu-param.h
>  create mode 100644 target/hppa/cpu-param.h
>  create mode 100644 target/i386/cpu-param.h
>  create mode 100644 target/lm32/cpu-param.h
>  create mode 100644 target/m68k/cpu-param.h
>  create mode 100644 target/microblaze/cpu-param.h
>  create mode 100644 target/mips/cpu-param.h
>  create mode 100644 target/moxie/cpu-param.h
>  create mode 100644 target/nios2/cpu-param.h
>  create mode 100644 target/openrisc/cpu-param.h
>  create mode 100644 target/ppc/cpu-param.h
>  create mode 100644 target/riscv/cpu-param.h
>  create mode 100644 target/s390x/cpu-param.h
>  create mode 100644 target/sh4/cpu-param.h
>  create mode 100644 target/sparc/cpu-param.h
>  create mode 100644 target/tilegx/cpu-param.h
>  create mode 100644 target/tricore/cpu-param.h
>  create mode 100644 target/unicore32/cpu-param.h
>  create mode 100644 target/xtensa/cpu-param.h
>
> diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
> index 52d150aaf1..2694481769 100644
> --- a/include/exec/cpu-defs.h
> +++ b/include/exec/cpu-defs.h
> @@ -34,8 +34,28 @@
>  #endif
>  #include "exec/memattrs.h"
>
> +#include "cpu-param.h"
> +
>  #ifndef TARGET_LONG_BITS
> -#error TARGET_LONG_BITS must be defined before including this header
> +# error TARGET_LONG_BITS must be defined in cpu-param.h
> +#endif
> +#ifndef NB_MMU_MODES
> +# error NB_MMU_MODES must be defined in cpu-param.h
> +#endif
> +#ifndef TARGET_PHYS_ADDR_SPACE_BITS
> +# error TARGET_PHYS_ADDR_SPACE_BITS must be defined in cpu-param.h
> +#endif
> +#ifndef TARGET_VIRT_ADDR_SPACE_BITS
> +# error TARGET_VIRT_ADDR_SPACE_BITS must be defined in cpu-param.h
> +#endif
> +#ifndef TARGET_PAGE_BITS
> +# ifdef TARGET_PAGE_BITS_VARY
> +#  ifndef TARGET_PAGE_BITS_MIN
> +#   error TARGET_PAGE_BITS_MIN must be defined in cpu-param.h
> +#  endif
> +# else
> +#  error TARGET_PAGE_BITS must be defined in cpu-param.h
> +# 

[Qemu-devel] [ANNOUNCE] QEMU 4.0.0-rc1 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 4.0 release.  This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu-project.org/qemu-4.0.0-rc1.tar.xz
  http://download.qemu-project.org/qemu-4.0.0-rc1.tar.xz.sig

You can help improve the quality of the QEMU 4.0 release by testing this
release and reporting bugs on Launchpad:

  https://bugs.launchpad.net/qemu/

The release plan, as well a documented known issues for release
candidates, are available at:

  http://wiki.qemu.org/Planning/4.0

Please add entries to the ChangeLog for the 4.0 release below:

  http://wiki.qemu.org/ChangeLog/4.0

Thank you to everyone involved!

49fc899f8d: Update version for v4.0.0-rc1 release (Peter Maydell)
c99ef792dc: gdbstub: fix vCont packet handling when no thread is specified (Luc 
Michel)
c8877d0f2f: target/arm: Set SIMDMISC and FPMISC for 32-bit -cpu max (Richard 
Henderson)
339534d402: ati-vga: Fix indexed access to video memory (BALATON Zoltan)
ab8789987f: ohci: don't die on ED_LINK_LIMIT overflow (Laurent Vivier)
c6e3f520c8: qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK (Kevin Wolf)
c9fdcf202f: qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing (Kevin Wolf)
738301e117: file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes (Kevin 
Wolf)
80f5c33ff3: block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers (Kevin Wolf)
fe0480d629: block: Add BDRV_REQ_NO_FALLBACK (Kevin Wolf)
48ce986096: block: Remove error messages in bdrv_make_zero() (Kevin Wolf)
a66c4b83c9: iotests: add 248: test resume mirror after auto pause on ENOSPC 
(Vladimir Sementsov-Ogievskiy)
620455350a: target/riscv: Fix wrong expanding for c.fswsp (Kito Cheng)
3f905a5bba: pflash: Bury disabled code to limit device sizes (Alex Bennée)
06f1521795: pflash: Require backend size to match device, improve errors 
(Markus Armbruster)
413aeacd4b: qapi/qmp-dispatch: fix return value in do_qmp_dispatch (Vladimir 
Sementsov-Ogievskiy)
19e8ff485a: json: Fix off-by-one assert check in next_state() (Liam Merwick)
ad85b0b4c7: xen-block: Replace qdict_put_obj() by qdict_put() where appropriate 
(Markus Armbruster)
57b7291e90: util/error: Remove an unnecessary NULL check (Philippe 
Mathieu-Daudé)
c38c1c142e: migration/postcopy: Update the bandwidth during postcopy (Dr. David 
Alan Gilbert)
5ed0deca41: Migration/colo.c: Make user obtain the last COLO mode info after 
failover (Zhang Chen)
82cd368ccd: Migration/colo.c: Add the necessary checks for colo_do_failover 
(Zhang Chen)
3a43ac4757: Migration/colo.c: Add new COLOExitReason to handle all failover 
state (Zhang Chen)
1fe6ab267f: Migration/colo.c: Fix COLO failover status error (Zhang Chen)
281496bb8a: migration/rdma: Check qemu_rdma_init_one_block (Dr. David Alan 
Gilbert)
d2f1d29b95: migration: add support for a "tls-authz" migration parameter 
(Daniel P. Berrange)
cbfd6c957a: multifd: Drop x- (Juan Quintela)
5fbd8b4bbb: multifd: Add some padding (Juan Quintela)
4b0c72645c: multifd: Change default packet size (Juan Quintela)
7ed379b286: multifd: Be flexible about packet size (Juan Quintela)
efd1a1d640: multifd: Drop x-multifd-page-count parameter (Juan Quintela)
2a34ee593b: multifd: Create new next_packet_size field (Juan Quintela)
6f86269295: multifd: Rename "size" member to pages_alloc (Juan Quintela)
ad24c7cb59: multifd: Only send pages when packet are not empty (Juan Quintela)
f2b2f53f64: target/arm: make pmccntr_op_start/finish static (Andrew Jones)
a46118fc16: target/arm: cortex-a7 and cortex-a15 have pmus (Andrew Jones)
cbbb3041fe: target/arm: fix crash on pmu register access (Andrew Jones)
da77e0fad4: target/arm: add PCI_TESTDEV back to default config (Andrew Jones)
4261b2f915: nrf51_gpio: reflect pull-up/pull-down to IRQs (Paolo Bonzini)
a036f5302c: target/arm: Fix non-parallel expansion of CASP (Richard Henderson)
87db901820: docker: trivial changes to `make docker` help (Wainer dos Santos 
Moschetta)
a6de52ac7a: docker: Fix travis script unable to find source dir (Wainer dos 
Santos Moschetta)
e8ced6813d: docker: Fix travis.py parser and misc change (Wainer dos Santos 
Moschetta)
896f51fbfa: hardfloat: fix float32/64 fused multiply-add (Kito Cheng)
7ca96e1a9c: target/mips: Fix minor bug in FPU (Mateja Marjanovic)
aec2927dda: .travis.yml: reduce number of targets built while disabling things 
(Alex Bennée)
386dc51492: .travis.yml: --disable-user for --without-default-devices (Alex 
Bennée)
8c3daf975b: .travis.yml: split some more system builds (Alex Bennée)
447e133f7a: configure: add --target-list-exclude (Alex Bennée)
7849f0c2ec: slirp: is not maintained by Kelly Price for a long time (Marc-André 
Lureau)
0c4cc4e218: slirp: remove reference to COPYRIGHT file (Marc-André Lureau)
dfacac4c81: slirp: clarify license of slirp files using SPDX: implicit via 
unstated (Marc-André Lureau)
3e6d35e560: slirp: clarify license of slirp files using SPDX: implicit via 
COPYRIGHT 

Re: [Qemu-devel] Why is vhost-user limited to 8 slots?

[Raphael Norwitz]

ping
From: Raphael Norwitz 
Date: Monday, March 18, 2019 at 7:10 PM
To: "m...@redhat.com" 
Cc: "qemu-devel@nongnu.org" , Malcolm Crossley 
, Mike Cui , Felipe Franciosi 

Subject: [Qemu-devel] Why is vhost-user limited to 8 slots?

Hi MST,

Looking at the kernel commit log, I see that commit 
c9ce42f72fd0ba180fd35539829e4139dca31494 introduced support for a configurable 
number of regions in vhost, but vhost-user is still limited to 8 slots. Is 
there a reason for that? Would you consider a patch to either statically 
increase the number of vhost-user slots (to something like 64?) or define some 
protocol allowing the number of slots to be negotiated?

Apologies if this has already been answered. I briefly looked through the 
mailing list archive and couldn’t find anything obvious.

Thanks,
Raphael

Re: [Qemu-devel] [PATCH] Categorize devices

[Philippe Mathieu-Daudé]

Le mar. 26 mars 2019 20:10, Eduardo Habkost  a écrit :

> On Tue, Mar 26, 2019 at 07:43:51PM +0100, Hervé Poussineau wrote:
> > Le 24/03/2019 à 19:05, Ernest Esene a écrit :
> > > Categorize devices in "uncategorised devices" section
> > > This patch is based on BiteSizedTask.
> > >
> > > Signed-off-by: Ernest Esene 
> > > ---
> > >   hw/dma/i82374.c   | 2 ++
> > >   hw/i386/amd_iommu.c   | 2 ++
> > >   hw/i386/intel_iommu.c | 2 ++
> > >   hw/i386/pc_piix.c | 1 +
> > >   hw/ipmi/ipmi_bmc_extern.c | 2 ++
> > >   hw/ipmi/ipmi_bmc_sim.c| 2 ++
> > >   hw/ipmi/isa_ipmi_bt.c | 2 ++
> > >   hw/ipmi/isa_ipmi_kcs.c| 2 ++
> > >   hw/mem/nvdimm.c   | 1 +
> > >   hw/mem/pc-dimm.c  | 1 +
> > >   hw/tpm/tpm_tis.c  | 3 +++
> > >   11 files changed, 20 insertions(+)
> >
> >
> > i82374 part:
> >
> > Reviewed-by: Hervé Poussineau 
>
> Thanks!  I wonder if it would be useful to resubmit this as
> separate patches, so the parts that are already reviewed aren't
> blocked by missing reviews for the other devices.
>

Good idea, I prefer that too.


> --
> Eduardo
>
>

Re: [Qemu-devel] [PATCH] Categorize devices

[Eduardo Habkost]

On Tue, Mar 26, 2019 at 07:43:51PM +0100, Hervé Poussineau wrote:
> Le 24/03/2019 à 19:05, Ernest Esene a écrit :
> > Categorize devices in "uncategorised devices" section
> > This patch is based on BiteSizedTask.
> > 
> > Signed-off-by: Ernest Esene 
> > ---
> >   hw/dma/i82374.c   | 2 ++
> >   hw/i386/amd_iommu.c   | 2 ++
> >   hw/i386/intel_iommu.c | 2 ++
> >   hw/i386/pc_piix.c | 1 +
> >   hw/ipmi/ipmi_bmc_extern.c | 2 ++
> >   hw/ipmi/ipmi_bmc_sim.c| 2 ++
> >   hw/ipmi/isa_ipmi_bt.c | 2 ++
> >   hw/ipmi/isa_ipmi_kcs.c| 2 ++
> >   hw/mem/nvdimm.c   | 1 +
> >   hw/mem/pc-dimm.c  | 1 +
> >   hw/tpm/tpm_tis.c  | 3 +++
> >   11 files changed, 20 insertions(+)
> 
> 
> i82374 part:
> 
> Reviewed-by: Hervé Poussineau 

Thanks!  I wonder if it would be useful to resubmit this as
separate patches, so the parts that are already reviewed aren't
blocked by missing reviews for the other devices.

-- 
Eduardo

Re: [Qemu-devel] [PATCH for 4.1 v2 10/13] tests: acpi: add simple arm/virt testcase

[Philippe Mathieu-Daudé]

Le mar. 26 mars 2019 17:05, Igor Mammedov  a écrit :

> On Tue, 26 Mar 2019 15:27:39 +0100
> Laszlo Ersek  wrote:
>
> > On 03/26/19 14:09, Igor Mammedov wrote:
> > > adds simple arm/virt test case that starts guest with
> > > bios-tables-test.aarch64.iso.qcow2 boot image which
> > > initializes UefiTestSupport* structure in RAM once
> > > guest is booted.
> > >
> > >  * see commit: tests: acpi: add acpi_find_rsdp_address_uefi() helper
> > >
> > > Signed-off-by: Igor Mammedov 
> > > ---
> > > v3:
> > >   * use firmware blobs directly from pc-bios directory
> > >   * use bios-tables-test.aarch64.iso.qcow2 as test boot image
> > > v2:
> > >   * specify in test_data where board's RAM starts and RAM size
> > > ---
> > >  tests/Makefile.include   |  1 +
> > >  tests/bios-tables-test.c | 17 +
> > >  2 files changed, 18 insertions(+)
> > >
> > > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > > index 0a0e1c3..0619751 100644
> > > --- a/tests/Makefile.include
> > > +++ b/tests/Makefile.include
> > > @@ -269,6 +269,7 @@ check-qtest-arm-y += tests/hexloader-test$(EXESUF)
> > >  check-qtest-aarch64-y = tests/numa-test$(EXESUF)
> > >  check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
> > >  check-qtest-aarch64-y += tests/migration-test$(EXESUF)
> > > +qtest-uefi-images-aarch64 = edk2-aarch64-code.fd.xz
> edk2-arm-vars.fd.xz
> > >
> > >  check-qtest-microblazeel-y += $(check-qtest-microblaze-y)
> > >
> >
> > What is this hunk needed for?
> >
> > I'm asking because it can't work on top of my v3 posting ("[PATCH
> > for-4.1 v3 00/12] bundle edk2 platform firmware  with QEMU") -- that
> > version provides *.bz2 files, not *.xz files.
> >
> > In addition, the rest of your patch refers to the decompressed (*.fd)
> > images -- and that is correct, in fact, given that my patches
> >
> > * [PATCH for-4.1 v3 10/12]
> >   tests: add missing dependency to build QTEST_QEMU_BINARY, round 2
> >   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06140.html
> >
> > * [PATCH for-4.1 v3 11/12]
> >   Makefile: install the edk2 firmware images and their descriptors
> >   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06138.html
> >
> > make sure that the images are decompressed for testing too.
> >
> > So, in the end, this hunk should be dropped, IMO.
>
> I know, I've just missed it during clean up. I'll fix it up.
>
> > > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> > > index 097ef03..b5cb425 100644
> > > --- a/tests/bios-tables-test.c
> > > +++ b/tests/bios-tables-test.c
> > > @@ -804,6 +804,21 @@ static void test_acpi_piix4_tcg_dimm_pxm(void)
> > >  test_acpi_tcg_dimm_pxm(MACHINE_PC);
> > >  }
> > >
> > > +static void test_acpi_virt_tcg(void)
> > > +{
> > > +test_data data = {
> > > +.machine = "virt",
> > > +.uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > > +.uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > > +.cd =
> "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2",
> > > +.ram_start = 0x4000ULL,
> > > +.scan_len = 128ULL * 1024 * 1024,
> > > +};
> >
> > (Feel free to ignore this one:)
> >
> > you might want to beautify both constants using the macros from
> > "qemu/units.h": 1 * GiB, and 128 * MiB.
>
> I prefer to use a less as possible code from QEMU in tests lest we break
> the later so tests would notice.
> (it probably doesn't matter much in this case)


Reviewed-by: Philippe Mathieu-Daudé 

>
> > > +
> > > +test_acpi_one("-cpu cortex-a57 ", );
> > > +free_test_data();
> > > +}
> > > +
> > >  int main(int argc, char *argv[])
> > >  {
> > >  const char *arch = qtest_get_arch();
> > > @@ -831,6 +846,8 @@ int main(int argc, char *argv[])
> > >  qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
> > >  qtest_add_func("acpi/piix4/dimmpxm",
> test_acpi_piix4_tcg_dimm_pxm);
> > >  qtest_add_func("acpi/q35/dimmpxm",
> test_acpi_q35_tcg_dimm_pxm);
> > > +} else if (strcmp(arch, "aarch64") == 0) {
> > > +qtest_add_func("acpi/virt", test_acpi_virt_tcg);
> > >  }
> > >  ret = g_test_run();
> > >  boot_sector_cleanup(disk);
> > >
> >
> > With the Makefile.include hunk dropped (and regardless of the constants):
> >
> > Reviewed-by: Laszlo Ersek 
>
> Thanks!
>
> >
> > Thanks,
> > Laszlo
>
>
>

Re: [Qemu-devel] [PATCH for 4.1 v2 10/13] tests: acpi: add simple arm/virt testcase

[Philippe Mathieu-Daudé]

Le mar. 26 mars 2019 15:28, Laszlo Ersek  a écrit :

> On 03/26/19 14:09, Igor Mammedov wrote:
> > adds simple arm/virt test case that starts guest with
> > bios-tables-test.aarch64.iso.qcow2 boot image which
> > initializes UefiTestSupport* structure in RAM once
> > guest is booted.
> >
> >  * see commit: tests: acpi: add acpi_find_rsdp_address_uefi() helper
> >
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >   * use firmware blobs directly from pc-bios directory
> >   * use bios-tables-test.aarch64.iso.qcow2 as test boot image
> > v2:
> >   * specify in test_data where board's RAM starts and RAM size
> > ---
> >  tests/Makefile.include   |  1 +
> >  tests/bios-tables-test.c | 17 +
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > index 0a0e1c3..0619751 100644
> > --- a/tests/Makefile.include
> > +++ b/tests/Makefile.include
> > @@ -269,6 +269,7 @@ check-qtest-arm-y += tests/hexloader-test$(EXESUF)
> >  check-qtest-aarch64-y = tests/numa-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/migration-test$(EXESUF)
> > +qtest-uefi-images-aarch64 = edk2-aarch64-code.fd.xz edk2-arm-vars.fd.xz
> >
> >  check-qtest-microblazeel-y += $(check-qtest-microblaze-y)
> >
>
> What is this hunk needed for?
>
> I'm asking because it can't work on top of my v3 posting ("[PATCH
> for-4.1 v3 00/12] bundle edk2 platform firmware  with QEMU") -- that
> version provides *.bz2 files, not *.xz files.
>
> In addition, the rest of your patch refers to the decompressed (*.fd)
> images -- and that is correct, in fact, given that my patches
>
> * [PATCH for-4.1 v3 10/12]
>   tests: add missing dependency to build QTEST_QEMU_BINARY, round 2
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06140.html
>
> * [PATCH for-4.1 v3 11/12]
>   Makefile: install the edk2 firmware images and their descriptors
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06138.html
>
> make sure that the images are decompressed for testing too.
>
> So, in the end, this hunk should be dropped, IMO.
>
> > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> > index 097ef03..b5cb425 100644
> > --- a/tests/bios-tables-test.c
> > +++ b/tests/bios-tables-test.c
> > @@ -804,6 +804,21 @@ static void test_acpi_piix4_tcg_dimm_pxm(void)
> >  test_acpi_tcg_dimm_pxm(MACHINE_PC);
> >  }
> >
> > +static void test_acpi_virt_tcg(void)
> > +{
> > +test_data data = {
> > +.machine = "virt",
> > +.uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > +.uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > +.cd =
> "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2",
> > +.ram_start = 0x4000ULL,
> > +.scan_len = 128ULL * 1024 * 1024,
> > +};
>
> (Feel free to ignore this one:)
>
> you might want to beautify both constants using the macros from
> "qemu/units.h": 1 * GiB, and 128 * MiB.
>

When I suggested to enforce those macros, my concern was not beauty but
ease review to QEMU newcomers not custom to read hexadecimal (or young
developers/students for Bit-sized tasks) and to give a hint with the unit
that we express memory size (not Hertz for frequency). 1 * GiB looks more
natural than 0x4000ULL. It was somehow funny that not everybody agreed,
in particular the experienced developers.


> > +
> > +test_acpi_one("-cpu cortex-a57 ", );
> > +free_test_data();
> > +}
> > +
> >  int main(int argc, char *argv[])
> >  {
> >  const char *arch = qtest_get_arch();
> > @@ -831,6 +846,8 @@ int main(int argc, char *argv[])
> >  qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
> >  qtest_add_func("acpi/piix4/dimmpxm",
> test_acpi_piix4_tcg_dimm_pxm);
> >  qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
> > +} else if (strcmp(arch, "aarch64") == 0) {
> > +qtest_add_func("acpi/virt", test_acpi_virt_tcg);
> >  }
> >  ret = g_test_run();
> >  boot_sector_cleanup(disk);
> >
>
> With the Makefile.include hunk dropped (and regardless of the constants):
>
> Reviewed-by: Laszlo Ersek 
>
> Thanks,
> Laszlo
>
>

Re: [Qemu-devel] [PATCH] Categorize devices

[Hervé Poussineau]

Le 24/03/2019 à 19:05, Ernest Esene a écrit :

Categorize devices in "uncategorised devices" section
This patch is based on BiteSizedTask.

Signed-off-by: Ernest Esene 
---
  hw/dma/i82374.c   | 2 ++
  hw/i386/amd_iommu.c   | 2 ++
  hw/i386/intel_iommu.c | 2 ++
  hw/i386/pc_piix.c | 1 +
  hw/ipmi/ipmi_bmc_extern.c | 2 ++
  hw/ipmi/ipmi_bmc_sim.c| 2 ++
  hw/ipmi/isa_ipmi_bt.c | 2 ++
  hw/ipmi/isa_ipmi_kcs.c| 2 ++
  hw/mem/nvdimm.c   | 1 +
  hw/mem/pc-dimm.c  | 1 +
  hw/tpm/tpm_tis.c  | 3 +++
  11 files changed, 20 insertions(+)



i82374 part:

Reviewed-by: Hervé Poussineau 



diff --git a/hw/dma/i82374.c b/hw/dma/i82374.c
index 892f655a..5b42dd1b 100644
--- a/hw/dma/i82374.c
+++ b/hw/dma/i82374.c
@@ -147,6 +147,8 @@ static void i82374_class_init(ObjectClass *klass, void 
*data)
  dc->realize = i82374_realize;
  dc->vmsd = _i82374;
  dc->props = i82374_properties;
+dc->desc = "Intel Enhanced DMA controller";
+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
  }
  
  static const TypeInfo i82374_info = {

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 6eabdf99..4a4e2c7f 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1601,6 +1601,8 @@ static void amdvi_class_init(ObjectClass *klass, void* 
data)
  dc_class->int_remap = amdvi_int_remap;
  /* Supported by the pc-q35-* machine types */
  dc->user_creatable = true;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+dc->desc = "AMD IOMMU (AMD-Vi) DMA Remapping device";
  }
  
  static const TypeInfo amdvi = {

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index b90de6c6..4d0e6042 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3702,6 +3702,8 @@ static void vtd_class_init(ObjectClass *klass, void *data)
  x86_class->int_remap = vtd_int_remap;
  /* Supported by the pc-q35-* machine types */
  dc->user_creatable = true;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+dc->desc = "Intel IOMMU (VT-d) DMA Remapping device";
  }
  
  static const TypeInfo vtd_info = {

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8ad8e885..03a9cb8a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -911,6 +911,7 @@ static void isa_bridge_class_init(ObjectClass *klass, void 
*data)
  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
  
  dc->desc= "ISA bridge faked to support IGD PT";

+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
  k->vendor_id= PCI_VENDOR_ID_INTEL;
  k->class_id = PCI_CLASS_BRIDGE_ISA;
  };
diff --git a/hw/ipmi/ipmi_bmc_extern.c b/hw/ipmi/ipmi_bmc_extern.c
index bf0b7ee0..39049c4d 100644
--- a/hw/ipmi/ipmi_bmc_extern.c
+++ b/hw/ipmi/ipmi_bmc_extern.c
@@ -526,6 +526,8 @@ static void ipmi_bmc_extern_class_init(ObjectClass *oc, 
void *data)
  dc->hotpluggable = false;
  dc->realize = ipmi_bmc_extern_realize;
  dc->props = ipmi_bmc_extern_properties;
+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+dc->desc = "IPMI Baseboard management controller";
  }
  
  static const TypeInfo ipmi_bmc_extern_type = {

diff --git a/hw/ipmi/ipmi_bmc_sim.c b/hw/ipmi/ipmi_bmc_sim.c
index 9b509f82..95a096fa 100644
--- a/hw/ipmi/ipmi_bmc_sim.c
+++ b/hw/ipmi/ipmi_bmc_sim.c
@@ -2016,6 +2016,8 @@ static void ipmi_sim_class_init(ObjectClass *oc, void 
*data)
  dc->realize = ipmi_sim_realize;
  dc->props = ipmi_sim_properties;
  bk->handle_command = ipmi_sim_handle_command;
+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+dc->desc = "IPMI Baseboard management controller";
  }
  
  static const TypeInfo ipmi_sim_type = {

diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c
index 8bbb1fa7..9ca3402e 100644
--- a/hw/ipmi/isa_ipmi_bt.c
+++ b/hw/ipmi/isa_ipmi_bt.c
@@ -541,6 +541,8 @@ static void isa_ipmi_bt_class_init(ObjectClass *oc, void 
*data)
  
  dc->realize = isa_ipmi_bt_realize;

  dc->props = ipmi_isa_properties;
+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+dc->desc = "ISA IPMI BT System Interface";
  
  iic->get_backend_data = isa_ipmi_bt_get_backend_data;

  ipmi_bt_class_init(iic);
diff --git a/hw/ipmi/isa_ipmi_kcs.c b/hw/ipmi/isa_ipmi_kcs.c
index a7943155..818d59d1 100644
--- a/hw/ipmi/isa_ipmi_kcs.c
+++ b/hw/ipmi/isa_ipmi_kcs.c
@@ -524,6 +524,8 @@ static void isa_ipmi_kcs_class_init(ObjectClass *oc, void 
*data)
  
  dc->realize = ipmi_isa_realize;

  dc->props = ipmi_isa_properties;
+set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+dc->desc = "ISA IPMI KCS System Interface";
  
  iic->get_backend_data = isa_ipmi_kcs_get_backend_data;

  ipmi_kcs_class_init(iic);
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index bf2adf5e..a334dbe1 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -200,6 +200,7 @@ static void nvdimm_class_init(ObjectClass *oc, void *data)
  ddc->realize = nvdimm_realize;
  mdc->get_memory_region = 

Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

[Markus Armbruster]

Laszlo Ersek  writes:

> On 03/26/19 17:39, Markus Armbruster wrote:
>> Laszlo Ersek  writes:
>
>>> With the dynamic sizing in QEMU (which, IIRC, I had originally
>>> introduced still in the 1MB times, due to the split between the
>>> executable and varstore parts), both the 1MB->2MB switch, and the
>>> 2MB->4MB switch in the firmware caused zero pain in QEMU. And right now,
>>> 4MB looks like a "sweet spot", with some elbow room left.
>> 
>> Explicit configuration would've been exactly as painless.  Even with
>> pflash sizes restricted to powers of two.
>
> I wrote the patch that ended up as commit 637a5acb46b3 -- with your R-b
> -- in 2013. I'm unsure if machine type properties existed back then, but
> even if they did, do you think I knew about them? :)
>
> You are right, of course; it's just that we can't tell the future.

True!  All we can do is continue to design as well as we can given the
information, experience and resources we have, and when the inevitable
design mistakes become apparent, limit their impact.

Some of the things we now consider mistakes we just didn't see.  Others
we saw (e.g. multiple pflash devices, unlike physical hardware), but
underestimated their impact.

[...]

[Qemu-devel] [PATCH for-4.0] qemu-img: Gracefully shutdown when map can't finish

[Eric Blake]

Trying 'qemu-img map -f raw nbd://localhost:10809' causes the
NBD server to output a scary message:

qemu-nbd: Disconnect client, due to: Failed to read request: Unexpected 
end-of-file before all bytes were read

This is because the NBD client, being remote, has no way to expose a
human-readable map (the --output=json data is fine, however). But
because we exit(1) right after the message, causing the client to
bypass all block cleanup, the server sees the abrupt exit and warns,
whereas it would be silent had the client had a chance to send
NBD_CMD_DISC. Other protocols may have similar cleanup issues, where
failure to blk_unref() could cause unintended effects.

Signed-off-by: Eric Blake 
---

Since I found this while testing NBD, I'm happy to include it through
my tree.

 qemu-img.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index 12f071a1ca2..55c599841a1 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -2736,14 +2736,14 @@ static int img_info(int argc, char **argv)
 return 0;
 }

-static void dump_map_entry(OutputFormat output_format, MapEntry *e,
-   MapEntry *next)
+static int dump_map_entry(OutputFormat output_format, MapEntry *e,
+  MapEntry *next)
 {
 switch (output_format) {
 case OFORMAT_HUMAN:
 if (e->data && !e->has_offset) {
 error_report("File contains external, encrypted or compressed 
clusters.");
-exit(1);
+return -1;
 }
 if (e->data && !e->zero) {
 printf("%#-16"PRIx64"%#-16"PRIx64"%#-16"PRIx64"%s\n",
@@ -2776,6 +2776,7 @@ static void dump_map_entry(OutputFormat output_format, 
MapEntry *e,
 }
 break;
 }
+return 0;
 }

 static int get_block_status(BlockDriverState *bs, int64_t offset,
@@ -2968,12 +2969,15 @@ static int img_map(int argc, char **argv)
 }

 if (curr.length > 0) {
-dump_map_entry(output_format, , );
+ret = dump_map_entry(output_format, , );
+if (ret < 0) {
+goto out;
+}
 }
 curr = next;
 }

-dump_map_entry(output_format, , NULL);
+ret = dump_map_entry(output_format, , NULL);

 out:
 blk_unref(blk);
-- 
2.20.1

Re: [Qemu-devel] [PATCH for-4.0] nbd-client: Work around server BLOCK_STATUS misalignment at EOF

[Eric Blake]

On 3/26/19 12:13 PM, Eric Blake wrote:
> The NBD spec is clear that a server that advertises a minimum block
> size should reply to NBD_CMD_BLOCK_STATUS with extents aligned
> accordingly. However, we know that the qemu NBD server implementation
> has had a corner-case bug where it is not compliant with the spec,
> present since the introduction of NBD_CMD_BLOCK_STATUS in qemu 2.12
> (and unlikely to be patched in time for 4.0). Namely, when qemu is
> serving a file that is not a multiple of 512 bytes, it rounds the size
> advertised over NBD up to the next sector boundary (someday, I'd like
> to fix that to be byte-accurate, but it's a much bigger audit not
> appropriate for this release); yet if the final sector contains data
> prior to EOF, lseek(SEEK_HOLE) will point to the implicit hole
> mid-sector which qemu then reported over NBD.
> 
> We are well within our rights to hang up on a server that can't follow
> the spec, but it is more useful to try and keep the connection alive
> in spite of the problem. Do so by tracing a message about the problem,
> and then either truncating the request back to an aligned boundary (if
> it covered more than the final sector) or widening it out to the full
> boundary with a forced status of data (since truncating would result
> in 0 bytes, but we have to make progress, and valid since data is a
> default-safe answer). And in practice, since the problem only happens
> on a sector that starts with data and ends with a hole, we are going
> to want to read that full sector anyway (where qemu as the server
> fills in the tail beyond EOF with appropriate NUL bytes).
> 
> Easy reproduction:
> $ printf %1000d 1 > file
> $ qemu-nbd -f raw -t file & pid=$!
> $ qemu-img map --output=json -f raw nbd://localhost:10809
> qemu-img: Could not read file metadata: Invalid argument
> $ kill $pid
> 
> where the patched version instead succeeds with:
> [{ "start": 0, "length": 1024, "depth": 0, "zero": false, "data": true}]
> 
> Signed-off-by: Eric Blake 
> ---
>  block/nbd-client.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)

I haven't seen patchew reports in a few days. But just in case it tries
to apply this,

Based-on: <20190325190104.30213-1-ebl...@redhat.com>
[v2 0/2] nbd: simple errors to BLOCK_STATUS

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1821430] Re: qemu-user-arm (4.0.0-rc0) crashes

[asavah]

qemu-user-arm 4.0.0-rc1 no longer produces any crashes for me.
Huge thanks.


** Changed in: qemu
   Status: Fix Committed => Fix Released

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

Title:
  qemu-user-arm (4.0.0-rc0) crashes

Status in QEMU:
  Fix Released

Bug description:
  I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper.
  qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions:

  first case (sadly I don't have more data handy, can reproduce at a later time 
if needed):
  (gdb) x/i $pc
  => 0xfffce314:  vseleq.f64  d0, d17, d0

  second case (llvm-config):
  qemu cmdline:
  qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E 
LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib
 /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode

  --- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} ---
  qemu: uncaught target signal 4 (Illegal instruction) - core dumped

  output from gdb(arm) attached to qemu-user-arm
  Program received signal SIGILL, Illegal instruction.
  0xf9f77f80 in ?? ()
  (gdb) bt
  #0  0xf9f77f80 in ?? ()
  #1  0xfffd796c in ?? ()
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb)  x/i $pc
  => 0xf9f77f80:  vrintm.f64  d18, d18

  
  The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 
19.04 package and self built)
  work flawlessly.

  This is clearly a regression.
  Please fix before releasing 4.0.0.

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

Re: [Qemu-devel] [PATCH] qapi/migration.json: Fix documentation issue about query_colo_status

[Eric Blake]

On 3/26/19 12:45 PM, Zhang Chen wrote:
> From: Zhang Chen 
> 
> The documentation with the wrong initial version number of last_mode field,
> This patch just fix this issue.

Grammar is a bit odd, but I'll leave it up to a maintainer if they want
to improve it. I suggest a shorter:

Fix a wrong initial version number for last_mode.

> 
> Signed-off-by: Zhang Chen 
> ---
>  qapi/migration.json | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Eric Blake 

Safe for 4.0, but not a showstopper if it slips.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 0/2 v2] misc usb-mtp fixes

[Bandan Das]

v2:
  1/2: Add Reviewed-by tag
  2/2: remove extra vars and directly call usb_mtp_queue_result
  
The first patch removes a unnecessary function
and the second is just a code reorg of usb_mtp_write_data
to make it less confusing. Applies on top of
[PATCH v3] usb-mtp: fix return status of delete
Message-ID: 

Bandan Das (2):
  usb-mtp: remove usb_mtp_object_free_one
  usb-mtp: refactor the flow of usb_mtp_write_data

 hw/usb/dev-mtp.c | 67 
 1 file changed, 28 insertions(+), 39 deletions(-)

-- 
2.19.2

[Qemu-devel] [PATCH 1/2 v2] usb-mtp: remove usb_mtp_object_free_one

[Bandan Das]

This function is used in the delete path only and can
be replaced by a call to usb_mtp_object_free.

Reviewed-by: Peter Maydell 
Signed-off-by: Bandan Das 
---
 hw/usb/dev-mtp.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 91b820baaf..4dc1317e2e 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1150,16 +1150,6 @@ enum {
 DELETE_PARTIAL = (DELETE_FAILURE | DELETE_SUCCESS),
 };
 
-/* Assumes that children, if any, have been already freed */
-static void usb_mtp_object_free_one(MTPState *s, MTPObject *o)
-{
-assert(o->nchildren == 0);
-QTAILQ_REMOVE(>objects, o, next);
-g_free(o->name);
-g_free(o->path);
-g_free(o);
-}
-
 static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
 {
 MTPObject *iter, *iter2;
@@ -1181,14 +1171,14 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, 
uint32_t trans)
 if (remove(o->path)) {
 ret |= DELETE_FAILURE;
 } else {
-usb_mtp_object_free_one(s, o);
+usb_mtp_object_free(s, o);
 ret |= DELETE_SUCCESS;
 }
 } else if (o->format == FMT_ASSOCIATION) {
 if (rmdir(o->path)) {
 ret |= DELETE_FAILURE;
 } else {
-usb_mtp_object_free_one(s, o);
+usb_mtp_object_free(s, o);
 ret |= DELETE_SUCCESS;
 }
 }
-- 
2.19.2

[Qemu-devel] [PULL] target/xtensa fixes for v4.0

[Max Filippov]

Hi Peter,
  
please pull the following batch of target/xtensa fixes for v4.0.

The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:

  Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)

are available in the git repository at:

  git://github.com/OSLL/qemu-xtensa.git tags/20190326-xtensa

for you to fetch changes up to bc19449acc2e05854118a47cdf96c1e86b30740d:

  tests/tcg/xtensa: clean up test set (2019-03-23 14:42:05 -0700)


target/xtensa fixes for v4.0:

- fix translation of FLIX bundles with multiple references to the same
  register;
- don't announce exit simcall;
- clean up tests/tcg/xtensa.


Max Filippov (3):
  target/xtensa: fix break_dependency for repeated resources
  target/xtensa: don't announce exit simcall
  tests/tcg/xtensa: clean up test set

 target/xtensa/translate.c|   1 -
 target/xtensa/xtensa-semi.c  |   1 -
 tests/tcg/xtensa/Makefile.softmmu-target |   2 +-
 tests/tcg/xtensa/test_fail.S |   9 --
 tests/tcg/xtensa/test_flix.S |  17 
 tests/tcg/xtensa/test_pipeline.S | 157 ---
 6 files changed, 18 insertions(+), 169 deletions(-)
 delete mode 100644 tests/tcg/xtensa/test_fail.S
 delete mode 100644 tests/tcg/xtensa/test_pipeline.S

-- 
Thanks.
-- Max

[Qemu-devel] [PATCH 2/2 v2] usb-mtp: refactor the flow of usb_mtp_write_data

[Bandan Das]

There's no functional change but the flow is (hopefully)
more consistent for both file and folder object types.

Signed-off-by: Bandan Das 
---
 hw/usb/dev-mtp.c | 53 
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 4dc1317e2e..57a4d00ad0 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1599,7 +1599,7 @@ static int usb_mtp_update_object(MTPObject *parent, char 
*name)
 return ret;
 }
 
-static int usb_mtp_write_data(MTPState *s)
+static void usb_mtp_write_data(MTPState *s, uint32_t handle)
 {
 MTPData *d = s->data_out;
 MTPObject *parent =
@@ -1616,26 +1616,32 @@ static int usb_mtp_write_data(MTPState *s)
 if (!parent || !s->write_pending) {
 usb_mtp_queue_result(s, RES_INVALID_OBJECTINFO, d->trans,
 0, 0, 0, 0);
-return 1;
+return;
 }
 
 if (s->dataset.filename) {
 path = g_strdup_printf("%s/%s", parent->path, s->dataset.filename);
 if (s->dataset.format == FMT_ASSOCIATION) {
 ret = mkdir(path, mask);
-goto free;
+if (!ret) {
+usb_mtp_queue_result(s, RES_OK, d->trans, 3,
+ QEMU_STORAGE_ID,
+ s->dataset.parent_handle,
+ handle);
+}
+goto done;
 }
+
 d->fd = open(path, O_CREAT | O_WRONLY |
  O_CLOEXEC | O_NOFOLLOW, mask);
 if (d->fd == -1) {
-usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
- 0, 0, 0, 0);
+ret = 1;
 goto done;
 }
 
 /* Return success if initiator sent 0 sized data */
 if (!s->dataset.size) {
-goto success;
+goto done;
 }
 if (d->length != MTP_WRITE_BUF_SZ && !d->pending) {
 d->write_status = WRITE_END;
@@ -1647,13 +1653,12 @@ static int usb_mtp_write_data(MTPState *s)
 rc = write_retry(d->fd, d->data, d->data_offset,
  d->offset - d->data_offset);
 if (rc != d->data_offset) {
-usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
- 0, 0, 0, 0);
+ret = 1;
 goto done;
 }
 if (d->write_status != WRITE_END) {
 g_free(path);
-return ret;
+return;
 } else {
 /*
  * Return an incomplete transfer if file size doesn't match
@@ -1665,16 +1670,17 @@ static int usb_mtp_write_data(MTPState *s)
 usb_mtp_update_object(parent, s->dataset.filename)) {
 usb_mtp_queue_result(s, RES_INCOMPLETE_TRANSFER, d->trans,
  0, 0, 0, 0);
-goto done;
+goto close;
 }
 }
 }
 
-success:
-usb_mtp_queue_result(s, RES_OK, d->trans,
- 0, 0, 0, 0);
-
 done:
+if (ret) {
+usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
+ 0, 0, 0, 0);
+}
+close:
 /*
  * The write dataset is kept around and freed only
  * on success or if another write request comes in
@@ -1683,12 +1689,10 @@ done:
 close(d->fd);
 d->fd = -1;
 }
-free:
 g_free(s->dataset.filename);
 s->dataset.size = 0;
 g_free(path);
 s->write_pending = false;
-return ret;
 }
 
 static void usb_mtp_write_metadata(MTPState *s, uint64_t dlen)
@@ -1725,16 +1729,11 @@ static void usb_mtp_write_metadata(MTPState *s, 
uint64_t dlen)
 s->write_pending = true;
 
 if (s->dataset.format == FMT_ASSOCIATION) {
-if (usb_mtp_write_data(s)) {
-/* next_handle will be allocated to the newly created dir */
-usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
- 0, 0, 0, 0);
-return;
-}
+usb_mtp_write_data(s, next_handle);
+} else {
+usb_mtp_queue_result(s, RES_OK, d->trans, 3, QEMU_STORAGE_ID,
+ s->dataset.parent_handle, next_handle);
 }
-
-usb_mtp_queue_result(s, RES_OK, d->trans, 3, QEMU_STORAGE_ID,
- s->dataset.parent_handle, next_handle);
 }
 
 static void usb_mtp_get_data(MTPState *s, mtp_container *container,
@@ -1814,14 +1813,14 @@ static void usb_mtp_get_data(MTPState *s, mtp_container 
*container,
 } else {
 d->write_status = WRITE_START;
 }
-usb_mtp_write_data(s);
+usb_mtp_write_data(s, 0);
 usb_mtp_data_free(s->data_out);
 s->data_out = NULL;
 return;
 }
 if (d->data_offset == d->length) {
   

Re: [Qemu-devel] [PATCH] SiFive RISC-V GPIO Device

[Fabien Chouteau]

Hi Palmer,

On 26/03/2019 09:58, Palmer Dabbelt wrote:
> Do you have anything that actually glues this to a machine so I can test it?
> 

In this patch I do instantiate the device in sifive_e machine.

Regards,

Re: [Qemu-devel] [PATCH 2/3] target/arm: cortex-a7 and cortex-a15 have pmus

[Andrew Jones]

On Tue, Mar 26, 2019 at 05:38:36PM +, Aaron Lindsay OS wrote:
> On Mar 22 17:23, Andrew Jones wrote:
> > cortex-a7 and cortex-a15 have pmus (PMUv2) and they advertise
> > them in ID_DFR0. Let's allow them to function. This also enables
> > the pmu cpu property to work with these cpu types, i.e. we can
> > now do '-cpu cortex-a15,pmu=off' to remove the pmu.
> 
> I'm a little nervous about this one, but PMUv2 isn't fresh enough in my
> mind to have a good reason other than that I didn't consider it when
> writing my recent PMU patches. Do you know if this boots a kernel that
> can detect and use the PMU successfully while thinking it's PMUv2?
>

I didn't try booting a kernel and running perf or anything like that.
It does now run the pmu kvm-unit-tests test though. As this patch is
now in master the test you propose can be done with a latest build :)

Thanks,
drew

Re: [Qemu-devel] [PATCH] vl: Fix to create migration object before block backends again

[Markus Armbruster]

Anthony PERARD  writes:

> On Tue, Mar 26, 2019 at 03:58:52PM +, Anthony PERARD wrote:
>> On Wed, Mar 13, 2019 at 09:43:30AM +0100, Markus Armbruster wrote:
>> > Recent commit cda4aa9a5a0 moved block backend creation before machine
>> > property evaluation.  This broke qemu-iotests 055.  Turns out we need
>> > to create the migration object before block backends, so block
>> > backends can add migration blockers.  Fix by calling
>> > migration_object_init() earlier, right before configure_blockdev().
>> > 
>> > Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
>> > Reported-by: Kevin Wolf 
>> > Signed-off-by: Markus Armbruster 
>> 
>> Hi,
>> 
>> After this patch is applied, migration with Xen doesn't work anymore.
>> When QEMU on the receiving end is started, it prints:
>> qemu-system-i386: load of migration failed: Invalid argument
>
> I should have quote this from QEMU stderr instead of the single line
> abrove:
> qemu-system-i386: Configuration section missing
> qemu-system-i386: load of migration failed: Invalid argument
>
>> > +/*
>> > + * Migration object can only be created after global properties
>> > + * are applied correctly.
>> > + */
>> > +migration_object_init();
>> 
>> I think it's because migration_object_init() is now called before
>> configure_accelerator(). xen_accel_class_init() have some compat_props
>> for migration.

I see.

Anything that gets created before a certain compat property becomes
known silently ignores the compat property[*].

Accelerator compat properties become known when we select the
accelerator.  This is awfully late, because we want to pick the first
accelerator that initializes, which requires a machine.

>> Any idea how to fix this?

Known dependencies:

* migration object_init() must run before configure_blockdev(), so block
  backends can register migration blockers

* configure_blockdev() must run before machine_set_property(), so
  machine properties can refer to block backends.

* configure_accelerator() must run after machine creation, because it
  needs a machine

* configure_accelerator() must run before migration_object_init(), so
  migration_object_init() can see accelerator compat properties.

We're currently violating the last one, because weren't aware of it.  To
fix that, rejigger some more: move configure_accelerator() before
migration_object_init() (with a suitable comment), then see what else
breaks.  Could you try the appended patch and report whether it fixes
your problem?


[*] Silent ignore is nasty.  I got experimental code to turn it into a
hard failure.


diff --git a/vl.c b/vl.c
index d61d5604e5..28b9e9a170 100644
--- a/vl.c
+++ b/vl.c
@@ -4276,6 +4276,12 @@ int main(int argc, char **argv, char **envp)
 exit(0);
 }
 
+/*
+ * Must run before migration_object_init() to make Xen's
+ * accelerator compat properties stick
+ */
+configure_accelerator(current_machine, argv[0]);
+
 /*
  * Migration object can only be created after global properties
  * are applied correctly.
@@ -4297,8 +4303,6 @@ int main(int argc, char **argv, char **envp)
 current_machine->maxram_size = maxram_size;
 current_machine->ram_slots = ram_slots;
 
-configure_accelerator(current_machine, argv[0]);
-
 if (!qtest_enabled() && machine_class->deprecation_reason) {
 error_report("Machine type '%s' is deprecated: %s",
  machine_class->name, machine_class->deprecation_reason);

[Qemu-devel] [PATCH] qapi/migration.json: Fix documentation issue about query_colo_status

[Zhang Chen]

From: Zhang Chen 

The documentation with the wrong initial version number of last_mode field,
This patch just fix this issue.

Signed-off-by: Zhang Chen 
---
 qapi/migration.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index cfde29acf8..798c6ac2df 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1382,7 +1382,7 @@
 #
 # @last_mode: COLO last running mode. If COLO is running, this field
 # will return same like mode field, after failover we can
-# use this field to get last colo mode. (since 4.1)
+# use this field to get last colo mode. (since 4.0)
 #
 # @reason: describes the reason for the COLO exit.
 #
-- 
2.17.GIT

Re: [Qemu-devel] [PATCH 3/3] target/arm: make pmccntr_op_start/finish static

[Aaron Lindsay OS]

On Mar 22 17:23, Andrew Jones wrote:
> These functions are not used outside helper.c
> 
> Signed-off-by: Andrew Jones 

I'm late to the party, but:

Reviewed-by: Aaron Lindsay 

> ---
>  target/arm/cpu.h| 11 ---
>  target/arm/helper.c |  4 ++--
>  2 files changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 5f23c621325c..d4d2836923df 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -992,17 +992,6 @@ static inline bool is_a64(CPUARMState *env)
>  int cpu_arm_signal_handler(int host_signum, void *pinfo,
> void *puc);
>  
> -/**
> - * pmccntr_op_start/finish
> - * @env: CPUARMState
> - *
> - * Convert the counter in the PMCCNTR between its delta form (the typical 
> mode
> - * when it's enabled) and the guest-visible value. These two calls must 
> always
> - * surround any action which might affect the counter.
> - */
> -void pmccntr_op_start(CPUARMState *env);
> -void pmccntr_op_finish(CPUARMState *env);
> -
>  /**
>   * pmu_op_start/finish
>   * @env: CPUARMState
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index fc73488f6cc0..a36f4b3d6997 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -1337,7 +1337,7 @@ static void pmu_update_irq(CPUARMState *env)
>   * etc. can be done logically. This is essentially a no-op if the counter is
>   * not enabled at the time of the call.
>   */
> -void pmccntr_op_start(CPUARMState *env)
> +static void pmccntr_op_start(CPUARMState *env)
>  {
>  uint64_t cycles = cycles_get_count(env);
>  
> @@ -1367,7 +1367,7 @@ void pmccntr_op_start(CPUARMState *env)
>   * guest-visible count. A call to pmccntr_op_finish should follow every call 
> to
>   * pmccntr_op_start.
>   */
> -void pmccntr_op_finish(CPUARMState *env)
> +static void pmccntr_op_finish(CPUARMState *env)
>  {
>  if (pmu_counter_enabled(env, 31)) {
>  #ifndef CONFIG_USER_ONLY
> -- 
> 2.17.2
> 

Re: [Qemu-devel] [PATCH 1/3] target/arm: fix crash on pmu register access

[Aaron Lindsay OS]

On Mar 22 17:23, Andrew Jones wrote:
> Fix a QEMU NULL derefence that occurs when the guest attempts to
> enable PMU counters with a non-v8 cpu model or a v8 cpu model
> which has not configured a PMU.
> 
> Fixes: 4e7beb0cc0f3 ("target/arm: Add a timer to predict PMU counter 
> overflow")
> Signed-off-by: Andrew Jones 

Reviewed-by: Aaron Lindsay 

> ---
>  target/arm/helper.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index c8d3c213b6b7..fc73488f6cc0 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -1259,6 +1259,10 @@ static bool pmu_counter_enabled(CPUARMState *env, 
> uint8_t counter)
>  int el = arm_current_el(env);
>  uint8_t hpmn = env->cp15.mdcr_el2 & MDCR_HPMN;
>  
> +if (!arm_feature(env, ARM_FEATURE_PMU)) {
> +return false;
> +}
> +
>  if (!arm_feature(env, ARM_FEATURE_EL2) ||
>  (counter < hpmn || counter == 31)) {
>  e = env->cp15.c9_pmcr & PMCRE;
> -- 
> 2.17.2
> 

Re: [Qemu-devel] [PATCH 2/3] target/arm: cortex-a7 and cortex-a15 have pmus

[Aaron Lindsay OS]

On Mar 22 17:23, Andrew Jones wrote:
> cortex-a7 and cortex-a15 have pmus (PMUv2) and they advertise
> them in ID_DFR0. Let's allow them to function. This also enables
> the pmu cpu property to work with these cpu types, i.e. we can
> now do '-cpu cortex-a15,pmu=off' to remove the pmu.

I'm a little nervous about this one, but PMUv2 isn't fresh enough in my
mind to have a good reason other than that I didn't consider it when
writing my recent PMU patches. Do you know if this boots a kernel that
can detect and use the PMU successfully while thinking it's PMUv2?

-Aaron

> Signed-off-by: Andrew Jones 
> ---
>  target/arm/cpu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 96f0ff0ec727..504a4771fbd3 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1109,6 +1109,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  #endif
>  } else {
>  cpu->id_aa64dfr0 &= ~0xf00;
> +cpu->id_dfr0 &= ~(0xf << 24);
>  cpu->pmceid0 = 0;
>  cpu->pmceid1 = 0;
>  }
> @@ -1744,6 +1745,7 @@ static void cortex_a7_initfn(Object *obj)
>  set_feature(>env, ARM_FEATURE_CBAR_RO);
>  set_feature(>env, ARM_FEATURE_EL2);
>  set_feature(>env, ARM_FEATURE_EL3);
> +set_feature(>env, ARM_FEATURE_PMU);
>  cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A7;
>  cpu->midr = 0x410fc075;
>  cpu->reset_fpsid = 0x41023075;
> @@ -1789,6 +1791,7 @@ static void cortex_a15_initfn(Object *obj)
>  set_feature(>env, ARM_FEATURE_CBAR_RO);
>  set_feature(>env, ARM_FEATURE_EL2);
>  set_feature(>env, ARM_FEATURE_EL3);
> +set_feature(>env, ARM_FEATURE_PMU);
>  cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A15;
>  cpu->midr = 0x412fc0f1;
>  cpu->reset_fpsid = 0x410430f0;
> -- 
> 2.17.2
> 

Re: [Qemu-devel] [PULL 14/15] Migration/colo.c: Make user obtain the last COLO mode info after failover

[Zhang, Chen]

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, March 26, 2019 10:41 PM
> To: Juan Quintela ; qemu-devel@nongnu.org
> Cc: Dr. David Alan Gilbert ; zhanghailiang
> ; Markus Armbruster
> ; Zhang, Chen 
> Subject: Re: [PULL 14/15] Migration/colo.c: Make user obtain the last COLO
> mode info after failover
> 
> On 3/25/19 12:47 PM, Juan Quintela wrote:
> > From: Zhang Chen 
> >
> > Add the last_colo_mode to save the status after failover.
> > This patch can solve the issue that user want to get last colo mode
> > use query_colo_status after failover.
> >
> > Signed-off-by: Zhang Chen 
> > Reviewed-by: Juan Quintela 
> > Signed-off-by: Juan Quintela 
> > ---
> 
> > +++ b/qapi/migration.json
> > @@ -1380,12 +1380,17 @@
> >  # @mode: COLO running mode. If COLO is running, this field will return
> >  #'primary' or 'secondary'.
> >  #
> > +# @last_mode: COLO last running mode. If COLO is running, this field
> > +# will return same like mode field, after failover we can
> > +# use this field to get last colo mode. (since 4.1)
> 
> s/4.1/4.0/ - now that this pull request is applied, we'll need a followup 
> patch.
> (Safe for 4.0, as fixing documentation is doable during
> freeze)

OK, I will send a patch for this issue.

Thanks
Zhang Chen

> 
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [RFC] arm/cpu: fix soft lockup panic after resuming from stop

[Steven Price]

Hi Heyi,

On 26/03/2019 13:53, Heyi Guo wrote:
> I also tested save/restore operations, and observed that clock in guest
> would not jump after restoring either. If we consider guest clock not
> being synchronized with real wall clock as an issue, does it mean
> save/restore function has the same issue?

Basically at the moment when the guest isn't running you have a choice
of two behaviours:

 1. Stop (i.e. save/restore) CNTVCT - this means that the guest sees no
time occur. If the guest needs to have a concept of wall-clock time
(e.g. it communicates with other systems over a network) then this can
cause problems (e.g. timeouts might be wrong, certificates might start
appearing to be in the future etc).

 2. Leave CNTVCT running - the guest sees the time pass but interprets
the vCPUs as effectively having locked up. Linux will trigger the soft
lockup warning.

There are two ways of solving this, which match the two behaviours above:

 1. Provide the guest with a view of wall-clock time. The obvious way of
doing this is with a pvclock implementation like MSR_KVM_WALL_CLOCK_NEW
for x86.

 2. Inform the guest to ignore the apparent "soft-lockup". There's
already an ioctl for x86 for this: KVM_KVMCLOCK_CTRL

My preference is for option 1 - as this gives the guest a good view of
both the time that it is actually executing (useful for internal
watchdog timers like the soft-lockup one in Linux) and maintains a view
of wall-clock time (useful when communicating with other external
services - e.g. the a server on the internet). Your patch to QEMU
provides the first step of that, but as you mention there's much more to do.

One thing I haven't investigated in great detail is how KVM handles the
timer during various forms of suspend. In particular for suspend types
like full hibernation the host's physical counter will jump (quite
possibly backwards) - I haven't looked in detail how KVM presents this
to the guest. Hopefully not by making it go backwards!

I'm not sure how much time I'm going to have to look at this in the near
future, but please keep me in the loop if you decide to tackle any of this.

Thanks,

Steve

[Qemu-devel] [PATCH for-4.0 1/3] block: continue until base is found in bdrv_freeze_backing_chain() et al

[Alberto Garcia]

All three functions that handle the BdrvChild.frozen attribute walk
the backing chain from 'bs' to 'base' and stop either when 'base' is
found or at the end of the chain if 'base' is NULL.

However if 'base' is not found then the functions return without
errors as if it was NULL.

This is wrong: if the caller passed an incorrect parameter that means
that there is a bug in the code.

Signed-off-by: Alberto Garcia 
---
 block.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/block.c b/block.c
index 0a93ee9ac8..3050854528 100644
--- a/block.c
+++ b/block.c
@@ -4218,14 +4218,15 @@ BlockDriverState *bdrv_find_base(BlockDriverState *bs)
 /*
  * Return true if at least one of the backing links between @bs and
  * @base is frozen. @errp is set if that's the case.
+ * @base must be reachable from @bs, or NULL.
  */
 bool bdrv_is_backing_chain_frozen(BlockDriverState *bs, BlockDriverState *base,
   Error **errp)
 {
 BlockDriverState *i;
 
-for (i = bs; i != base && i->backing; i = backing_bs(i)) {
-if (i->backing->frozen) {
+for (i = bs; i != base; i = backing_bs(i)) {
+if (i->backing && i->backing->frozen) {
 error_setg(errp, "Cannot change '%s' link from '%s' to '%s'",
i->backing->name, i->node_name,
backing_bs(i)->node_name);
@@ -4240,6 +4241,7 @@ bool bdrv_is_backing_chain_frozen(BlockDriverState *bs, 
BlockDriverState *base,
  * Freeze all backing links between @bs and @base.
  * If any of the links is already frozen the operation is aborted and
  * none of the links are modified.
+ * @base must be reachable from @bs, or NULL.
  * Returns 0 on success. On failure returns < 0 and sets @errp.
  */
 int bdrv_freeze_backing_chain(BlockDriverState *bs, BlockDriverState *base,
@@ -4251,8 +4253,10 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
BlockDriverState *base,
 return -EPERM;
 }
 
-for (i = bs; i != base && i->backing; i = backing_bs(i)) {
-i->backing->frozen = true;
+for (i = bs; i != base; i = backing_bs(i)) {
+if (i->backing) {
+i->backing->frozen = true;
+}
 }
 
 return 0;
@@ -4261,14 +4265,17 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
BlockDriverState *base,
 /*
  * Unfreeze all backing links between @bs and @base. The caller must
  * ensure that all links are frozen before using this function.
+ * @base must be reachable from @bs, or NULL.
  */
 void bdrv_unfreeze_backing_chain(BlockDriverState *bs, BlockDriverState *base)
 {
 BlockDriverState *i;
 
-for (i = bs; i != base && i->backing; i = backing_bs(i)) {
-assert(i->backing->frozen);
-i->backing->frozen = false;
+for (i = bs; i != base; i = backing_bs(i)) {
+if (i->backing) {
+assert(i->backing->frozen);
+i->backing->frozen = false;
+}
 }
 }
 
-- 
2.11.0

[Qemu-devel] [PATCH for-4.0] nbd-client: Work around server BLOCK_STATUS misalignment at EOF

[Eric Blake]

The NBD spec is clear that a server that advertises a minimum block
size should reply to NBD_CMD_BLOCK_STATUS with extents aligned
accordingly. However, we know that the qemu NBD server implementation
has had a corner-case bug where it is not compliant with the spec,
present since the introduction of NBD_CMD_BLOCK_STATUS in qemu 2.12
(and unlikely to be patched in time for 4.0). Namely, when qemu is
serving a file that is not a multiple of 512 bytes, it rounds the size
advertised over NBD up to the next sector boundary (someday, I'd like
to fix that to be byte-accurate, but it's a much bigger audit not
appropriate for this release); yet if the final sector contains data
prior to EOF, lseek(SEEK_HOLE) will point to the implicit hole
mid-sector which qemu then reported over NBD.

We are well within our rights to hang up on a server that can't follow
the spec, but it is more useful to try and keep the connection alive
in spite of the problem. Do so by tracing a message about the problem,
and then either truncating the request back to an aligned boundary (if
it covered more than the final sector) or widening it out to the full
boundary with a forced status of data (since truncating would result
in 0 bytes, but we have to make progress, and valid since data is a
default-safe answer). And in practice, since the problem only happens
on a sector that starts with data and ends with a hole, we are going
to want to read that full sector anyway (where qemu as the server
fills in the tail beyond EOF with appropriate NUL bytes).

Easy reproduction:
$ printf %1000d 1 > file
$ qemu-nbd -f raw -t file & pid=$!
$ qemu-img map --output=json -f raw nbd://localhost:10809
qemu-img: Could not read file metadata: Invalid argument
$ kill $pid

where the patched version instead succeeds with:
[{ "start": 0, "length": 1024, "depth": 0, "zero": false, "data": true}]

Signed-off-by: Eric Blake 
---
 block/nbd-client.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/block/nbd-client.c b/block/nbd-client.c
index a3b70d14004..241cc555246 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -269,14 +269,36 @@ static int nbd_parse_blockstatus_payload(NBDClientSession 
*client,
 extent->length = payload_advance32();
 extent->flags = payload_advance32();

-if (extent->length == 0 ||
-(client->info.min_block && !QEMU_IS_ALIGNED(extent->length,
-client->info.min_block))) {
+if (extent->length == 0) {
 error_setg(errp, "Protocol error: server sent status chunk with "
"invalid length");
 return -EINVAL;
 }

+/*
+ * A server sending unaligned block status is in violation of the
+ * protocol, but as qemu-nbd 3.1 is such a server (at least for
+ * POSIX files that are not a multiple of 512 bytes, since qemu
+ * rounds files up to 512-byte multiples but lseek(SEEK_HOLE)
+ * still sees an implicit hole beyond the real EOF), it's nicer to
+ * work around the misbehaving server. If the request included
+ * more than the final unaligned block, truncate it back to an
+ * aligned result; if the request was only the final block, round
+ * up to the full block and change the status to fully-allocated
+ * (always a safe status, even if it loses information).
+ */
+if (client->info.min_block && !QEMU_IS_ALIGNED(extent->length,
+   client->info.min_block)) {
+trace_nbd_parse_blockstatus_compliance("extent length is unaligned");
+if (extent->length > client->info.min_block) {
+extent->length = QEMU_ALIGN_DOWN(extent->length,
+ client->info.min_block);
+} else {
+extent->length = client->info.min_block;
+extent->flags = 0;
+}
+}
+
 /*
  * We used NBD_CMD_FLAG_REQ_ONE, so the server should not have
  * sent us any more than one extent, nor should it have included
-- 
2.20.1

[Qemu-devel] [PATCH for-4.0 2/3] block: freeze the backing chain earlier in stream_start()

[Alberto Garcia]

Commit 6585493369819a48d34a86d57ec6b97cb5cd9bc0 added code to freeze
the backing chain from 'top' to 'base' for the duration of the
block-stream job.

The problem is that the freezing happens too late in stream_start():
during the bdrv_reopen_set_read_only() call earlier in that function
another job can jump in and remove the base image. If that happens we
have an invalid chain and QEMU crashes.

This patch puts the bdrv_freeze_backing_chain() call at the beginning
of the function.

Signed-off-by: Alberto Garcia 
---
 block/stream.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/block/stream.c b/block/stream.c
index 6253c86fae..6502468f88 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -238,11 +238,16 @@ void stream_start(const char *job_id, BlockDriverState 
*bs,
 BlockDriverState *iter;
 bool bs_read_only;
 
+if (bdrv_freeze_backing_chain(bs, base, errp) < 0) {
+return;
+}
+
 /* Make sure that the image is opened in read-write mode */
 bs_read_only = bdrv_is_read_only(bs);
 if (bs_read_only) {
 if (bdrv_reopen_set_read_only(bs, false, errp) != 0) {
-return;
+bs_read_only = false;
+goto fail;
 }
 }
 
@@ -269,11 +274,6 @@ void stream_start(const char *job_id, BlockDriverState *bs,
_abort);
 }
 
-if (bdrv_freeze_backing_chain(bs, base, errp) < 0) {
-job_early_fail(>common.job);
-goto fail;
-}
-
 s->base = base;
 s->backing_file_str = g_strdup(backing_file_str);
 s->bs_read_only = bs_read_only;
@@ -285,6 +285,7 @@ void stream_start(const char *job_id, BlockDriverState *bs,
 return;
 
 fail:
+bdrv_unfreeze_backing_chain(bs, base);
 if (bs_read_only) {
 bdrv_reopen_set_read_only(bs, true, NULL);
 }
-- 
2.11.0

Re: [Qemu-devel] [qemu-s390x] [PATCH for-4.0?] exec: Only count mapped memory backends for qemu_getrampagesize()

[David Hildenbrand]

On 26.03.19 15:08, Igor Mammedov wrote:
> On Tue, 26 Mar 2019 14:50:58 +1100
> David Gibson  wrote:
> 
>> qemu_getrampagesize() works out the minimum host page size backing any of
>> guest RAM.  This is required in a few places, such as for POWER8 PAPR KVM
>> guests, because limitations of the hardware virtualization mean the guest
>> can't use pagesizes larger than the host pages backing its memory.
>>
>> However, it currently checks against *every* memory backend, whether or not
>> it is actually mapped into guest memory at the moment.  This is incorrect.
>>
>> This can cause a problem attempting to add memory to a POWER8 pseries KVM
>> guest which is configured to allow hugepages in the guest (e.g.
>> -machine cap-hpt-max-page-size=16m).  If you attempt to add non-hugepage,
>> you can (correctly) create a memory backend, however it (correctly) will
>> throw an error when you attempt to map that memory into the guest by
>> 'device_add'ing a pc-dimm.
>>
>> What's not correct is that if you then reset the guest a startup check
>> against qemu_getrampagesize() will cause a fatal error because of the new
>> memory object, even though it's not mapped into the guest.
> I'd say that backend should be remove by mgmt app since device_add failed
> instead of leaving it to hang around. (but fatal error either not a nice
> behavior on QEMU part)

Indeed, it should be removed. Depending on the options (huge pages with
prealloc?) memory might be consumed for unused memory. Undesired.

> 
>>
>> This patch corrects the problem by adjusting find_max_supported_pagesize()
>> (called from qemu_getrampagesize() via object_child_foreach) to exclude
>> non-mapped memory backends.
> I'm not sure about if it's ok do so. It depends on where from
> qemu_getrampagesize() is called. For example s390 calls it rather early
> when initializing KVM, so there isn't anything mapped yet.
> 
> And once I replace -mem-path with hostmem backend and drop
> qemu_mempath_getpagesize(mem_path) /which btw aren't guarantied to be mapped 
> either/
> this patch might lead to incorrect results for initial memory as well.
> 
>>
>> Signed-off-by: David Gibson 
>> ---
>>  exec.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> This is definitely a bug, but it's not a regression.  I'm not sure if
>> this is 4.0 material at this stage of the freeze or not.
>>
>> diff --git a/exec.c b/exec.c
>> index 86a38d3b3b..6ab62f4eee 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -1692,9 +1692,10 @@ static int find_max_supported_pagesize(Object *obj, 
>> void *opaque)
>>  long *hpsize_min = opaque;
>>  
>>  if (object_dynamic_cast(obj, TYPE_MEMORY_BACKEND)) {
>> -long hpsize = host_memory_backend_pagesize(MEMORY_BACKEND(obj));
>> +HostMemoryBackend *backend = MEMORY_BACKEND(obj);
>> +long hpsize = host_memory_backend_pagesize(backend);
>>  
>> -if (hpsize < *hpsize_min) {
>> +if (host_memory_backend_is_mapped(backend) && (hpsize < 
>> *hpsize_min)) {
>>  *hpsize_min = hpsize;
>>  }
>>  }
> 
> 


-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH for-4.0 0/3] freeze the backing chain earlier in stream_start()

[Alberto Garcia]

Hi,

this series fixes the bug that I found the other day and described here:

   https://lists.gnu.org/archive/html/qemu-block/2019-03/msg00764.html
   https://lists.gnu.org/archive/html/qemu-block/2019-03/msg00791.html

Patch 2 is the important one, patch 3 is a test case, and patch 1 will
allow us to detect this kind of errors earlier.

Regards,

Berto

Alberto Garcia (3):
  block: continue until base is found in bdrv_freeze_backing_chain() et
al
  block: freeze the backing chain earlier in stream_start()
  block: test block-stream with a base node that is used by block-commit

 block.c| 21 ++---
 block/stream.c | 13 +++--
 tests/qemu-iotests/030 | 32 
 tests/qemu-iotests/030.out |  4 ++--
 4 files changed, 55 insertions(+), 15 deletions(-)

-- 
2.11.0

Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

[Laszlo Ersek]

On 03/26/19 17:39, Markus Armbruster wrote:
> Laszlo Ersek  writes:

>> With the dynamic sizing in QEMU (which, IIRC, I had originally
>> introduced still in the 1MB times, due to the split between the
>> executable and varstore parts), both the 1MB->2MB switch, and the
>> 2MB->4MB switch in the firmware caused zero pain in QEMU. And right now,
>> 4MB looks like a "sweet spot", with some elbow room left.
> 
> Explicit configuration would've been exactly as painless.  Even with
> pflash sizes restricted to powers of two.

I wrote the patch that ended up as commit 637a5acb46b3 -- with your R-b
-- in 2013. I'm unsure if machine type properties existed back then, but
even if they did, do you think I knew about them? :)

You are right, of course; it's just that we can't tell the future.

>> Second, regarding physical RAM consumption: disable memory overcommit,
>> and set a large swap. The unused parts of the large pflash chips should
>> be swapped out at some point (after their initial population from disk),
>> and should never be swapped back in again.
> 
> Just providing swap should do the trick, shouldn't it?

Yes, it should.

(I just find any given swap setting more trustworthy if memory
overcommit is disabled -- for me, disabling memory overcommit comes
first. I trust "this swap should be large enough" much more if the
kernel enforces allocations and the OOM killer can't surprise me later.
I know we don't check g_malloc/g_new in QEMU, but I still prefer if
those crash QEMU over the OOM killer picking a victim.)

Thanks,
Laszlo

[Qemu-devel] [PATCH for-4.0 3/3] block: test block-stream with a base node that is used by block-commit

[Alberto Garcia]

The base node of a block-stream operation indicates the first image
from the backing chain starting from which no data is copied to the
top node.

The block-stream job allows others to use that base image, so a second
block-stream job could be writing to it at the same time. An important
restriction is that the base image must not disappear while the stream
job is ongoing. stream_start() freezes the backing chain from top to
base with that purpose but it does it too late in the code so there is
a race condition there.

This bug was fixed in the previous commit, and this patch contains an
iotest for this scenario.

Signed-off-by: Alberto Garcia 
---
 tests/qemu-iotests/030 | 32 
 tests/qemu-iotests/030.out |  4 ++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 276e06b5ba..184a59d465 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -314,6 +314,38 @@ class TestParallelOps(iotests.QMPTestCase):
 
 self.wait_until_completed(drive='commit-drive0')
 
+# In this case the base node of the stream job is the same as the
+# top node of commit job. Since block-commit removes the top node
+# when it finishes, this is not allowed.
+def test_overlapping_4(self):
+self.assert_no_active_block_jobs()
+
+# Commit from node2 into node0
+result = self.vm.qmp('block-commit', device='drive0', 
top=self.imgs[2], base=self.imgs[0])
+self.assert_qmp(result, 'return', {})
+
+# Stream from node2 into node4
+result = self.vm.qmp('block-stream', device='node4', 
base_node='node2', job_id='node4')
+self.assert_qmp(result, 'error/class', 'GenericError')
+
+# Wait for all jobs to be finished.
+pending_jobs = ['drive0']
+while len(pending_jobs) > 0:
+for event in self.vm.get_qmp_events(wait=True):
+if event['event'] == 'BLOCK_JOB_COMPLETED':
+node_name = self.dictpath(event, 'data/device')
+self.assertTrue(node_name in pending_jobs)
+self.assert_qmp_absent(event, 'data/error')
+pending_jobs.remove(node_name)
+if event['event'] == 'BLOCK_JOB_READY':
+self.assert_qmp(event, 'data/device', 'drive0')
+self.assert_qmp(event, 'data/type', 'commit')
+self.assert_qmp_absent(event, 'data/error')
+self.assertTrue('drive0' in pending_jobs)
+self.vm.qmp('block-job-complete', device='drive0')
+
+self.assert_no_active_block_jobs()
+
 # Test a block-stream and a block-commit job in parallel
 # Here the stream job is supposed to finish quickly in order to reproduce
 # the scenario that triggers the bug fixed in 3d5d319e1221 and 1a63a907507
diff --git a/tests/qemu-iotests/030.out b/tests/qemu-iotests/030.out
index 42314e9c00..4fd1c2dcd2 100644
--- a/tests/qemu-iotests/030.out
+++ b/tests/qemu-iotests/030.out
@@ -1,5 +1,5 @@
-
+.
 --
-Ran 24 tests
+Ran 25 tests
 
 OK
-- 
2.11.0

[Qemu-devel] [Bug 1801073] Re: util/zbin.c:390:37: error: absolute value function 'abs' given an argument of type 'long int' but has parameter of type 'int' which may cause truncation of value [-Werro

[Peter Maydell]

In QEMU commit fd813c72392a712022d5d75a9 we upgraded our ipxe, so this
bug should now be fixed in git master and in the upcoming 4.0 release.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  util/zbin.c:390:37: error: absolute value function 'abs' given an
  argument of type 'long int' but has parameter of type 'int' which may
  cause truncation of value [-Werror=absolute-value]

Status in QEMU:
  Fix Committed

Bug description:
  For qemu-3.0.0 I see with GCC 9 compiler a new warning:

  $ make -j1 -C roms pxerom VERBOSE=1 V=1
  make: Entering directory '/home/abuild/rpmbuild/BUILD/qemu-3.0.0/roms'
  make -C ipxe/src CONFIG=qemu \
PACKAGING_TIMESTAMP=1534273834 \
CROSS_COMPILE= \
bin/8086100e.rom bin/808610d3.rom bin/80861209.rom bin/10500940.rom 
bin/10222000.rom bin/10ec8139.rom bin/1af41000.rom bin/15ad07b0.rom
  make[1]: Entering directory 
'/home/abuild/rpmbuild/BUILD/qemu-3.0.0/roms/ipxe/src'
  gcc  -Wall -W -Wformat-nonliteral -O2 -g -Werror util/zbin.c -llzma -o 
util/zbin
  util/zbin.c: In function 'process_zinfo_add':
  util/zbin.c:390:37: error: absolute value function 'abs' given an argument of 
type 'long int' but has parameter of type 'int' which may cause truncation of 
value [-Werror=absolute-value]
390 |  ( ( addend < 0 ) ? "-" : "" ), abs ( addend ), size,
| ^~~
  util/zbin.c:398:37: error: absolute value function 'abs' given an argument of 
type 'long int' but has parameter of type 'int' which may cause truncation of 
value [-Werror=absolute-value]
398 |  ( ( addend < 0 ) ? "-" : "" ), abs ( addend ), size,
| ^~~
  util/zbin.c:419:37: error: absolute value function 'abs' given an argument of 
type 'long int' but has parameter of type 'int' which may cause truncation of 
value [-Werror=absolute-value]
419 |  ( ( addend < 0 ) ? "-" : "" ), abs ( addend ),
| ^~~
  cc1: all warnings being treated as errors
  make[1]: *** [Makefile.housekeeping:1368: util/zbin] Error 1

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

[Qemu-devel] [Bug 1802684] Re: QEMU gui crashes on macOS Mojave

[Peter Maydell]

We think we have shaken all the bugs out of the patchset which overhauls
the Cocoa UI, so the crashes on OSX Mojave should be fixed in QEMU git
master; these will be in QEMU 4.0.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  QEMU gui crashes on macOS Mojave

Status in QEMU:
  Fix Committed

Bug description:
  QEMU release 3.0.0 as well as a recent head build

  /usr/local/Cellar/qemu/HEAD-03c1ca1 (147 files, 257.2MB)
Built from source on 2018-11-06 at 13:41:32 with: --with-gtk+3 --with-sdl2 
--with-libusb
  /usr/local/Cellar/qemu/3.0.0 (137 files, 261.6MB) *
Poured from bottle on 2018-11-10 at 22:58:32 with: --with-gtk+3 
--with-libusb --with-sdl2

  Crashes when attempting to use any gui interface (tried SDL and
  default Cocoa):

  2018-11-10 22:58:41.799 qemu-system-aarch64[42982:1102466] *** Terminating 
app due to uncaught exception 'NSInternalInconsistencyException', reason: 
'NSWindow drag regions should only be invalidated on the Main Thread!'
  *** First throw call stack:
  (
0   CoreFoundation  0x7fff3ea96ecd 
__exceptionPreprocess + 256
1   libobjc.A.dylib 0x7fff6ab49720 
objc_exception_throw + 48
2   CoreFoundation  0x7fff3eab095d 
-[NSException raise] + 9
3   AppKit  0x7fff3bfb13fa 
-[NSWindow(NSWindow_Theme) 
_postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
4   AppKit  0x7fff3bfb6850 -[NSView 
setFrameSize:] + 2082
5   AppKit  0x7fff3c02747d 
-[NSVisualEffectView setFrameSize:] + 171
6   AppKit  0x7fff3c0811b1 
-[NSTitlebarView setFrameSize:] + 84
7   AppKit  0x7fff3bfb5859 -[NSView 
setFrame:] + 478
8   AppKit  0x7fff3c081154 
-[NSTitlebarView resizeWithOldSuperviewSize:] + 100
9   AppKit  0x7fff3bfbc95e -[NSView 
resizeSubviewsWithOldSize:] + 502
10  AppKit  0x7fff3bfb66d9 -[NSView 
setFrameSize:] + 1707
11  AppKit  0x7fff3c9773c0 
-[NSTitlebarContainerView setFrameSize:] + 142
12  AppKit  0x7fff3bfb5859 -[NSView 
setFrame:] + 478
13  AppKit  0x7fff3bfbcdb5 -[NSView 
resizeWithOldSuperviewSize:] + 776
14  AppKit  0x7fff3bfbc95e -[NSView 
resizeSubviewsWithOldSize:] + 502
15  AppKit  0x7fff3bfb66d9 -[NSView 
setFrameSize:] + 1707
16  AppKit  0x7fff3c024570 
-[NSThemeFrame setFrameSize:] + 495
17  AppKit  0x7fff3c011223 -[NSWindow 
_setFrame:updateBorderViewSize:] + 966
18  AppKit  0x7fff3c010b46 -[NSWindow 
_oldPlaceWindow:] + 547
19  AppKit  0x7fff3c010151 -[NSWindow 
_setFrameCommon:display:stashSize:] + 3006
20  AppKit  0x7fff3c00f57d -[NSWindow 
_setFrame:display:allowImplicitAnimation:stashSize:] + 192
21  AppKit  0x7fff3c019ff8 -[NSWindow 
setFrame:display:animate:] + 567
22  qemu-system-aarch64 0x00010b7b2abf 
qemu-system-aarch64 + 3668671
23  qemu-system-aarch64 0x00010b7b6356 
qemu-system-aarch64 + 3683158
24  qemu-system-aarch64 0x00010b7ad836 
qemu-system-aarch64 + 3647542
25  qemu-system-aarch64 0x00010b4ce769 
qemu-system-aarch64 + 636777
26  qemu-system-aarch64 0x00010b487c24 
qemu-system-aarch64 + 347172
27  qemu-system-aarch64 0x00010b487a15 
qemu-system-aarch64 + 346645
28  qemu-system-aarch64 0x00010b4878f1 
qemu-system-aarch64 + 346353
29  qemu-system-aarch64 0x00010b4414aa 
qemu-system-aarch64 + 58538
30  qemu-system-aarch64 0x00010b4f78c3 
qemu-system-aarch64 + 805059
31  qemu-system-aarch64 0x00010b487c24 
qemu-system-aarch64 + 347172
32  qemu-system-aarch64 0x00010b487a15 
qemu-system-aarch64 + 346645
33  qemu-system-aarch64 0x00010b4878f1 
qemu-system-aarch64 + 346353
34  qemu-system-aarch64 0x00010b4b8f57 
qemu-system-aarch64 + 548695
35  qemu-system-aarch64 0x00010b49c3af 
qemu-system-aarch64 + 431023
36  ??? 

[Qemu-devel] [Bug 1798780] Re: hw/usb/dev-mtp.c:1616: bad test ?

[Peter Maydell]

Fixed by commit 49f9e8d660d4 which will be in QEMU 4.0.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  hw/usb/dev-mtp.c:1616: bad test ?

Status in QEMU:
  Fix Committed

Bug description:
  hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively
  exhaustive tests is always true [-Wlogical-op]

  Source code is

  if ((ret == -1) && (errno != EINTR || errno != EAGAIN ||
  errno != EWOULDBLOCK)) {

  Maybe better code

  if ((ret == -1) && (errno != EINTR && errno != EAGAIN &&
  errno != EWOULDBLOCK)) {

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

[Qemu-devel] [Bug 1794187] Re: improve error message, when using raspi3 and RAM>4G

[Peter Maydell]

** Tags added: arm

** Changed in: qemu
   Status: New => Confirmed

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

Title:
  improve error message, when using raspi3 and RAM>4G

Status in QEMU:
  Confirmed

Bug description:
  Running `qemu-system-aarch64 image-aarch64.iso --machine raspi3 -m 8G`
  prints this error message:

  ```
  Unexpected error in visit_type_uintN() at 
/builddir/build/BUILD/qemu-3.0.0/qapi/qapi-visit-core.c:164:
  qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t
  ```

  The problem is, that you musn't use more than 4 GB RAM for machine
  raspi3. As it took me some time to figure that out, I'd be glad, if
  you can print better error message, like you do, when using more than
  4 CPU cores with machine raspi3:

  ```
  Invalid SMP CPUs 8. The max CPUs supported by machine 'raspi3' is 4 
  ```

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

Re: [Qemu-devel] [PULL 26/27] pc: Support firmware configuration with -blockdev

[Markus Armbruster]

Laszlo Ersek  writes:

> Hi Markus,
>
> (+Michal, Peter)
>
> On 03/11/19 23:08, Markus Armbruster wrote:
>> The PC machines put firmware in ROM by default.  To get it put into
>> flash memory (required by OVMF), you have to use -drive
>> if=pflash,unit=0,... and optionally -drive if=pflash,unit=1,...
>> 
>> Why two -drive?  This permits setting up one part of the flash memory
>> read-only, and the other part read/write.  It also makes upgrading
>> firmware on the host easier.  Below the hood, it creates two separate
>> flash devices, because we were too lazy to improve our flash device
>> models to support sector protection.
>> 
>> The problem at hand is to do the same with -blockdev somehow, as one
>> more step towards deprecating -drive.
>> 
>> Mapping -drive if=none,... to -blockdev is a solved problem.  With
>> if=T other than if=none, -drive additionally configures a block device
>> frontend.  For non-onboard devices, that part maps to -device.  Also a
>> solved problem.  For onboard devices such as PC flash memory, we have
>> an unsolved problem.
>> 
>> This is actually an instance of a wider problem: our general device
>> configuration interface doesn't cover onboard devices.  Instead, we have
>> a zoo of ad hoc interfaces that are much more limited.  One of them is
>> -drive, which we'd rather deprecate, but can't until we have suitable
>> replacements for all its uses.
>> 
>> Sadly, I can't attack the wider problem today.  So back to the narrow
>> problem.
>> 
>> My first idea was to reduce it to its solved buddy by using pluggable
>> instead of onboard devices for the flash memory.  Workable, but it
>> requires some extra smarts in firmware descriptors and libvirt.  Paolo
>> had an idea that is simpler for libvirt: keep the devices onboard, and
>> add machine properties for their block backends.
>> 
>> The implementation is less than straightforward, I'm afraid.
>> 
>> First, block backend properties are *qdev* properties.  Machines can't
>> have those, as they're not devices.  I could duplicate these qdev
>> properties as QOM properties, but I hate that.
>> 
>> More seriously, the properties do not belong to the machine, they
>> belong to the onboard flash devices.  Adding them to the machine would
>> then require bad magic to somehow transfer them to the flash devices.
>> Fortunately, QOM provides the means to handle exactly this case: add
>> alias properties to the machine that forward to the onboard devices'
>> properties.
>> 
>> Properties need to be created in .instance_init() methods.  For PC
>> machines, that's pc_machine_initfn().  To make alias properties work,
>> we need to create the onboard flash devices there, too.  Requires
>> several bug fixes, in the previous commits.  We also have to realize
>> the devices.  More on that below.
>> 
>> If the user sets pflash0, firmware resides in flash memory.
>> pc_system_firmware_init() maps and realizes the flash devices.
>> 
>> Else, firmware resides in ROM.  The onboard flash devices aren't used
>> then.  pc_system_firmware_init() destroys them unrealized, along with
>> the alias properties.
>> 
>> The existing code to pick up drives defined with -drive if=pflash is
>> replaced by code to desugar into the machine properties.
>> 
>> Signed-off-by: Markus Armbruster 
>> Reviewed-by: Philippe Mathieu-Daudé 
>> Acked-by: Laszlo Ersek 
>> Reviewed-by: Michael S. Tsirkin 
>> Message-Id: <87ftrtux81@dusky.pond.sub.org>
>> ---
>>  hw/i386/pc.c |   2 +
>>  hw/i386/pc_sysfw.c   | 233 ---
>>  include/hw/i386/pc.h |   3 +
>>  3 files changed, 156 insertions(+), 82 deletions(-)
>
> the next patch in the series -- which is now commit e33763be7cd3 --
> updates the command line recommendation regardless of system emulation
> target / machine type. But, the series (i.e., this patch, ultimately)
> implements support for the new command line only for the PC machine types.
>
> I think the same interface should be implemented for (arm|aarch64)/virt
> too, because those machine types are covered by
> "docs/interop/firmware.json" similarly, and once Michal does the libvirt
> work for "pflash via -blockdev", libvirt will want to use uniform
> cmdline options for both sets of machine types.
>
> (Search "hw/arm/virt.c" for IF_PFLASH / create_one_flash().)
>
> ... Yes, this omission is in fact "reviewer fail" (if you allow me to
> steal that term); I should have noticed this *much* earlier. I've only
> realized now, from
> .
> Mea culpa :(
>
> (It's just as well that this is not a "correctness" but "completeness"
> kind of problem -- whatever has been committed thus far should be OK.)

I'll look into it.  Thanks!

[Qemu-devel] [Bug 1807675] Re: qemu commit 80422b0: tcg.c crash in temp_load

[Peter Maydell]

(Still repros as of commit d37bfe142382fa82585.)


** Changed in: qemu
   Status: New => Confirmed

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

Title:
  qemu commit 80422b0: tcg.c crash in temp_load

Status in QEMU:
  Confirmed

Bug description:
  As discussed in #1803160 I'm opening a new ticket for the new bug.

  QEMU version:
  -

  qemu from git, master branch commit
  80422b00196a7af4c6efb628fae0ad8b644e98af

  Summary:
  

  TCG crashes in i386 and x86_64 when it tries to execute some specific
  illegal instructions. When running full OS emulation, both the guest
  system and QEMU crash.

  $ qemu-i386 tcg_crash1.elf
  /home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  zsh: segmentation fault (core dumped) ./qemu/build/i386-linux-user/qemu-i386 
tcg_crash1.elf

  Invalid instructions:

  f0 invalid
  40 inc eax
  a7 cmpsd dword [esi], dword ptr es:[edi]
  48 dec eax

  Testcase:
  -

  Find ELF file attached.

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

[Qemu-devel] megasas: Unexpected response from lun 1 while scanning, scan aborted

[Dongli Zhang]

I am reporting an error that the scsi lun cannot initialize successfully when I
am emulating megasas scsi controller with qemu.

I am not sure if this is issue in qemu or linux kernel.

When 'lun=1' is specified, there is "Unexpected response from lun 1 while
scanning, scan aborted".

Everything works well if 'lun=0' is specified.


Below is the qemu cmdline involved:

-device megasas,id=scsi0 \
-device scsi-hd,drive=drive0,bus=scsi0.0,lun=1 \
-drive file=/home/zhang/img/test.img,if=none,id=drive0,format=raw


Below is the syslog related to 'scsi|SCSI'

# dmesg | grep SCSI
[0.392494] SCSI subsystem initialized
[0.460666] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
251)
[0.706788] sd 1:0:0:0: [sda] Attached SCSI disk
# dmesg | grep scsi
[0.511643] scsi host0: Avago SAS based MegaRAID driver
[0.523302] scsi 0:2:0:0: Unexpected response from lun 1 while scanning, 
scan aborted
[0.540364] scsi host1: ata_piix
[0.540780] scsi host2: ata_piix
[0.702396] scsi 1:0:0:0: Direct-Access ATA  QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5

When 'lun=1' is changed to 'lun=0', there is no issue.

Thank you very much!

Dongli Zhang

[Qemu-devel] [Bug 1810956] Re: qemu-2.12.1 crashes when running malicious bootloader.

[Peter Maydell]

I think this bug was fixed in QEMU 3.1 -- I can reproduce the assert on
3.0 but not on 3.1.


** Changed in: qemu
   Status: New => Fix Released

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

Title:
  qemu-2.12.1 crashes when running malicious bootloader.

Status in QEMU:
  Fix Released

Bug description:
  Running specific bootloader on Qemu causes fatal error and 
  hence SIGABRT in /qemu-2.12.1/tcg/tcg.c on line 2684.

  Bootloader binary code is included in attachments.
  The code was generated by assembling a valid bootloader, then
  appending random-bytes from file `/dev/urandom` to the binary file.

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

[Qemu-devel] [Bug 1811499] Re: qemu/net/colo-compare.c:288: possible pointless code duplication ?

[Peter Maydell]

The fix is now in master as commit 6d3aaa5b255ffc55a0561 and will be in
QEMU 4.0.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  qemu/net/colo-compare.c:288: possible pointless code duplication ?

Status in QEMU:
  Fix Committed

Bug description:
  qemu/net/colo-compare.c:288] -> [qemu/net/colo-compare.c:296]: (style)
  The if condition is the same as the previous if condition

  Source code is

  if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) {
  if (colo_compare_packet_payload(ppkt, spkt,
  ppkt->header_size, spkt->header_size,
  ppkt->payload_size)) {
  *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY;
  return true;
  }
  }
  if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) {
  if (colo_compare_packet_payload(ppkt, spkt,
  ppkt->header_size, spkt->header_size,
  ppkt->payload_size)) {
  *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY;
  return true;
  }
  }

  Maybe the second block was supposed to be different ?

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

Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

[Markus Armbruster]

Laszlo Ersek  writes:

> On 03/26/19 07:17, Markus Armbruster wrote:
>> Zheng Xiang  writes:
>> 
>>> Hi Peter,
>>>
>>> Thanks for your reply!
>>>
>>> On 2019/3/25 21:11, Peter Maydell wrote:
 On Mon, 25 Mar 2019 at 12:53, Xiang Zheng  wrote:
>
> Currently we fill the VIRT_FLASH space with two 64MB NOR images when
> using persistent UEFI variables on QEMU. Actually we only use a very
> small part of the memory while the rest significant large part of
> memory is wasted.
>
> This patch creates and maps a variable size of flash device instead of
> a mandatory 64MB one to save memory.
>
> Signed-off-by: Xiang Zheng 
> ---
>
> This patch might be insufficient since it also needs to modify the flash 
> size
> in ACPI and DTB.
>
> BTW, I don't understand why it requires the two NOR images to be exactly 
> 64MB
> in size when using -pflash.

 I don't think we should do this. The board should in general
 create the same hardware visible to the guest, not change
 it based on subtle things like the size of the image files.
>> 
>> Concur.
>> 
 The reason why the flash images must be 64MB in size
 when using -pflash is that they are the backing store
 for a writable device. Suppose you have 1MB of data in your
 backing image that you pass to QEMU and then the guest writes
 to the last block of the flash device. The new data
 written by the guest to the end of the device has to be
 stored somewhere, so the file has to be large enough
 to cover the whole of the flash area.

>>>
>>> Is there any way to support config or limit the size that both
>>> guest and QEMU are visible?
>>>
>>> The original QEMU_EFI.fd has only 2M, but we need to stuff it
>>> to 64M with 62M unused data. It will consume a large amount of
>>> memory when running multiple VM simultaneously.
>> 
>> Here's a number of ideas.
>> 
>> The first one is of course making the flash memory size configurable, to
>> eliminate the "unused" part.  Our PC machines use the backing image
>> sizes as configuration.  I consider that a bad idea that should not be
>> allowed to spread to other machines.  Peter seems to agree.
>
> For the full picture, we have to realize that flash size is a trade-off
> for virtual machines too, not just for physical machines. UEFI firmware
> tends to grow like an OS -- whether that's good or bad belongs on
> another page :) --, and so you tend to need more and more space for it,
> even after Link Time Optimization, and image compression, over time.

Same for physical and virtual machines.

> So you are left with a choice.
>
> * You can let board logic size the flash dynamically at startup (and
> then call it a "bad idea" :) ).
>
> * Alternatively, you can hardcode the pflash size in the board setup,
> perhaps depdent on machine type version, and/or dependent on some
> properties.

The difference between getting flash memory size from the backend
vs. getting it from a machine type or property is implicit vs. explicit
configuration.

Implicit vs. explicit can have ramifications beyond the user interface.
For instance, if we ever get around to transferring device configuration
in the migration stream, the machine property would surely be part of
that, but the size of the backend won't.

> Even assuming that this diversity doesn't break migration at
> once,

I doubt explicit could break anything that implicit couldn't :)

>   you'll create a dependency between firmware releases (sizes) and
> machine types. 'For the next release of ArmVirtQemu/edk2, you'll need
> "virt-4.1" or later'.

Yes if you tie the size to the machine type.  No if you get it from a
machine property.

> In addition, in most cases, the firmware, when it runs from flash,
> cannot dynamically adapt itself to random flash sizes and/or base
> addresses, so not only will new (larger) firmware not fit on old machine
> types, but old (small) firmware may also not feel "at home" on new
> machine types. (Note: this is not a theoretical limitation, but it is a
> *very* practical one.)

The exact same problem exists for physical machines.  You can revise
your firmware only within limits set by the board.

I don't mean to say this problem isn't worth avoiding for virtual
machines.  Only that it is neither new nor intractable.

> That's a kind of mapping that is taken for "obvious" in the physical
> world (you get the board, your firmware comes with it, that's why it's
> called *firm*), but it used to be frowned upon in the virtual world.

I'm willing to give developers of virtual firmware more flexibility than
they get in the physical world.  I just happen to dislike "implicit" and
"any multiple of 4KiB up to a limit" (because physical flash chips with
sizes like 64140KiB do not exist, and virtual ones should not).

> * Or else, you pad the pflash chips as broadly as you dare, in order to
> never run into the above mess -- and then 

Re: [Qemu-devel] [PULL 0/7] Block layer patches

[Peter Maydell]

On Tue, 26 Mar 2019 at 15:52, Kevin Wolf  wrote:
>
> The following changes since commit 527266f324def9f7f392fe3b0dd940cb8dc699d9:
>
>   Merge remote-tracking branch 'remotes/armbru/tags/pull-pflash-2019-03-26' 
> into staging (2019-03-26 09:57:07 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to c6e3f520c802c5cb2de80576aba7f9f1fe985d8b:
>
>   qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK (2019-03-26 11:37:51 +0100)
>
> 
> Block layer patches:
>
> - Fix slow pre-zeroing in qemu-img convert
> - Test case for block job pausing on I/O errors
>
> 

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PATCH] ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input device

[Peter Maydell]

On Thu, 21 Mar 2019 at 07:10, Chen Zhang  wrote:
>
> In fullscreen mode, the window property of cocoaView may not be the key
> window, and the current implementation would not grab mouse in
> fullscreen mode after left clicks on relative input devices.
>
> This patch used isFullscreen value as a short-cirtuit condition for
> relative input device grabbing.
>
> Note that this patch should be tested after applying a previous patch
> which fixed event location conversion for relative input devices.
>
> Signed-off-by: Chen Zhang 

Can you explain in more detail when this patch makes a
difference, please? (for instance, a set of instructions
for reproducing the issue).

I'm confused, because in the toggleFullScreen method, when
we switch to full screen mode (which is the only place where
we set isFullscreen to true) we always do a [self grabMouse].
So if we get into the event handling function and isFullscreen
is true, I think the mouse should already be grabbed. What
am I missing ?

thanks
-- PMM

Re: [Qemu-devel] [PATCH] vl: Fix to create migration object before block backends again

[Anthony PERARD]

On Tue, Mar 26, 2019 at 03:58:52PM +, Anthony PERARD wrote:
> On Wed, Mar 13, 2019 at 09:43:30AM +0100, Markus Armbruster wrote:
> > Recent commit cda4aa9a5a0 moved block backend creation before machine
> > property evaluation.  This broke qemu-iotests 055.  Turns out we need
> > to create the migration object before block backends, so block
> > backends can add migration blockers.  Fix by calling
> > migration_object_init() earlier, right before configure_blockdev().
> > 
> > Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
> > Reported-by: Kevin Wolf 
> > Signed-off-by: Markus Armbruster 
> 
> Hi,
> 
> After this patch is applied, migration with Xen doesn't work anymore.
> When QEMU on the receiving end is started, it prints:
> qemu-system-i386: load of migration failed: Invalid argument

I should have quote this from QEMU stderr instead of the single line
abrove:
qemu-system-i386: Configuration section missing
qemu-system-i386: load of migration failed: Invalid argument

> > +/*
> > + * Migration object can only be created after global properties
> > + * are applied correctly.
> > + */
> > +migration_object_init();
> 
> I think it's because migration_object_init() is now called before
> configure_accelerator(). xen_accel_class_init() have some compat_props
> for migration.
> 
> Any idea how to fix this?

-- 
Anthony PERARD

Re: [Qemu-devel] [PATCH v2] ui/cocoa: Fix absolute input device grabbing issues on Mojave

[Peter Maydell]

On Tue, 19 Mar 2019 at 03:51, Chen Zhang  wrote:
>
> On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
> the cursor in re-entry into the virtual screen area. In some cases,
> the `window` property of NSEvent object is nil, after exit of cursor,
> meaning that the `-locationInWindow` method would return value in screen
> coordinates. Current implementation used raw locations from NSEvent
> without considering whether the value was for the window coordinates or
> the macOS screen coordinates, nor was the zooming factor for Zoom-to-Fit
> included for fullscreen mode.
>
> In fullscreen mode, the fullscreen cocoa window might not be the key
> window, therefore location of event in virtual coordinates should suffice
> for the condition of grabbing.
>
> This patch fixed boundary check methods for cursor in normal and fullscreen
> with/without Zoom-to-Fit on macOS Mojave.
>
> Signed-off-by: Chen Zhang 
> ---
>  ui/cocoa.m | 39 +--
>  1 file changed, 37 insertions(+), 2 deletions(-)
>

Hi; this doesn't compile for me, I'm afraid. I've appended the full
compiler error log, but the problem seems to be that
the convertPointFromScreen method of NSWindow doesn't exist.
I'm not entirely sure why, since the API docs say that method
was introduced in OSX 10.12 and I'm running 10.13.6, but
at least at the moment our minimum OSX version is 10.10,
so we need something to handle that anyway.

(http://codeworkshop.net/objc-diff/sdkdiffs/macos/10.14/AppKit.html
suggests that maybe the docs are wrong and this method
was only added in 10.14; that would certainly fit the symptoms.)


/Users/pm215/src/qemu/ui/cocoa.m:414:35: warning: instance method
'-convertPointFromScreen:' not found
  (return type defaults to 'id') [-Wobjc-method-access]
return [[self window] convertPointFromScreen:[ev locationInWindow]];
  ^~
/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:191:12:
note: receiver is instance of class declared here
@interface NSWindow : NSResponder 

[Qemu-devel] [Bug 1821771] [NEW] KVM guest does not reflect numa distances configured through qemu

[Satheesh Rajendran]

Public bug reported:

KVM guest does not reflect numa distances configured through qemu

Env:
Host/Guest Kernel: 5.1.0-rc1-g72999bbdc
qemu : 3.1.90 (v2.8.0-rc0-18614-g278aebafa0-dirty) [repo: 
https://github.com/dgibson/qemu; branch:ppc-for-4.1 ]
# git log -1
commit 278aebafa02f699857ca082d966bcbc05dc9bffb (HEAD -> ppc-for-4.1)
Author: Jafar Abdi 
Date:   Sat Mar 23 17:26:36 2019 +0300

tests/libqos: fix usage of bool in pci-spapr.c

Clean up wrong usage of FALSE and TRUE in places that use "bool" from 
stdbool.h.

FALSE and TRUE (with capital letters) are the constants defined by glib for
being used with the "gboolean" type of glib. But some parts of the code 
also use
TRUE and FALSE for variables that are declared as "bool" (the type from 
).

Signed-off-by: Jafar Abdi 
Reviewed-by: Eric Blake 
Message-Id: <1553351197-14581-4-git-send-email-cafer.a...@gmail.com>
Signed-off-by: David Gibson 

# libvirtd -V
libvirtd (libvirt) 5.1.0


Steps to reproduce:
1. Boot attached guest xml with predefined numa distance.

qemu-commandline:
/usr/share/avocado-plugins-vt/bin/install_root/bin/qemu-system-ppc64 -name 
guest=vm2,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-vm2/master-key.aes
 -machine pseries-4.0,accel=kvm,usb=off,dump-guest-core=off -m 4096 -realtime 
mlock=off -smp 4,sockets=1,cores=4,threads=1 -numa 
node,nodeid=0,cpus=0-1,mem=2048 -numa node,nodeid=1,cpus=2-3,mem=2048 -uuid 
1a870f1d-269a-4a8c-84bc-2b5bda72823a -display none -no-user-config -nodefaults 
-chardev socket,id=charmonitor,fd=28,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot 
strict=on -kernel /home/kvmci/linux/vmlinux -append root=/dev/sda2 rw 
console=tty0 console=ttyS0,115200 init=/sbin/init  initcall_debug selinux=0 
-device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device 
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive 
file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f4:f5:f6,bus=pci.0,addr=0x1 
-chardev pty,id=charserial0 -device 
spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on


2. Check numa distance and other details inside guest
# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1
node 0 size: 2025 MB
node 0 free: 1837 MB
node 1 cpus: 2 3
node 1 size: 2045 MB
node 1 free: 1646 MB
node distances:
node   0   1 
  0:  10  40 ---NOK
  1:  40  10 

# lsprop /proc/device-tree/cpus/PowerPC\,POWER9\@*/ibm\,associativity 
/proc/device-tree/cpus/PowerPC,POWER8@0/ibm,associativity
 0005     
/proc/device-tree/cpus/PowerPC,POWER8@10/ibm,associativity
 0005    0001 0010
/proc/device-tree/cpus/PowerPC,POWER8@18/ibm,associativity
 0005    0001 0018
/proc/device-tree/cpus/PowerPC,POWER8@8/ibm,associativity
 0005     0008

# lsprop /proc/device-tree/rtas/ibm,associativity-reference-points
/proc/device-tree/rtas/ibm,associativity-reference-points
 0004 0004

Expected numa distances:
node distances:
node   0   1 
  0:  10  20
  1:  20  10

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: kvm numa powerpc

** Attachment added: "guest xml"
   
https://bugs.launchpad.net/bugs/1821771/+attachment/5249507/+files/guest_xml.txt

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

Title:
  KVM guest does not reflect numa distances configured through qemu

Status in QEMU:
  New

Bug description:
  KVM guest does not reflect numa distances configured through qemu

  Env:
  Host/Guest Kernel: 5.1.0-rc1-g72999bbdc
  qemu : 3.1.90 (v2.8.0-rc0-18614-g278aebafa0-dirty) [repo: 
https://github.com/dgibson/qemu; branch:ppc-for-4.1 ]
  # git log -1
  commit 278aebafa02f699857ca082d966bcbc05dc9bffb (HEAD -> ppc-for-4.1)
  Author: Jafar Abdi 
  Date:   Sat Mar 23 17:26:36 2019 +0300

  tests/libqos: fix usage of bool in pci-spapr.c
  
  Clean up wrong usage of FALSE and TRUE in places that use "bool" from 
stdbool.h.
  
  FALSE and TRUE (with capital letters) are the constants defined by glib 
for
  being used with the "gboolean" type of glib. But some parts of the code 
also use
  TRUE and FALSE for variables that are declared as "bool" (the type from 
).
  
  Signed-off-by: Jafar Abdi 
  

Re: [Qemu-devel] [PATCH for 4.1 v2 10/13] tests: acpi: add simple arm/virt testcase

[Igor Mammedov]

On Tue, 26 Mar 2019 15:27:39 +0100
Laszlo Ersek  wrote:

> On 03/26/19 14:09, Igor Mammedov wrote:
> > adds simple arm/virt test case that starts guest with
> > bios-tables-test.aarch64.iso.qcow2 boot image which
> > initializes UefiTestSupport* structure in RAM once
> > guest is booted.
> > 
> >  * see commit: tests: acpi: add acpi_find_rsdp_address_uefi() helper
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > v3:
> >   * use firmware blobs directly from pc-bios directory
> >   * use bios-tables-test.aarch64.iso.qcow2 as test boot image
> > v2:
> >   * specify in test_data where board's RAM starts and RAM size
> > ---
> >  tests/Makefile.include   |  1 +
> >  tests/bios-tables-test.c | 17 +
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > index 0a0e1c3..0619751 100644
> > --- a/tests/Makefile.include
> > +++ b/tests/Makefile.include
> > @@ -269,6 +269,7 @@ check-qtest-arm-y += tests/hexloader-test$(EXESUF)
> >  check-qtest-aarch64-y = tests/numa-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/migration-test$(EXESUF)
> > +qtest-uefi-images-aarch64 = edk2-aarch64-code.fd.xz edk2-arm-vars.fd.xz
> >  
> >  check-qtest-microblazeel-y += $(check-qtest-microblaze-y)
> >  
> 
> What is this hunk needed for?
> 
> I'm asking because it can't work on top of my v3 posting ("[PATCH
> for-4.1 v3 00/12] bundle edk2 platform firmware  with QEMU") -- that
> version provides *.bz2 files, not *.xz files.
> 
> In addition, the rest of your patch refers to the decompressed (*.fd)
> images -- and that is correct, in fact, given that my patches
> 
> * [PATCH for-4.1 v3 10/12]
>   tests: add missing dependency to build QTEST_QEMU_BINARY, round 2
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06140.html
> 
> * [PATCH for-4.1 v3 11/12]
>   Makefile: install the edk2 firmware images and their descriptors
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06138.html
> 
> make sure that the images are decompressed for testing too.
> 
> So, in the end, this hunk should be dropped, IMO.

I know, I've just missed it during clean up. I'll fix it up.

> > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> > index 097ef03..b5cb425 100644
> > --- a/tests/bios-tables-test.c
> > +++ b/tests/bios-tables-test.c
> > @@ -804,6 +804,21 @@ static void test_acpi_piix4_tcg_dimm_pxm(void)
> >  test_acpi_tcg_dimm_pxm(MACHINE_PC);
> >  }
> >  
> > +static void test_acpi_virt_tcg(void)
> > +{
> > +test_data data = {
> > +.machine = "virt",
> > +.uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > +.uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > +.cd = 
> > "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2",
> > +.ram_start = 0x4000ULL,
> > +.scan_len = 128ULL * 1024 * 1024,
> > +};
> 
> (Feel free to ignore this one:)
> 
> you might want to beautify both constants using the macros from
> "qemu/units.h": 1 * GiB, and 128 * MiB.

I prefer to use a less as possible code from QEMU in tests lest we break the 
later so tests would notice.
(it probably doesn't matter much in this case)

> 
> > +
> > +test_acpi_one("-cpu cortex-a57 ", );
> > +free_test_data();
> > +}
> > +
> >  int main(int argc, char *argv[])
> >  {
> >  const char *arch = qtest_get_arch();
> > @@ -831,6 +846,8 @@ int main(int argc, char *argv[])
> >  qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
> >  qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
> >  qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
> > +} else if (strcmp(arch, "aarch64") == 0) {
> > +qtest_add_func("acpi/virt", test_acpi_virt_tcg);
> >  }
> >  ret = g_test_run();
> >  boot_sector_cleanup(disk);
> > 
> 
> With the Makefile.include hunk dropped (and regardless of the constants):
> 
> Reviewed-by: Laszlo Ersek 

Thanks!

> 
> Thanks,
> Laszlo

[Qemu-devel] [PULL 6/7] qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing

[Kevin Wolf]

If qemu-img convert sees that the target image isn't zero-initialised
yet, it tries to do an efficient zero write for the whole image first
to save the overhead of repeated explicit zero writes during the
conversion. Obviously, this provides only an advantage if the
pre-zeroing is actually efficient. Otherwise, we can end up writing
zeroes slowly while zeroing out the whole image, and then overwrite the
same blocks again with real data, potentially doubling the written data.

Pass BDRV_REQ_NO_FALLBACK to blk_make_zero() to avoid this case. If we
can't efficiently zero out, we'll instead write explicit zeroes only if
there is no data to be written to a block.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 qemu-img.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qemu-img.c b/qemu-img.c
index 5fac840742..8ee63daeae 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1932,7 +1932,7 @@ static int convert_do_copy(ImgConvertState *s)
 if (!s->has_zero_init && !s->target_has_backing &&
 bdrv_can_write_zeroes_with_unmap(blk_bs(s->target)))
 {
-ret = blk_make_zero(s->target, BDRV_REQ_MAY_UNMAP);
+ret = blk_make_zero(s->target, BDRV_REQ_MAY_UNMAP | 
BDRV_REQ_NO_FALLBACK);
 if (ret == 0) {
 s->has_zero_init = true;
 }
-- 
2.20.1

Re: [Qemu-devel] [PATCH] vl: Fix to create migration object before block backends again

[Anthony PERARD]

On Wed, Mar 13, 2019 at 09:43:30AM +0100, Markus Armbruster wrote:
> Recent commit cda4aa9a5a0 moved block backend creation before machine
> property evaluation.  This broke qemu-iotests 055.  Turns out we need
> to create the migration object before block backends, so block
> backends can add migration blockers.  Fix by calling
> migration_object_init() earlier, right before configure_blockdev().
> 
> Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
> Reported-by: Kevin Wolf 
> Signed-off-by: Markus Armbruster 

Hi,

After this patch is applied, migration with Xen doesn't work anymore.
When QEMU on the receiving end is started, it prints:
qemu-system-i386: load of migration failed: Invalid argument

> +/*
> + * Migration object can only be created after global properties
> + * are applied correctly.
> + */
> +migration_object_init();

I think it's because migration_object_init() is now called before
configure_accelerator(). xen_accel_class_init() have some compat_props
for migration.

Any idea how to fix this?

Thanks,

-- 
Anthony PERARD

[Qemu-devel] [PULL 7/7] qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK

[Kevin Wolf]

This makes the new BDRV_REQ_NO_FALLBACK flag available in the qemu-io
write command.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 qemu-io-cmds.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 35dcdcf413..09750a23ce 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -946,6 +946,7 @@ static void write_help(void)
 " -b, -- write to the VM state rather than the virtual disk\n"
 " -c, -- write compressed data with blk_write_compressed\n"
 " -f, -- use Force Unit Access semantics\n"
+" -n, -- with -z, don't allow slow fallback\n"
 " -p, -- ignored for backwards compatibility\n"
 " -P, -- use different pattern to fill file\n"
 " -C, -- report statistics in a machine parsable format\n"
@@ -964,7 +965,7 @@ static const cmdinfo_t write_cmd = {
 .perm   = BLK_PERM_WRITE,
 .argmin = 2,
 .argmax = -1,
-.args   = "[-bcCfquz] [-P pattern] off len",
+.args   = "[-bcCfnquz] [-P pattern] off len",
 .oneline= "writes a number of bytes at a specified offset",
 .help   = write_help,
 };
@@ -983,7 +984,7 @@ static int write_f(BlockBackend *blk, int argc, char **argv)
 int64_t total = 0;
 int pattern = 0xcd;
 
-while ((c = getopt(argc, argv, "bcCfpP:quz")) != -1) {
+while ((c = getopt(argc, argv, "bcCfnpP:quz")) != -1) {
 switch (c) {
 case 'b':
 bflag = true;
@@ -997,6 +998,9 @@ static int write_f(BlockBackend *blk, int argc, char **argv)
 case 'f':
 flags |= BDRV_REQ_FUA;
 break;
+case 'n':
+flags |= BDRV_REQ_NO_FALLBACK;
+break;
 case 'p':
 /* Ignored for backwards compatibility */
 break;
@@ -1037,6 +1041,11 @@ static int write_f(BlockBackend *blk, int argc, char 
**argv)
 return -EINVAL;
 }
 
+if ((flags & BDRV_REQ_NO_FALLBACK) && !zflag) {
+printf("-n requires -z to be specified\n");
+return -EINVAL;
+}
+
 if ((flags & BDRV_REQ_MAY_UNMAP) && !zflag) {
 printf("-u requires -z to be specified\n");
 return -EINVAL;
-- 
2.20.1

[Qemu-devel] [PULL 3/7] block: Add BDRV_REQ_NO_FALLBACK

[Kevin Wolf]

For qemu-img convert, we want an operation that zeroes out the whole
image if this can be done efficiently, but that returns an error
otherwise so we don't write explicit zeroes and immediately overwrite
them with the real data, potentially doubling the amount of data to be
written.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 include/block/block.h |  7 ++-
 block/io.c| 12 +++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/include/block/block.h b/include/block/block.h
index e452988b66..c7a26199aa 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -83,8 +83,13 @@ typedef enum {
  */
 BDRV_REQ_SERIALISING= 0x80,
 
+/* Execute the request only if the operation can be offloaded or otherwise
+ * be executed efficiently, but return an error instead of using a slow
+ * fallback. */
+BDRV_REQ_NO_FALLBACK= 0x100,
+
 /* Mask of valid flags */
-BDRV_REQ_MASK   = 0xff,
+BDRV_REQ_MASK   = 0x1ff,
 } BdrvRequestFlags;
 
 typedef struct BlockSizes {
diff --git a/block/io.c b/block/io.c
index 952372c2bb..dfc153b8d8 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1015,6 +1015,7 @@ static int coroutine_fn 
bdrv_driver_preadv(BlockDriverState *bs,
 unsigned int nb_sectors;
 
 assert(!(flags & ~BDRV_REQ_MASK));
+assert(!(flags & BDRV_REQ_NO_FALLBACK));
 
 if (!drv) {
 return -ENOMEDIUM;
@@ -1061,6 +1062,7 @@ static int coroutine_fn 
bdrv_driver_pwritev(BlockDriverState *bs,
 int ret;
 
 assert(!(flags & ~BDRV_REQ_MASK));
+assert(!(flags & BDRV_REQ_NO_FALLBACK));
 
 if (!drv) {
 return -ENOMEDIUM;
@@ -1467,6 +1469,10 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 return -ENOMEDIUM;
 }
 
+if ((flags & ~bs->supported_zero_flags) & BDRV_REQ_NO_FALLBACK) {
+return -ENOTSUP;
+}
+
 assert(alignment % bs->bl.request_alignment == 0);
 head = offset % alignment;
 tail = (offset + bytes) % alignment;
@@ -1510,7 +1516,7 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 assert(!bs->supported_zero_flags);
 }
 
-if (ret == -ENOTSUP) {
+if (ret == -ENOTSUP && !(flags & BDRV_REQ_NO_FALLBACK)) {
 /* Fall back to bounce buffer if write zeroes is unsupported */
 BdrvRequestFlags write_flags = flags & ~BDRV_REQ_ZERO_WRITE;
 
@@ -2949,6 +2955,10 @@ static int coroutine_fn bdrv_co_copy_range_internal(
 BdrvTrackedRequest req;
 int ret;
 
+/* TODO We can support BDRV_REQ_NO_FALLBACK here */
+assert(!(read_flags & BDRV_REQ_NO_FALLBACK));
+assert(!(write_flags & BDRV_REQ_NO_FALLBACK));
+
 if (!dst || !dst->bs) {
 return -ENOMEDIUM;
 }
-- 
2.20.1

[Qemu-devel] [PULL 5/7] file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes

[Kevin Wolf]

We know that the kernel implements a slow fallback code path for
BLKZEROOUT, so if BDRV_REQ_NO_FALLBACK is given, we shouldn't call it.
The other operations we call in the context of .bdrv_co_pwrite_zeroes
should usually be quick, so no modification should be needed for them.
If we ever notice that there are additional problematic cases, we can
still make these conditional as well.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 include/block/raw-aio.h |  1 +
 block/file-posix.c  | 24 
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/include/block/raw-aio.h b/include/block/raw-aio.h
index 6799614e56..ba223dd1f1 100644
--- a/include/block/raw-aio.h
+++ b/include/block/raw-aio.h
@@ -40,6 +40,7 @@
 /* AIO flags */
 #define QEMU_AIO_MISALIGNED   0x1000
 #define QEMU_AIO_BLKDEV   0x2000
+#define QEMU_AIO_NO_FALLBACK  0x4000
 
 
 /* linux-aio.c - Linux native implementation */
diff --git a/block/file-posix.c b/block/file-posix.c
index d102f3b222..db4cccbe51 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -652,7 +652,7 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 }
 #endif
 
-bs->supported_zero_flags = BDRV_REQ_MAY_UNMAP;
+bs->supported_zero_flags = BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK;
 ret = 0;
 fail:
 if (filename && (bdrv_flags & BDRV_O_TEMPORARY)) {
@@ -1500,14 +1500,19 @@ static ssize_t 
handle_aiocb_write_zeroes_block(RawPosixAIOData *aiocb)
 }
 
 #ifdef BLKZEROOUT
-do {
-uint64_t range[2] = { aiocb->aio_offset, aiocb->aio_nbytes };
-if (ioctl(aiocb->aio_fildes, BLKZEROOUT, range) == 0) {
-return 0;
-}
-} while (errno == EINTR);
+/* The BLKZEROOUT implementation in the kernel doesn't set
+ * BLKDEV_ZERO_NOFALLBACK, so we can't call this if we have to avoid slow
+ * fallbacks. */
+if (!(aiocb->aio_type & QEMU_AIO_NO_FALLBACK)) {
+do {
+uint64_t range[2] = { aiocb->aio_offset, aiocb->aio_nbytes };
+if (ioctl(aiocb->aio_fildes, BLKZEROOUT, range) == 0) {
+return 0;
+}
+} while (errno == EINTR);
 
-ret = translate_err(-errno);
+ret = translate_err(-errno);
+}
 #endif
 
 if (ret == -ENOTSUP) {
@@ -2659,6 +2664,9 @@ raw_do_pwrite_zeroes(BlockDriverState *bs, int64_t 
offset, int bytes,
 if (blkdev) {
 acb.aio_type |= QEMU_AIO_BLKDEV;
 }
+if (flags & BDRV_REQ_NO_FALLBACK) {
+acb.aio_type |= QEMU_AIO_NO_FALLBACK;
+}
 
 if (flags & BDRV_REQ_MAY_UNMAP) {
 acb.aio_type |= QEMU_AIO_DISCARD;
-- 
2.20.1

[Qemu-devel] [PULL 2/7] block: Remove error messages in bdrv_make_zero()

[Kevin Wolf]

There is only a single caller of bdrv_make_zero(), which is qemu-img
convert. If the function fails, we just fall back to a different method
of zeroing out blocks on the target image. There is no good reason to
print error messages on stderr when the higher level operation will
actually succeed.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 block/io.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/block/io.c b/block/io.c
index 2ba603c7bc..952372c2bb 100644
--- a/block/io.c
+++ b/block/io.c
@@ -909,8 +909,6 @@ int bdrv_make_zero(BdrvChild *child, BdrvRequestFlags flags)
 }
 ret = bdrv_block_status(bs, offset, bytes, , NULL, NULL);
 if (ret < 0) {
-error_report("error getting block status at offset %" PRId64 ": 
%s",
- offset, strerror(-ret));
 return ret;
 }
 if (ret & BDRV_BLOCK_ZERO) {
@@ -919,8 +917,6 @@ int bdrv_make_zero(BdrvChild *child, BdrvRequestFlags flags)
 }
 ret = bdrv_pwrite_zeroes(child, offset, bytes, flags);
 if (ret < 0) {
-error_report("error writing zeroes at offset %" PRId64 ": %s",
- offset, strerror(-ret));
 return ret;
 }
 offset += bytes;
-- 
2.20.1

[Qemu-devel] [PULL 4/7] block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers

[Kevin Wolf]

Filter drivers that support .bdrv_co_pwrite_zeroes can safely advertise
BDRV_REQ_NO_FALLBACK because they just forward the request flags to
their child node.

Signed-off-by: Kevin Wolf 
Acked-by: Eric Blake 
---
 block/blkdebug.c | 2 +-
 block/copy-on-read.c | 7 +++
 block/mirror.c   | 3 ++-
 block/raw-format.c   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/block/blkdebug.c b/block/blkdebug.c
index 1ea835c2b9..efd9441625 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -401,7 +401,7 @@ static int blkdebug_open(BlockDriverState *bs, QDict 
*options, int flags,
 bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
 (BDRV_REQ_FUA & bs->file->bs->supported_write_flags);
 bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
-((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP) &
+((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
 bs->file->bs->supported_zero_flags);
 ret = -EINVAL;
 
diff --git a/block/copy-on-read.c b/block/copy-on-read.c
index d670fec42b..53972b1da3 100644
--- a/block/copy-on-read.c
+++ b/block/copy-on-read.c
@@ -34,12 +34,11 @@ static int cor_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 
 bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
-(BDRV_REQ_FUA &
-bs->file->bs->supported_write_flags);
+(BDRV_REQ_FUA & bs->file->bs->supported_write_flags);
 
 bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
-   ((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP) &
-bs->file->bs->supported_zero_flags);
+((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
+bs->file->bs->supported_zero_flags);
 
 return 0;
 }
diff --git a/block/mirror.c b/block/mirror.c
index eb9a4cdf56..ff15cfb197 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1548,7 +1548,8 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
 }
 mirror_top_bs->total_sectors = bs->total_sectors;
 mirror_top_bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED;
-mirror_top_bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED;
+mirror_top_bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
+  BDRV_REQ_NO_FALLBACK;
 bs_opaque = g_new0(MirrorBDSOpaque, 1);
 mirror_top_bs->opaque = bs_opaque;
 bdrv_set_aio_context(mirror_top_bs, bdrv_get_aio_context(bs));
diff --git a/block/raw-format.c b/block/raw-format.c
index cec29986cc..385cdc2490 100644
--- a/block/raw-format.c
+++ b/block/raw-format.c
@@ -434,7 +434,7 @@ static int raw_open(BlockDriverState *bs, QDict *options, 
int flags,
 bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
 (BDRV_REQ_FUA & bs->file->bs->supported_write_flags);
 bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
-((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP) &
+((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
 bs->file->bs->supported_zero_flags);
 
 if (bs->probed && !bdrv_is_read_only(bs)) {
-- 
2.20.1

[Qemu-devel] [PULL 1/7] iotests: add 248: test resume mirror after auto pause on ENOSPC

[Kevin Wolf]

From: Vladimir Sementsov-Ogievskiy 

Test that mirror job actually resume on resume command after being
automatically paused on ENOSPC error.

It's a follow-up test for 8d9648cbf3e
"blockjob: fix user pause in block_job_error_action"

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Tested-by: John Snow 
Reviewed-by: John Snow 
Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/248 | 71 ++
 tests/qemu-iotests/248.out |  8 +
 tests/qemu-iotests/group   |  1 +
 3 files changed, 80 insertions(+)
 create mode 100755 tests/qemu-iotests/248
 create mode 100644 tests/qemu-iotests/248.out

diff --git a/tests/qemu-iotests/248 b/tests/qemu-iotests/248
new file mode 100755
index 00..f26b4bb2aa
--- /dev/null
+++ b/tests/qemu-iotests/248
@@ -0,0 +1,71 @@
+#!/usr/bin/env python
+#
+# Test resume mirror after auto pause on ENOSPC
+#
+# Copyright (c) 2019 Virtuozzo International GmbH. All rights reserved.
+#
+# 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 iotests
+from iotests import qemu_img_create, qemu_io, file_path, filter_qmp_testfiles
+
+iotests.verify_image_format(supported_fmts=['qcow2'])
+
+source, target = file_path('source', 'target')
+size = 5 * 1024 * 1024
+limit = 2 * 1024 * 1024
+
+qemu_img_create('-f', iotests.imgfmt, source, str(size))
+qemu_img_create('-f', iotests.imgfmt, target, str(size))
+qemu_io('-c', 'write 0 {}'.format(size), source)
+
+# raw format don't like empty files
+qemu_io('-c', 'write 0 {}'.format(size), target)
+
+vm = iotests.VM().add_drive(source)
+vm.launch()
+
+blockdev_opts = {
+'driver': iotests.imgfmt,
+'node-name': 'target',
+'file': {
+'driver': 'raw',
+'size': limit,
+'file': {
+'driver': 'file',
+'filename': target
+}
+}
+}
+vm.qmp_log('blockdev-add', filters=[filter_qmp_testfiles], **blockdev_opts)
+
+vm.qmp_log('blockdev-mirror', device='drive0', sync='full', target='target',
+   on_target_error='enospc')
+
+vm.event_wait('JOB_STATUS_CHANGE', timeout=3.0,
+  match={'data': {'status': 'paused'}})
+
+# drop other cached events, to not interfere with further wait for 'running'
+vm.get_qmp_events()
+
+del blockdev_opts['file']['size']
+vm.qmp_log('x-blockdev-reopen', filters=[filter_qmp_testfiles],
+   **blockdev_opts)
+
+vm.qmp_log('block-job-resume', device='drive0')
+vm.event_wait('JOB_STATUS_CHANGE', timeout=1.0,
+  match={'data': {'status': 'running'}})
+
+vm.shutdown()
diff --git a/tests/qemu-iotests/248.out b/tests/qemu-iotests/248.out
new file mode 100644
index 00..369b25bf26
--- /dev/null
+++ b/tests/qemu-iotests/248.out
@@ -0,0 +1,8 @@
+{"execute": "blockdev-add", "arguments": {"driver": "qcow2", "file": 
{"driver": "raw", "file": {"driver": "file", "filename": 
"TEST_DIR/PID-target"}, "size": 2097152}, "node-name": "target"}}
+{"return": {}}
+{"execute": "blockdev-mirror", "arguments": {"device": "drive0", 
"on-target-error": "enospc", "sync": "full", "target": "target"}}
+{"return": {}}
+{"execute": "x-blockdev-reopen", "arguments": {"driver": "qcow2", "file": 
{"driver": "raw", "file": {"driver": "file", "filename": 
"TEST_DIR/PID-target"}}, "node-name": "target"}}
+{"return": {}}
+{"execute": "block-job-resume", "arguments": {"device": "drive0"}}
+{"return": {}}
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index d192abaecf..41da10c6cf 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -246,3 +246,4 @@
 245 rw auto
 246 rw auto quick
 247 rw auto quick
+248 rw auto quick
-- 
2.20.1

[Qemu-devel] [PULL 0/7] Block layer patches

[Kevin Wolf]

The following changes since commit 527266f324def9f7f392fe3b0dd940cb8dc699d9:

  Merge remote-tracking branch 'remotes/armbru/tags/pull-pflash-2019-03-26' 
into staging (2019-03-26 09:57:07 +)

are available in the Git repository at:

  git://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to c6e3f520c802c5cb2de80576aba7f9f1fe985d8b:

  qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK (2019-03-26 11:37:51 +0100)


Block layer patches:

- Fix slow pre-zeroing in qemu-img convert
- Test case for block job pausing on I/O errors


Kevin Wolf (6):
  block: Remove error messages in bdrv_make_zero()
  block: Add BDRV_REQ_NO_FALLBACK
  block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers
  file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes
  qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing
  qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK

Vladimir Sementsov-Ogievskiy (1):
  iotests: add 248: test resume mirror after auto pause on ENOSPC

 include/block/block.h  |  7 -
 include/block/raw-aio.h|  1 +
 block/blkdebug.c   |  2 +-
 block/copy-on-read.c   |  7 ++---
 block/file-posix.c | 24 ++--
 block/io.c | 16 +++
 block/mirror.c |  3 +-
 block/raw-format.c |  2 +-
 qemu-img.c |  2 +-
 qemu-io-cmds.c | 13 +++--
 tests/qemu-iotests/248 | 71 ++
 tests/qemu-iotests/248.out |  8 ++
 tests/qemu-iotests/group   |  1 +
 13 files changed, 133 insertions(+), 24 deletions(-)
 create mode 100755 tests/qemu-iotests/248
 create mode 100644 tests/qemu-iotests/248.out

Re: [Qemu-devel] [PATCH 0/3] migration: add sztd compression

[Denis Plotnikov]

ping ping ping ping ping!

On 18.03.2019 10:53, Denis Plotnikov wrote:
> ping ping ping ping!
> 
> On 11.03.2019 11:20, Denis Plotnikov wrote:
>> ping ping ping!
>>
>> On 04.03.2019 18:10, Denis Plotnikov wrote:
>>> ping!
>>>
>>> On 26.02.2019 16:15, Denis Plotnikov wrote:
 zstd date compression algorithm shows better performance on data 
 compression.
 It might be useful to employ the algorithm in VM migration to reduce CPU 
 usage.
 A user will be able to choose between those algorithms, therefor 
 compress-type
 migration parameter is added.

 Here are some results of performance comparison zstd vs gzip:

 host: i7-4790 8xCPU @ 3.60GHz, 16G RAM
 migration to the same host
 VM: 2xVCPU, 8G RAM total
 5G RAM used, memory populated with postgreqsl data
 produced by pgbench performance benchmark


 Threads: 1 compress – 1 decompress

 zstd provides slightly less compression ratio with almost the same
 CPU usage but copes with RAM  compression roghly 2 times faster

 compression type  zlib   |  zstd
 -
 compression level  1   5 |   1   5
 compression ratio  6.927.05  |   6.696.89
 cpu idle, %82  83|   86  80
 time, sec  49  71|   26  31
 time diff to zlib, sec  -25 -41


 Threads: 8 compress – 2 decompress

 zstd provides the same migration time with less cpu consumption

 compression type none  |gzip(zlib)|  zstd
 --
 compression level- |  1  5   9|   1   5   
 15
 compression ratio- |  6.94   6.997.14 |   6.646.89
 6.93
 time, sec154   |  22 23  27   |   23  23  
 25
 cpu idle, %  99|  45 30  12   |   70  52  
 23
 cpu idle diff to zlib  |  |  -25%-22%
 -11%


 Denis Plotnikov (3):
   migration: rework compression code for adding more data compressors
   hmp: add compress-type parameter to migration parameters
   migration: add zstd compression

  configure |  26 
  hmp.c |   8 ++
  migration/migration.c |  45 ++-
  migration/migration.h |   1 +
  migration/qemu-file.c |  39 ++
  migration/qemu-file.h |  18 ++-
  migration/ram.c   | 291 ++
  qapi/migration.json   |  26 +++-
  8 files changed, 369 insertions(+), 85 deletions(-)

>>>
>>
> 

-- 
Best,
Denis

Re: [Qemu-devel] [PATCH for 4.1 v2 09/13] tests: acpi: ignore SMBIOS tests when UEFI firmware is used

[Laszlo Ersek]

On 03/26/19 15:19, Laszlo Ersek wrote:
> On 03/26/19 14:09, Igor Mammedov wrote:
>> once FW provides a pointer to SMBIOS entry point like it does for
>> RSDP it should be possible to enable this one the same way.
>>
>> Signed-off-by: Igor Mammedov 
>> ---
>>  tests/bios-tables-test.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
>> index 91846d6..097ef03 100644
>> --- a/tests/bios-tables-test.c
>> +++ b/tests/bios-tables-test.c
>> @@ -569,8 +569,11 @@ static void test_acpi_one(const char *params, test_data 
>> *data)
>>  }
>>  }
>>  
>> -test_smbios_entry_point(data);
>> -test_smbios_structs(data);
>> +/* TODO: make SMBIOS tests work with UEFI firmware */
>> +if (!use_uefi) {
>> +test_smbios_entry_point(data);
>> +test_smbios_structs(data);
>> +}
>>  
>>  assert(!global_qtest);
>>  qtest_quit(data->qts);
>>
> 
> For now:
> 
> Reviewed-by: Laszlo Ersek 
> 
> Can you file a LP item about this, and assign it to me? (I can assign it
> to myself as well if you send me the link.)

To clarify, I'm offering to extend the UEFI helper app under
"tests/uefi-test-tools/UefiTestToolsPkg", in order to expose two new
entry point fields (one for SMBIOS 2 and another for SMBIOS 3). I'll
leave the qtest code refresh to you :)

Laszlo

> ... In fact, if we have a LP ticket, we could reference it either in the
> code comment, or in the commit message. I'll leave that up to you (you
> can keep my R-b either way).
> 
> Thanks,
> Laszlo
> 

[Qemu-devel] [Bug 1813305] Re: trace-root.h is not regerenerated after re-configure

[Peter Maydell]

This was fixed by commit 57b7bdf426445d83561, which will be in the 4.0
release.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  trace-root.h is not regerenerated after re-configure

Status in QEMU:
  Fix Committed

Bug description:
  Hi,

  I've just realized that after I reconfigured my qemu with
  ../configure 
--target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user 
--enable-trace-backends=simple

  $ make
  did rebuild some stuff for the 'simple' trace, but it did not update 
trace-root.h until after I
  $ make clean

  
  I took me while to understand why I didn't get the traces I wanted (my 
trace-root.h still thought it was configured for the default 'log').

  I didn't check how easy it is to fix this in the build system.

  Thanks

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

[Qemu-devel] [Bug 1805445] Re: QEMU arm virt machine was stopped by STMFD command while debug process

[Peter Maydell]

I think there isn't a QEMU bug to address here, so I'm going to close
this bug. Please let us know if there's anything we've missed.


** Changed in: qemu
   Status: New => Invalid

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

Title:
  QEMU arm virt machine was stopped by STMFD command while debug process

Status in QEMU:
  Invalid

Bug description:
  Hello, i have a big problem with QEMU arm virtual machine. So...
  I run QEMU machine with bare-metal ThreadX fullflash from Texet TM-333 phone  
(Spreadtrum platform)
  [CODE]qemu-system-arm -S -gdb tcp::1234,ipv4 -drive 
file=C:\cygwin64\home\flash.bin,if=mtd,format=raw -M palmetto-bmc -cpu arm926 
-m 64M[/CODE]
  I use palmetto-bmc platform because it have ARM926EJ-S core and support SPI 
Flash.
  Then, i attach to gdb qemu process from IDA and run code step-by-step.

  
  When the IDA run 00032534 STR R11, [R10] command

  
  instead of store R11 on R10 adress, it jump 000328DC STMFD SP!, {R0-R12,LR} 
instruction...

  and virt machine not execute new instruction...
  [IMG]https://pp.userapi.com/c850624/v850624111/528f3/N7FTpgloWVU.jpg[/IMG]

  and why i did not change flash from n25q256a to n25q032a11 in aspeed.c
  without rebuild qemu?

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

[Qemu-devel] [Bug 1806243] Re: ARM conditional branch after if-then instruction not working

[Peter Maydell]

I think this was probably fixed by commit c2d9644e6d517170b, which was
in QEMU 3.1.0 -- that commit certainly fixes some kinds of crash if
guest code tried to do an UNPREDICTABLE conditional instruction inside
an IT block.

Could you try again with that version of QEMU, or at least provide a
repro case with a command line which demonstrates the problem with
upstream QEMU?

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

Title:
  ARM conditional branch after if-then instruction not working

Status in QEMU:
  New

Bug description:
  Hello

  There seems to be an issue with QEMU when debugging if-then condition
  blocks from the thumb2 instruction set. The following snippet runs
  fine during normal execution, but keeps hanging at the conditional
  branch when debugging. The jump at the branch should only be executed
  as long as $r0 is lower than $r1. Problem is that once both are equal,
  the execution is not continued past the branch and the program counter
  never gets popped.

  2000407a:   push{lr}
  2000407c:   movsr0, r6
  2000407e:   ldmia   r7!, {r1, r6}
  20004080:   push{r0, r1}
  20004082:   str.w   r6, [r7, #-4]!
  20004086:   ldr r6, [sp, #0]
  20004088:   pop {r0, r1}
  2000408a:   addsr0, #1
  2000408c:   cmp r0, r1
  2000408e:   itt lt
  20004090:   pushlt  {r0, r1}
  20004092:   blt.w   0x20004082  ; unpredictable   // <-- GDB hangs 
here
  20004096:   pop {pc}

  I have tried to reproduce the problem with inline assembly but for
  some reason the following example just worked:

  void f() {
static uint8_t stack[256]{};
stack[255] = 4;

asm volatile("\n\t"
 "push{lr}"
 "\n\t"

 // pre-conditions
 "movsr7, %[stack]"
 "\n\t"
 "movsr6, #1"
 "\n\t"

 "movsr0, r6"
 "\n\t"
 "ldmia   r7!, {r1, r6}"
 "\n\t"
 "push{r0, r1}"
 "\n\t"
 "1:"
 "\n\t"
 "str.w   r6, [r7, #-4]!"
 "\n\t"
 "ldr r6, [sp, #0]"
 "\n\t"
 "pop {r0, r1}"
 "\n\t"
 "addsr0, #1"
 "\n\t"
 "cmp r0, r1"
 "\n\t"
 "itt lt"
 "\n\t"
 "pushlt  {r0, r1}"
 "\n\t"

 // Original instruction
 //"blt.w   0x20004082"  //   ; unpredictable 

 // Trying to fake it
 "blt.w   1b"
 "\n\t"

 "pop {pc}"
 "\n\t"
 :
 : [stack] "r"([255]));
  }

  The only real major difference I see to the other code snipped is that
  the inline assembly is running from flash memory where as the original
  code runs in ram? Maybe that's a clue somehow?

  Quickly reading through already reported ARM bugs I think this might be 
related:
  https://bugs.launchpad.net/qemu/+bug/1364501
  At least the symptoms sound identical.

  
  The versions I'm running are:
  QEMU 3.0.0
  arm-none-eabi-gdb 8.2

  I've also captured some trace output for single stepping from the
  pushlt to the blt.w instruction with the trace arguments unimp,
  guest_errors, op, int, exec.

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

[Qemu-devel] [Bug 1455912] Re: vnc websocket option not properly parsed when running on commandline

[Peter Maydell]

Dan's patch linked in comment #4 went into git as commit
1b1aeb5828c978a, so this has been fixed (with the fix going into the
2.9.0 release).


** Changed in: qemu
   Status: In Progress => Fix Released

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

Title:
  vnc websocket option not properly parsed when running on commandline

Status in QEMU:
  Fix Released

Bug description:
  All of my vms are started with a simple script on the command line.  
  Starting with Qemu 2.3.0, the option "-vnc host:port,websocket" is no longer 
working.

  Previously if I said listen on Tor:17,websocket it would function
  correctly.  Now it's kicking an error:

  
  qemu-system-x86_64: -vnc tor:17,websocket: Failed to start VNC server on 
`(null)': address resolution failed for tor:on: Servname not supported for 
ai_socktype

  The error leads me to believe it's not parsing the command line
  options for the "vnc" option correctly.  If I leave off ",websocket"
  it works correctly.  I've even tried, replacing the hostname with an
  IP address, and using the alternate form " -display
  vnc=tor:17,webscoket". It reports the same error.

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

Re: [Qemu-devel] [PATCH v3 0/4] target/arm: Implement ARMv8.5-BTI

[Richard Henderson]

On 3/26/19 6:57 AM, Peter Maydell wrote:
> I'm pretty sure we talked about this on IRC at some point,
> but for the record: I believe the relevent ELF ABI spec docs
> are now public that have the changes that describe how ELF
> executables are marked up to indicate which parts should be
> loaded into guarded pages. The rest of the userspace ABI
> is likely to just be a new mmap() flag. So I think we're
> better off implementing that (possibly still guarded by
> an x- property if it's not finalized yet.)

We still don't know what the mmap flag will be.

You're right that the elf abi is sufficient to
build statically linked test cases, though, which
is all we wanted here.


r~

[Qemu-devel] [Bug 1754605] Re: ppc64 migration bad_dest test is failed with failed to connect to socket

[Peter Maydell]

David's patch fixing this went in as commit f96d6651e4b7cb8a8e91, which
will have been in the 3.0 release.


** Changed in: qemu
   Status: In Progress => Fix Released

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

Title:
  ppc64 migration bad_dest test is failed with failed to connect to
  socket

Status in QEMU:
  Fix Released

Bug description:
  On ppc64le machine the following test failed.

  # QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/migration-test V=1
  /ppc64/migration/deprecated: OK
  /ppc64/migration/bad_dest: qemu-system-ppc64: Failed to connect socket: 
Connection refused
  OK
  /ppc64/migration/postcopy/unix: OK

  Head is at f6d81cdec807bb85325afedb536b17c5331483c7
  configured with options: configure --target-list=ppc64-softmmu

  This test case is added through
  2c9bb29703caa8fd31078cc38b3b53762557c27c

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

[Qemu-devel] [Bug 1294227] Re: migration wrong handling of KVM_GET_DIRTY_LOG ioctl

[Peter Maydell]

The apparently obvious fix was applied as commit b533f658a98325d0e4 but
then reverted in commit 50212d6346f33d6e19, because not all errno
returns from this ioctl should be treated as errors.

That commit message said "Revert that patch instead of fixing it
properly this late in the release process.  I disagree with this
approach, but let's make things move _somewhere_, instead of arguing
endlessly whch of the 2 proposed fixes is better." -- and then we never
did a proper fix, so 5 years later we're still making an incorrect == -1
check...

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

Title:
  migration wrong handling of KVM_GET_DIRTY_LOG ioctl

Status in QEMU:
  In Progress

Bug description:
  In the code below kvm_vm_ioctl(...) can return --errno != -1 from ioctl call, 
 but return only checks for -1. 
  Found during KVM-ARM migration which apperead to go through but was actually 
failing getting 
  memslot dirty bitmap.

  static int kvm_physical_sync_dirty_bitmap()
  {
   
   if(kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, ) == -1) {
 - err out
   }
   ... continue
  }

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

[Qemu-devel] [Bug 1796754] Re: ioctl SIOCGIFCONF causes qemu-aarch64-static to crash with "received signal outside vCPU context"

[Peter Maydell]

Kan Li's patch was applied to master as commit 22e4a267a6627e5b5b, so
this will be fixed in the upcoming QEMU 4.0 release.


** Changed in: qemu
   Status: In Progress => Fix Committed

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

Title:
  ioctl SIOCGIFCONF causes qemu-aarch64-static to crash with "received
  signal outside vCPU context"

Status in QEMU:
  Fix Committed

Bug description:
  To reproduce it, compile the attached crash.c under aarch64 to a.out and 
execute on x86_64
  qemu-aarch64-static ./a.out

  It will print the following and crash:

  socket=3
  qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60038cd6
  qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6000157a

  The version of qemu-aarch64-static is

  qemu-aarch64 version 3.0.0 (qemu-3.0.0-1.fc29)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  But it did also happen in previous versions so it is not a regression
  but a bug existed ever since.

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