Re: [PATCH v13 0/4] Add Versal usb model

[Philippe Mathieu-Daudé]

On 11/10/20 7:52 AM, Sai Pavan Boddu wrote:
> This patch series attempts to make 'hcd-xhci' an independent model so it can 
> be used by both pci and system-bus interface.

This part got merged already...

Re: [PATCH-for-5.2 v3] configure: Check vhost-user is available for vhost-user-blk-server

[Philippe Mathieu-Daudé]

On 11/10/20 4:15 AM, Thomas Huth wrote:
> On 09/11/2020 20.15, Philippe Mathieu-Daudé wrote:
>> On 11/9/20 7:52 PM, Philippe Mathieu-Daudé wrote:
>>> On 11/9/20 7:44 PM, Thomas Huth wrote:
 On 09/11/2020 19.41, Philippe Mathieu-Daudé wrote:
> On Mon, Nov 9, 2020 at 6:22 PM Thomas Huth  wrote:
>> On 09/11/2020 15.07, Philippe Mathieu-Daudé wrote:
>>> Check vhost-user is available when building vhost-user-blk-server.
>>>
>>> This fixes:
>>>
>>>  $ ../configure \
>>>   --disable-vhost-user --enable-vhost-user-blk-server && \
>>>make qemu-nbd
>>>  ...
>>>  [505/505] Linking target qemu-nbd
>>>  FAILED: qemu-nbd
>>>  cc  -o qemu-nbd qemu-nbd.p/qemu-nbd.c.o -Wl,--as-needed 
>>> -Wl,--no-undefined -pie -Wl,--whole-archive libblockdev.fa libblock.fa 
>>> libcrypto.fa libauthz.fa libqom.fa libio.fa -Wl,--no-whole-archive 
>>> -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -fstack-protector-strong 
>>> -Wl,--start-group libqemuutil.a libblockdev.fa libblock.fa libcrypto.fa 
>>> libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 
>>> -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lgnutls -lutil 
>>> -lm -lgthread-2.0 -lglib-2.0 -lbz2 -lgthread-2.0 -lglib-2.0 -lssh -lrbd 
>>> -lrados -lcurl -lxml2 -lzstd -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr 
>>> -luuid -laio /usr/lib64/libz.so -L/usr/lib64/iscsi -liscsi -lnettle 
>>> -lgnutls -lpam -Wl,--end-group
>>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): 
>>> in function `vu_blk_process_vq':
>>>  block/export/vhost-user-blk-server.c:203: undefined reference to 
>>> `vu_get_queue'
>>>  /usr/bin/ld: block/export/vhost-user-blk-server.c:208: undefined 
>>> reference to `vu_queue_pop'
>>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): 
>>> in function `vu_blk_queue_set_started':
>>>  block/export/vhost-user-blk-server.c:228: undefined reference to 
>>> `vu_get_queue'
>>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): 
>>> in function `vu_blk_req_complete':
>>>  block/export/vhost-user-blk-server.c:55: undefined reference to 
>>> `vu_queue_push'
>>>  /usr/bin/ld: block/export/vhost-user-blk-server.c:56: undefined 
>>> reference to `vu_queue_notify'
>>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): 
>>> in function `vu_blk_queue_set_started':
>>>  block/export/vhost-user-blk-server.c:229: undefined reference to 
>>> `vu_set_queue_handler'
>>>  /usr/bin/ld: libqemuutil.a(util_vhost-user-server.c.o): in function 
>>> `vu_client_trip':
>>>  util/vhost-user-server.c:176: undefined reference to `vu_dispatch'
>>>  /usr/bin/ld: util/vhost-user-server.c:180: undefined reference to 
>>> `vu_deinit'
>>>  /usr/bin/ld: libqemuutil.a(util_vhost-user-server.c.o): in function 
>>> `vu_accept':
>>>  util/vhost-user-server.c:291: undefined reference to `vu_init'
>>>  collect2: error: ld returned 1 exit status
>>>  ninja: build stopped: subcommand failed.
>>>  make: *** [Makefile:171: run-ninja] Error 1
>>>
>>> Now we get:
>>>
>>>  $ ../configure \
>>>   --disable-vhost-user --enable-vhost-user-blk-server && \
>>>  ERROR: --enable-vhost-user-blk-server requires --enable-vhost-user
>>>
>>> Fixes: bc15e44cb21 ("configure: introduce 
>>> --enable-vhost-user-blk-server")
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>> Since v1:
>>> - Addressed Thomas review comments
>>> https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02188.html
>>> ---
>>>  configure | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index 805f7791503..3124be82da1 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2375,6 +2375,10 @@ test "$vhost_user_fs" = "" && 
>>> vhost_user_fs=$vhost_user
>>>  if test "$vhost_user_fs" = "yes" && test "$vhost_user" = "no"; then
>>>error_exit "--enable-vhost-user-fs requires --enable-vhost-user"
>>>  fi
>>> +test "$vhost_user_blk_server" = "" && vhost_user_blk_server=$vhost_user
>>> +if test "$vhost_user_blk_server" = "yes" && test "$vhost_user" = "no"; 
>>> then
>>> +  error_exit "--enable-vhost-user-blk-server requires 
>>> --enable-vhost-user"
>>> +fi
>>
>> A little bit later in this file, we've got :
>>
>> # libvhost-user is Linux-only
>> test "$vhost_user_blk_server" = "" && vhost_user_blk_server=$linux
>> if test "$vhost_user_blk_server" = "yes" && test "$linux" = "no"; then
>>   error_exit "--enable-vhost-user-blk-server is only available on Linux"
>> fi
>>
>> I think it would be better to add the new code there instead.
>> Also maybe better do something like:
>>
>> test "$vhost_user_blk_server" = 

Re: nbd: bitmap_to_extents() calls nbd_extent_array_add() without checking return value: coverity false positive?

[Vladimir Sementsov-Ogievskiy]

09.11.2020 18:22, Eric Blake wrote:

On 11/9/20 1:17 AM, Vladimir Sementsov-Ogievskiy wrote:

07.11.2020 01:53, Peter Maydell wrote:

On Fri, 6 Nov 2020 at 20:36, Eric Blake  wrote:


On 11/6/20 11:22 AM, Peter Maydell wrote:

Hi; Coverity's "you usually check the return value of this function
but you didn't do that here" heuristic has fired on the code in
nbd/server.c:bitmap_to_extents() -- the function nbd_extent_array_add()
is called five times in server.c, and the return value is checked
in four of those, but not in the final call at the end of
bitmap_to_extents(). (CID 1436125.)

Is this a false positive, or should the caller be handling an
error here ?


False positive, but I don't mind tweaking the code to silence Coverity.
This should do it; let me know if I should turn it into a formal patch.

diff --git i/nbd/server.c w/nbd/server.c
index d145e1a69083..377698a2ce85 100644
--- i/nbd/server.c
+++ w/nbd/server.c
@@ -2128,9 +2128,8 @@ static void bitmap_to_extents(BdrvDirtyBitmap
*bitmap,
   }
   }

-    if (!full) {
-    /* last non dirty extent */
-    nbd_extent_array_add(es, end - start, 0);
+    if (!full && nbd_extent_array_add(es, end - start, 0) < 0) {
+    /* last non dirty extent, not a problem if array is now full */
   }

   bdrv_dirty_bitmap_unlock(bitmap);


Hmm; that looks a little odd but I guess it's a bit more
documentative of the intent. Up to you whether you want
to submit it as a patch or not I guess :-)

thanks
-- PMM




update_refcount() in block/qcow2-refcount.c is defined as

  static int QEMU_WARN_UNUSED_RESULT update_refcount(..);

May be, use such specifier for nbd_extent_array_add()?


Adding that attribute would _force_ us to modify the code, rather than
the current situation where we are mulling the modification merely to
pacify Coverity's 4-out-of-5 analysis.  We don't strictly need to always
use the return value (hence my declaration that this was a Coverity
false positive), but declaring that we always want to use it, and fixing
the code fallout, would indeed silence Coverity.



Oh, I thought that this macro has the opposite meaning :\

--
Best regards,
Vladimir

[PATCH v13 4/4] arm: xlnx-versal: Connect usb to virt-versal

[Sai Pavan Boddu]

From: Vikram Garhwal 

Connect VersalUbs2 subsystem to xlnx-versal SOC, its placed
in iou of lpd domain and configure it as dual port host controller.
Add the respective guest dts nodes for "xlnx-versal-virt" machine.

Signed-off-by: Vikram Garhwal 
Signed-off-by: Sai Pavan Boddu 
---
 hw/arm/xlnx-versal-virt.c| 58 
 hw/arm/xlnx-versal.c | 26 
 include/hw/arm/xlnx-versal.h |  9 +++
 3 files changed, 93 insertions(+)

diff --git a/hw/arm/xlnx-versal-virt.c b/hw/arm/xlnx-versal-virt.c
index ee12822..84b450e 100644
--- a/hw/arm/xlnx-versal-virt.c
+++ b/hw/arm/xlnx-versal-virt.c
@@ -39,6 +39,8 @@ struct VersalVirt {
 uint32_t ethernet_phy[2];
 uint32_t clk_125Mhz;
 uint32_t clk_25Mhz;
+uint32_t usb;
+uint32_t dwc;
 } phandle;
 struct arm_boot_info binfo;
 
@@ -66,6 +68,8 @@ static void fdt_create(VersalVirt *s)
 s->phandle.clk_25Mhz = qemu_fdt_alloc_phandle(s->fdt);
 s->phandle.clk_125Mhz = qemu_fdt_alloc_phandle(s->fdt);
 
+s->phandle.usb = qemu_fdt_alloc_phandle(s->fdt);
+s->phandle.dwc = qemu_fdt_alloc_phandle(s->fdt);
 /* Create /chosen node for load_dtb.  */
 qemu_fdt_add_subnode(s->fdt, "/chosen");
 
@@ -148,6 +152,59 @@ static void fdt_add_timer_nodes(VersalVirt *s)
  compat, sizeof(compat));
 }
 
+static void fdt_add_usb_xhci_nodes(VersalVirt *s)
+{
+const char clocknames[] = "bus_clk\0ref_clk";
+char *name = g_strdup_printf("/usb@%" PRIx32, MM_USB2_CTRL_REGS);
+const char compat[] = "xlnx,versal-dwc3";
+
+qemu_fdt_add_subnode(s->fdt, name);
+qemu_fdt_setprop(s->fdt, name, "compatible",
+ compat, sizeof(compat));
+qemu_fdt_setprop_sized_cells(s->fdt, name, "reg",
+ 2, MM_USB2_CTRL_REGS,
+ 2, MM_USB2_CTRL_REGS_SIZE);
+qemu_fdt_setprop(s->fdt, name, "clock-names",
+ clocknames, sizeof(clocknames));
+qemu_fdt_setprop_cells(s->fdt, name, "clocks",
+   s->phandle.clk_25Mhz, s->phandle.clk_125Mhz);
+qemu_fdt_setprop(s->fdt, name, "ranges", NULL, 0);
+qemu_fdt_setprop_cell(s->fdt, name, "#address-cells", 2);
+qemu_fdt_setprop_cell(s->fdt, name, "#size-cells", 2);
+qemu_fdt_setprop_cell(s->fdt, name, "phandle", s->phandle.usb);
+g_free(name);
+
+{
+const char irq_name[] = "dwc_usb3";
+const char compat[] = "snps,dwc3";
+
+name = g_strdup_printf("/usb@%" PRIx32 "/dwc3@%" PRIx32,
+   MM_USB2_CTRL_REGS, MM_USB_0);
+qemu_fdt_add_subnode(s->fdt, name);
+qemu_fdt_setprop(s->fdt, name, "compatible",
+ compat, sizeof(compat));
+qemu_fdt_setprop_sized_cells(s->fdt, name, "reg",
+ 2, MM_USB_0, 2, MM_USB_0_SIZE);
+qemu_fdt_setprop(s->fdt, name, "interrupt-names",
+ irq_name, sizeof(irq_name));
+qemu_fdt_setprop_cells(s->fdt, name, "interrupts",
+   GIC_FDT_IRQ_TYPE_SPI, VERSAL_USB0_IRQ_0,
+   GIC_FDT_IRQ_FLAGS_LEVEL_HI);
+qemu_fdt_setprop_cell(s->fdt, name,
+  "snps,quirk-frame-length-adjustment", 0x20);
+qemu_fdt_setprop_cells(s->fdt, name, "#stream-id-cells", 1);
+qemu_fdt_setprop_string(s->fdt, name, "dr_mode", "host");
+qemu_fdt_setprop_string(s->fdt, name, "phy-names", "usb3-phy");
+qemu_fdt_setprop(s->fdt, name, "snps,dis_u2_susphy_quirk", NULL, 0);
+qemu_fdt_setprop(s->fdt, name, "snps,dis_u3_susphy_quirk", NULL, 0);
+qemu_fdt_setprop(s->fdt, name, "snps,refclk_fladj", NULL, 0);
+qemu_fdt_setprop(s->fdt, name, "snps,mask_phy_reset", NULL, 0);
+qemu_fdt_setprop_cell(s->fdt, name, "phandle", s->phandle.dwc);
+qemu_fdt_setprop_string(s->fdt, name, "maximum-speed", "high-speed");
+g_free(name);
+}
+}
+
 static void fdt_add_uart_nodes(VersalVirt *s)
 {
 uint64_t addrs[] = { MM_UART1, MM_UART0 };
@@ -515,6 +572,7 @@ static void versal_virt_init(MachineState *machine)
 fdt_add_gic_nodes(s);
 fdt_add_timer_nodes(s);
 fdt_add_zdma_nodes(s);
+fdt_add_usb_xhci_nodes(s);
 fdt_add_sd_nodes(s);
 fdt_add_rtc_node(s);
 fdt_add_cpu_nodes(s, psci_conduit);
diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
index 12ba6c4..b077716 100644
--- a/hw/arm/xlnx-versal.c
+++ b/hw/arm/xlnx-versal.c
@@ -145,6 +145,31 @@ static void versal_create_uarts(Versal *s, qemu_irq *pic)
 }
 }
 
+static void versal_create_usbs(Versal *s, qemu_irq *pic)
+{
+DeviceState *dev;
+MemoryRegion *mr;
+
+object_initialize_child(OBJECT(s), "usb2", >lpd.iou.usb,
+TYPE_XILINX_VERSAL_USB2);
+dev = DEVICE(>lpd.iou.usb);
+
+object_property_set_link(OBJECT(dev), 

[PATCH v13 0/4] Add Versal usb model

[Sai Pavan Boddu]

This patch series attempts to make 'hcd-xhci' an independent model so it can be 
used by both pci and system-bus interface.

Changes for V2:
Make XHCIState non-qom
Use container_of functions for retriving pci device instance
Initialize the AddressSpace pointer in PATCH 1/3 itself Changes for V3:
Convert XHCIState to TYPE_DEVICE and register as a child of XHCIPciState.
Changes for V4:
Add DWC3 usb controller
Add versal, usb2-reg module
Connect sysbus xhci to versal virt board Changes for V5:
Add extra info about dwc3 and usb2_regs devices in commit messages
Use only one irq for versal usb controller
Mark the unimplemented registers in dwc3 controller
Rebase the patches over master.
Move few mispalced contents from patch 2/7 to 3/7.
Fix the author names in the header.
Move the inclusion of "sysemu/dma.h" from patch 1/7 to 3/7 Changes for V6:
Fixed style issue in patch 7/7
Renamed usb2_reg model to VersalUsb2CtrlReg
Fixed author in headers
Changes for V7:
Create a usb structure to keep things clean
Remove the repeated patch in the series i.e 5/7 Changes for V8:
Fix vmstate sturcts to support cross version migration.
Changes for V9:
Added recommended changes to fix vmstate migration.
Fixed commit message on 3/7.
Changes for V10:
use vmstate_post_load avaialble in VMStateDescription
tested vmstate cross migration.
Changes for V11:
Removed the patches which got accepted
Changed object name "USB2Reg" -> "ctrl"
Updated Subject line on cover letter.
Changes for V12:
Use reset class for usb2-ctrl-regs module
Move the few register update to realize
Marked registers which are unimplemented in regapi model
Changs for V13:
Add usb subsystem for xilinx devices,
Memory Map xhci internally to dwc3 device,
Add respective changes to connect VersalUsb2 subsystem to xilinx-versal.



Sai Pavan Boddu (2):
  usb: Add versal-usb2-ctrl-regs module
  usb: xlnx-usb-subsystem: Add xilinx usb subsystem

Vikram Garhwal (2):
  usb: Add DWC3 model
  arm: xlnx-versal: Connect usb to virt-versal

 hw/arm/xlnx-versal-virt.c   |  58 +++
 hw/arm/xlnx-versal.c|  26 ++
 hw/usb/Kconfig  |   6 +
 hw/usb/hcd-dwc3.c   | 677 
 hw/usb/meson.build  |   3 +
 hw/usb/xlnx-usb-subsystem.c |  94 
 hw/usb/xlnx-versal-usb2-ctrl-regs.c | 229 ++
 include/hw/arm/xlnx-versal.h|   9 +
 include/hw/usb/hcd-dwc3.h   |  56 +++
 include/hw/usb/xlnx-usb-subsystem.h |  45 ++
 include/hw/usb/xlnx-versal-usb2-ctrl-regs.h |  45 ++
 11 files changed, 1248 insertions(+)
 create mode 100644 hw/usb/hcd-dwc3.c
 create mode 100644 hw/usb/xlnx-usb-subsystem.c
 create mode 100644 hw/usb/xlnx-versal-usb2-ctrl-regs.c
 create mode 100644 include/hw/usb/hcd-dwc3.h
 create mode 100644 include/hw/usb/xlnx-usb-subsystem.h
 create mode 100644 include/hw/usb/xlnx-versal-usb2-ctrl-regs.h

-- 
2.7.4

Re: [PATCH for-5.2 3/3] linux-user/sparc: Don't zero high half of PC, NPC, PSR in sigreturn

[Laurent Vivier]

Le 05/11/2020 à 22:23, Peter Maydell a écrit :
> The function do_sigreturn() tries to store the PC, NPC and PSR in
> uint32_t local variables, which implicitly drops the high half of
> these fields for 64-bit guests.
> 
> The usual effect was that a guest which used signals would crash on
> return from a signal unless it was lucky enough to take it while the
> PC was in the low 4GB of the address space.  In particular, Debian
> /bin/dash and /bin/bash would segfault after executing external
> commands.
> 
> Use abi_ulong, which is the type these fields all have in the
> __siginfo_t struct.
> 
> Signed-off-by: Peter Maydell 
> ---
>  linux-user/sparc/signal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c
> index c315704b389..d12adc8e6ff 100644
> --- a/linux-user/sparc/signal.c
> +++ b/linux-user/sparc/signal.c
> @@ -247,7 +247,7 @@ long do_sigreturn(CPUSPARCState *env)
>  {
>  abi_ulong sf_addr;
>  struct target_signal_frame *sf;
> -uint32_t up_psr, pc, npc;
> +abi_ulong up_psr, pc, npc;
>  target_sigset_t set;
>  sigset_t host_set;
>  int i;
> 

Applied to my linux-user-for-5.2 branch.

Thanks,
Laurent

Re: [PATCH for-5.2 2/3] linux-user/sparc: Correct set/get_context handling of fp and i7

[Laurent Vivier]

Le 05/11/2020 à 22:23, Peter Maydell a écrit :
> Because QEMU's user-mode emulation just directly accesses guest CPU
> state, for SPARC the guest register window state is not the same in
> the sparc64_get_context() and sparc64_set_context() functions as it
> is for the real kernel's versions of those functions.  Specifically,
> for the kernel it has saved the user space state such that the O*
> registers go into a pt_regs struct as UREG_I*, and the I* registers
> have been spilled onto the userspace stack.  For QEMU, we haven't
> done that, so the guest's O* registers are still in WREG_O* and the
> I* registers in WREG_I*.
> 
> The code was already accessing the O* registers correctly for QEMU,
> but had copied the kernel code for accessing the I* registers off the
> userspace stack.  Replace this with direct accesses to fp and i7 in
> the CPU state, and add a comment explaining why we differ from the
> kernel code here.
> 
> This fix is sufficient to get bash to a shell prompt.
> 
> Signed-off-by: Peter Maydell 
> ---
> I'm really pretty unsure about our handling of SPARC register
> windows here. This fix works, but should we instead be
> ensuring that the flush_windows() call cpu_loop() does
> before handling this trap has written the I* regs to the
> stack ???
> ---
>  linux-user/sparc/signal.c | 47 ++-
>  1 file changed, 22 insertions(+), 25 deletions(-)
> 
> diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c
> index 57ea1593bfc..c315704b389 100644
> --- a/linux-user/sparc/signal.c
> +++ b/linux-user/sparc/signal.c
> @@ -403,7 +403,6 @@ void sparc64_set_context(CPUSPARCState *env)
>  struct target_ucontext *ucp;
>  target_mc_gregset_t *grp;
>  abi_ulong pc, npc, tstate;
> -abi_ulong fp, i7, w_addr;
>  unsigned int i;
>  
>  ucp_addr = env->regwptr[WREG_O0];
> @@ -447,6 +446,15 @@ void sparc64_set_context(CPUSPARCState *env)
>  __get_user(env->gregs[5], (&(*grp)[SPARC_MC_G5]));
>  __get_user(env->gregs[6], (&(*grp)[SPARC_MC_G6]));
>  __get_user(env->gregs[7], (&(*grp)[SPARC_MC_G7]));
> +
> +/*
> + * Note that unlike the kernel, we didn't need to mess with the
> + * guest register window state to save it into a pt_regs to run
> + * the kernel. So for us the guest's O regs are still in WREG_O*
> + * (unlike the kernel which has put them in UREG_I* in a pt_regs)
> + * and the fp and i7 are still in WREG_I6 and WREG_I7 and don't
> + * need to be written back to userspace memory.
> + */
>  __get_user(env->regwptr[WREG_O0], (&(*grp)[SPARC_MC_O0]));
>  __get_user(env->regwptr[WREG_O1], (&(*grp)[SPARC_MC_O1]));
>  __get_user(env->regwptr[WREG_O2], (&(*grp)[SPARC_MC_O2]));
> @@ -456,18 +464,9 @@ void sparc64_set_context(CPUSPARCState *env)
>  __get_user(env->regwptr[WREG_O6], (&(*grp)[SPARC_MC_O6]));
>  __get_user(env->regwptr[WREG_O7], (&(*grp)[SPARC_MC_O7]));
>  
> -__get_user(fp, &(ucp->tuc_mcontext.mc_fp));
> -__get_user(i7, &(ucp->tuc_mcontext.mc_i7));
> +__get_user(env->regwptr[WREG_FP], &(ucp->tuc_mcontext.mc_fp));
> +__get_user(env->regwptr[WREG_I7], &(ucp->tuc_mcontext.mc_i7));
>  
> -w_addr = TARGET_STACK_BIAS + env->regwptr[WREG_O6];
> -if (put_user(fp, w_addr + offsetof(struct target_reg_window, ins[6]),
> - abi_ulong) != 0) {
> -goto do_sigsegv;
> -}
> -if (put_user(i7, w_addr + offsetof(struct target_reg_window, ins[7]),
> - abi_ulong) != 0) {
> -goto do_sigsegv;
> -}
>  /* FIXME this does not match how the kernel handles the FPU in
>   * its sparc64_set_context implementation. In particular the FPU
>   * is only restored if fenab is non-zero in:
> @@ -501,7 +500,6 @@ void sparc64_get_context(CPUSPARCState *env)
>  struct target_ucontext *ucp;
>  target_mc_gregset_t *grp;
>  target_mcontext_t *mcp;
> -abi_ulong fp, i7, w_addr;
>  int err;
>  unsigned int i;
>  target_sigset_t target_set;
> @@ -553,6 +551,15 @@ void sparc64_get_context(CPUSPARCState *env)
>  __put_user(env->gregs[5], &((*grp)[SPARC_MC_G5]));
>  __put_user(env->gregs[6], &((*grp)[SPARC_MC_G6]));
>  __put_user(env->gregs[7], &((*grp)[SPARC_MC_G7]));
> +
> +/*
> + * Note that unlike the kernel, we didn't need to mess with the
> + * guest register window state to save it into a pt_regs to run
> + * the kernel. So for us the guest's O regs are still in WREG_O*
> + * (unlike the kernel which has put them in UREG_I* in a pt_regs)
> + * and the fp and i7 are still in WREG_I6 and WREG_I7 and don't
> + * need to be fished out of userspace memory.
> + */
>  __put_user(env->regwptr[WREG_O0], &((*grp)[SPARC_MC_O0]));
>  __put_user(env->regwptr[WREG_O1], &((*grp)[SPARC_MC_O1]));
>  __put_user(env->regwptr[WREG_O2], &((*grp)[SPARC_MC_O2]));
> @@ -562,18 +569,8 @@ void sparc64_get_context(CPUSPARCState *env)
>  

Re: [PATCH for-5.2 1/3] linux-user/sparc: Fix errors in target_ucontext structures

[Laurent Vivier]

Le 05/11/2020 à 22:23, Peter Maydell a écrit :
> The various structs that make up the SPARC target_ucontext had some
> errors:
>  * target structures must not include fields which are host pointers,
>which might be the wrong size.  These should be abi_ulong instead
>  * because we don't have the 'long double' part of the mcfpu_fregs
>union in our version of the target_mc_fpu struct, we need to
>manually force it to be 16-aligned
> 
> In particular, the lack of 16-alignment caused sparc64_get_context()
> and sparc64_set_context() to read and write all the registers at the
> wrong offset, which triggered a guest glibc stack check in
> siglongjmp:
>   *** longjmp causes uninitialized stack frame ***: terminated
> when trying to run bash.
> 
> Signed-off-by: Peter Maydell 
> ---
>  linux-user/sparc/signal.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c
> index d796f50f665..57ea1593bfc 100644
> --- a/linux-user/sparc/signal.c
> +++ b/linux-user/sparc/signal.c
> @@ -349,10 +349,15 @@ typedef abi_ulong target_mc_greg_t;
>  typedef target_mc_greg_t target_mc_gregset_t[SPARC_MC_NGREG];
>  
>  struct target_mc_fq {
> -abi_ulong *mcfq_addr;
> +abi_ulong mcfq_addr;
>  uint32_t mcfq_insn;
>  };
>  
> +/*
> + * Note the manual 16-alignment; the kernel gets this because it
> + * includes a "long double qregs[16]" in the mcpu_fregs union,
> + * which we can't do.
> + */
>  struct target_mc_fpu {
>  union {
>  uint32_t sregs[32];
> @@ -362,11 +367,11 @@ struct target_mc_fpu {
>  abi_ulong mcfpu_fsr;
>  abi_ulong mcfpu_fprs;
>  abi_ulong mcfpu_gsr;
> -struct target_mc_fq *mcfpu_fq;
> +abi_ulong mcfpu_fq;
>  unsigned char mcfpu_qcnt;
>  unsigned char mcfpu_qentsz;
>  unsigned char mcfpu_enab;
> -};
> +} __attribute__((aligned(16)));
>  typedef struct target_mc_fpu target_mc_fpu_t;
>  
>  typedef struct {
> @@ -377,7 +382,7 @@ typedef struct {
>  } target_mcontext_t;
>  
>  struct target_ucontext {
> -struct target_ucontext *tuc_link;
> +abi_ulong tuc_link;
>  abi_ulong tuc_flags;
>  target_sigset_t tuc_sigmask;
>  target_mcontext_t tuc_mcontext;
> 

Applied to my linux-user-for-5.2 branch.

Thanks,
Laurent

[PATCH v13 3/4] usb: xlnx-usb-subsystem: Add xilinx usb subsystem

[Sai Pavan Boddu]

This model is a top level integration wrapper for hcd-dwc3 and
versal-usb2-ctrl-regs modules, this is used by xilinx versal soc's and
future xilinx usb subsystems would also be part of it.

Signed-off-by: Sai Pavan Boddu 
---
 hw/usb/meson.build  |  1 +
 hw/usb/xlnx-usb-subsystem.c | 94 +
 include/hw/usb/xlnx-usb-subsystem.h | 45 ++
 3 files changed, 140 insertions(+)
 create mode 100644 hw/usb/xlnx-usb-subsystem.c
 create mode 100644 include/hw/usb/xlnx-usb-subsystem.h

diff --git a/hw/usb/meson.build b/hw/usb/meson.build
index 433c27e..580d28d 100644
--- a/hw/usb/meson.build
+++ b/hw/usb/meson.build
@@ -32,6 +32,7 @@ softmmu_ss.add(when: 'CONFIG_TUSB6010', if_true: 
files('tusb6010.c'))
 softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('chipidea.c'))
 softmmu_ss.add(when: 'CONFIG_IMX_USBPHY', if_true: files('imx-usb-phy.c'))
 specific_ss.add(when: 'CONFIG_XLNX_VERSAL', if_true: 
files('xlnx-versal-usb2-ctrl-regs.c'))
+specific_ss.add(when: 'CONFIG_XLNX_VERSAL', if_true: 
files('xlnx-usb-subsystem.c'))
 
 # emulated usb devices
 softmmu_ss.add(when: 'CONFIG_USB', if_true: files('dev-hub.c'))
diff --git a/hw/usb/xlnx-usb-subsystem.c b/hw/usb/xlnx-usb-subsystem.c
new file mode 100644
index 000..5682573
--- /dev/null
+++ b/hw/usb/xlnx-usb-subsystem.c
@@ -0,0 +1,94 @@
+/*
+ * QEMU model of the Xilinx usb subsystem
+ *
+ * Copyright (c) 2020 Xilinx Inc. Sai Pavan Boddu 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/irq.h"
+#include "hw/register.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "qom/object.h"
+#include "qapi/error.h"
+#include "hw/qdev-properties.h"
+#include "hw/usb/xlnx-usb-subsystem.h"
+
+static void versal_usb2_realize(DeviceState *dev, Error **errp)
+{
+VersalUsb2 *s = VERSAL_USB2(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+Error *err = NULL;
+
+sysbus_realize(SYS_BUS_DEVICE(>dwc3), );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_realize(SYS_BUS_DEVICE(>usb2Ctrl), );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_init_mmio(sbd, >dwc3_mr);
+sysbus_init_mmio(sbd, >usb2Ctrl_mr);
+qdev_pass_gpios(DEVICE(>dwc3.sysbus_xhci), dev, SYSBUS_DEVICE_GPIO_IRQ);
+}
+
+static void versal_usb2_init(Object *obj)
+{
+VersalUsb2 *s = VERSAL_USB2(obj);
+
+object_initialize_child(obj, "versal.dwc3", >dwc3,
+TYPE_USB_DWC3);
+object_initialize_child(obj, "versal.usb2-ctrl", >usb2Ctrl,
+TYPE_XILINX_VERSAL_USB2_CTRL_REGS);
+memory_region_init_alias(>dwc3_mr, obj, "versal.dwc3_alias",
+ >dwc3.iomem, 0, DWC3_SIZE);
+memory_region_init_alias(>usb2Ctrl_mr, obj, "versal.usb2Ctrl_alias",
+ >usb2Ctrl.iomem, 0, USB2_REGS_R_MAX * 4);
+qdev_alias_all_properties(DEVICE(>dwc3), obj);
+qdev_alias_all_properties(DEVICE(>dwc3.sysbus_xhci), obj);
+object_property_add_alias(obj, "dma", OBJECT(>dwc3.sysbus_xhci), "dma");
+}
+
+static void versal_usb2_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->realize = versal_usb2_realize;
+}
+
+static const TypeInfo versal_usb2_info = {
+.name  = TYPE_XILINX_VERSAL_USB2,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(VersalUsb2),
+.class_init= versal_usb2_class_init,
+.instance_init = versal_usb2_init,
+};
+
+static void versal_usb_types(void)
+{
+type_register_static(_usb2_info);
+}
+
+type_init(versal_usb_types)
diff --git a/include/hw/usb/xlnx-usb-subsystem.h 
b/include/hw/usb/xlnx-usb-subsystem.h
new file mode 100644
index 000..739bef7
--- /dev/null
+++ b/include/hw/usb/xlnx-usb-subsystem.h
@@ -0,0 +1,45 @@
+/*
+ * QEMU model of the 

[PATCH v13 2/4] usb: Add DWC3 model

[Sai Pavan Boddu]

From: Vikram Garhwal 

This patch adds skeleton model of dwc3 usb controller attached to
xhci-sysbus device. It defines global register space of DWC3 controller,
global registers control the AXI/AHB interfaces properties, external FIFO
support and event count support. All of which are unimplemented at
present,we are only supporting core reset and read of ID register.

Signed-off-by: Vikram Garhwal 
Signed-off-by: Sai Pavan Boddu 
Reviewed-by: Edgar E. Iglesias 
---
 hw/usb/Kconfig|   6 +
 hw/usb/hcd-dwc3.c | 677 ++
 hw/usb/meson.build|   1 +
 include/hw/usb/hcd-dwc3.h |  56 
 4 files changed, 740 insertions(+)
 create mode 100644 hw/usb/hcd-dwc3.c
 create mode 100644 include/hw/usb/hcd-dwc3.h

diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
index a674ce4..31084f8 100644
--- a/hw/usb/Kconfig
+++ b/hw/usb/Kconfig
@@ -114,3 +114,9 @@ config IMX_USBPHY
 bool
 default y
 depends on USB
+
+config USB_DWC3
+bool
+default y if USB_XHCI_SYSBUS
+select USB
+select REGISTER
diff --git a/hw/usb/hcd-dwc3.c b/hw/usb/hcd-dwc3.c
new file mode 100644
index 000..cf71fe4
--- /dev/null
+++ b/hw/usb/hcd-dwc3.c
@@ -0,0 +1,677 @@
+/*
+ * QEMU model of the USB DWC3 host controller emulation.
+ *
+ * This model defines global register space of DWC3 controller. Global
+ * registers control the AXI/AHB interfaces properties, external FIFO support
+ * and event count support. All of which are unimplemented at present. We are
+ * only supporting core reset and read of ID register.
+ *
+ * Copyright (c) 2020 Xilinx Inc. Vikram Garhwal
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/register.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "qom/object.h"
+#include "migration/vmstate.h"
+#include "hw/qdev-properties.h"
+#include "hw/usb/hcd-dwc3.h"
+#include "qapi/error.h"
+
+#ifndef USB_DWC3_ERR_DEBUG
+#define USB_DWC3_ERR_DEBUG 0
+#endif
+
+#define HOST_MODE   1
+#define FIFO_LEN 0x1000
+
+REG32(GSBUSCFG0, 0x00)
+FIELD(GSBUSCFG0, DATRDREQINFO, 28, 4)
+FIELD(GSBUSCFG0, DESRDREQINFO, 24, 4)
+FIELD(GSBUSCFG0, DATWRREQINFO, 20, 4)
+FIELD(GSBUSCFG0, DESWRREQINFO, 16, 4)
+FIELD(GSBUSCFG0, RESERVED_15_12, 12, 4)
+FIELD(GSBUSCFG0, DATBIGEND, 11, 1)
+FIELD(GSBUSCFG0, DESBIGEND, 10, 1)
+FIELD(GSBUSCFG0, RESERVED_9_8, 8, 2)
+FIELD(GSBUSCFG0, INCR256BRSTENA, 7, 1)
+FIELD(GSBUSCFG0, INCR128BRSTENA, 6, 1)
+FIELD(GSBUSCFG0, INCR64BRSTENA, 5, 1)
+FIELD(GSBUSCFG0, INCR32BRSTENA, 4, 1)
+FIELD(GSBUSCFG0, INCR16BRSTENA, 3, 1)
+FIELD(GSBUSCFG0, INCR8BRSTENA, 2, 1)
+FIELD(GSBUSCFG0, INCR4BRSTENA, 1, 1)
+FIELD(GSBUSCFG0, INCRBRSTENA, 0, 1)
+REG32(GSBUSCFG1, 0x04)
+FIELD(GSBUSCFG1, RESERVED_31_13, 13, 19)
+FIELD(GSBUSCFG1, EN1KPAGE, 12, 1)
+FIELD(GSBUSCFG1, PIPETRANSLIMIT, 8, 4)
+FIELD(GSBUSCFG1, RESERVED_7_0, 0, 8)
+REG32(GTXTHRCFG, 0x08)
+FIELD(GTXTHRCFG, RESERVED_31, 31, 1)
+FIELD(GTXTHRCFG, RESERVED_30, 30, 1)
+FIELD(GTXTHRCFG, USBTXPKTCNTSEL, 29, 1)
+FIELD(GTXTHRCFG, RESERVED_28, 28, 1)
+FIELD(GTXTHRCFG, USBTXPKTCNT, 24, 4)
+FIELD(GTXTHRCFG, USBMAXTXBURSTSIZE, 16, 8)
+FIELD(GTXTHRCFG, RESERVED_15, 15, 1)
+FIELD(GTXTHRCFG, RESERVED_14, 14, 1)
+FIELD(GTXTHRCFG, RESERVED_13_11, 11, 3)
+FIELD(GTXTHRCFG, RESERVED_10_0, 0, 11)
+REG32(GRXTHRCFG, 0x0c)
+FIELD(GRXTHRCFG, RESERVED_31_30, 30, 2)
+FIELD(GRXTHRCFG, USBRXPKTCNTSEL, 29, 1)
+FIELD(GRXTHRCFG, RESERVED_28, 28, 1)
+FIELD(GRXTHRCFG, USBRXPKTCNT, 24, 4)
+FIELD(GRXTHRCFG, USBMAXRXBURSTSIZE, 19, 5)
+FIELD(GRXTHRCFG, RESERVED_18_16, 16, 3)
+FIELD(GRXTHRCFG, RESERVED_15, 15, 1)
+FIELD(GRXTHRCFG, RESERVED_14_13, 13, 2)
+FIELD(GRXTHRCFG, RESVISOCOUTSPC, 0, 13)
+REG32(GCTL, 0x10)
+FIELD(GCTL, PWRDNSCALE, 19, 13)
+FIELD(GCTL, 

[PATCH v13 1/4] usb: Add versal-usb2-ctrl-regs module

[Sai Pavan Boddu]

This module emulates control registers of versal usb2 controller, this is added
just to make guest happy. In general this module would control the phy-reset
signal from usb controller, data coherency of the transactions, signals
the host system errors received from controller.

Signed-off-by: Sai Pavan Boddu 
Signed-off-by: Vikram Garhwal 
Reviewed-by: Edgar E. Iglesias 
---
 hw/usb/meson.build  |   1 +
 hw/usb/xlnx-versal-usb2-ctrl-regs.c | 229 
 include/hw/usb/xlnx-versal-usb2-ctrl-regs.h |  45 ++
 3 files changed, 275 insertions(+)
 create mode 100644 hw/usb/xlnx-versal-usb2-ctrl-regs.c
 create mode 100644 include/hw/usb/xlnx-versal-usb2-ctrl-regs.h

diff --git a/hw/usb/meson.build b/hw/usb/meson.build
index 934e4fa..ecfec0a 100644
--- a/hw/usb/meson.build
+++ b/hw/usb/meson.build
@@ -30,6 +30,7 @@ softmmu_ss.add(when: 'CONFIG_USB_DWC2', if_true: 
files('hcd-dwc2.c'))
 softmmu_ss.add(when: 'CONFIG_TUSB6010', if_true: files('tusb6010.c'))
 softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('chipidea.c'))
 softmmu_ss.add(when: 'CONFIG_IMX_USBPHY', if_true: files('imx-usb-phy.c'))
+specific_ss.add(when: 'CONFIG_XLNX_VERSAL', if_true: 
files('xlnx-versal-usb2-ctrl-regs.c'))
 
 # emulated usb devices
 softmmu_ss.add(when: 'CONFIG_USB', if_true: files('dev-hub.c'))
diff --git a/hw/usb/xlnx-versal-usb2-ctrl-regs.c 
b/hw/usb/xlnx-versal-usb2-ctrl-regs.c
new file mode 100644
index 000..9eaa59e
--- /dev/null
+++ b/hw/usb/xlnx-versal-usb2-ctrl-regs.c
@@ -0,0 +1,229 @@
+/*
+ * QEMU model of the VersalUsb2CtrlRegs Register control/Status block for
+ * USB2.0 controller
+ *
+ * This module should control phy_reset, permanent device plugs, frame length
+ * time adjust & setting of coherency paths. None of which are emulated in
+ * present model.
+ *
+ * Copyright (c) 2020 Xilinx Inc. Vikram Garhwal 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/irq.h"
+#include "hw/register.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "qom/object.h"
+#include "migration/vmstate.h"
+#include "hw/usb/xlnx-versal-usb2-ctrl-regs.h"
+
+#ifndef XILINX_VERSAL_USB2_CTRL_REGS_ERR_DEBUG
+#define XILINX_VERSAL_USB2_CTRL_REGS_ERR_DEBUG 0
+#endif
+
+REG32(BUS_FILTER, 0x30)
+FIELD(BUS_FILTER, BYPASS, 0, 4)
+REG32(PORT, 0x34)
+FIELD(PORT, HOST_SMI_BAR_WR, 4, 1)
+FIELD(PORT, HOST_SMI_PCI_CMD_REG_WR, 3, 1)
+FIELD(PORT, HOST_MSI_ENABLE, 2, 1)
+FIELD(PORT, PWR_CTRL_PRSNT, 1, 1)
+FIELD(PORT, HUB_PERM_ATTACH, 0, 1)
+REG32(JITTER_ADJUST, 0x38)
+FIELD(JITTER_ADJUST, FLADJ, 0, 6)
+REG32(BIGENDIAN, 0x40)
+FIELD(BIGENDIAN, ENDIAN_GS, 0, 1)
+REG32(COHERENCY, 0x44)
+FIELD(COHERENCY, USB_COHERENCY, 0, 1)
+REG32(XHC_BME, 0x48)
+FIELD(XHC_BME, XHC_BME, 0, 1)
+REG32(REG_CTRL, 0x60)
+FIELD(REG_CTRL, SLVERR_ENABLE, 0, 1)
+REG32(IR_STATUS, 0x64)
+FIELD(IR_STATUS, HOST_SYS_ERR, 1, 1)
+FIELD(IR_STATUS, ADDR_DEC_ERR, 0, 1)
+REG32(IR_MASK, 0x68)
+FIELD(IR_MASK, HOST_SYS_ERR, 1, 1)
+FIELD(IR_MASK, ADDR_DEC_ERR, 0, 1)
+REG32(IR_ENABLE, 0x6c)
+FIELD(IR_ENABLE, HOST_SYS_ERR, 1, 1)
+FIELD(IR_ENABLE, ADDR_DEC_ERR, 0, 1)
+REG32(IR_DISABLE, 0x70)
+FIELD(IR_DISABLE, HOST_SYS_ERR, 1, 1)
+FIELD(IR_DISABLE, ADDR_DEC_ERR, 0, 1)
+REG32(USB3, 0x78)
+
+static void ir_update_irq(VersalUsb2CtrlRegs *s)
+{
+bool pending = s->regs[R_IR_STATUS] & ~s->regs[R_IR_MASK];
+qemu_set_irq(s->irq_ir, pending);
+}
+
+static void ir_status_postw(RegisterInfo *reg, uint64_t val64)
+{
+VersalUsb2CtrlRegs *s = XILINX_VERSAL_USB2_CTRL_REGS(reg->opaque);
+/*
+ * TODO: This should also clear USBSTS.HSE field in USB XHCI register.
+ * May be combine both the modules.
+ */
+ir_update_irq(s);
+}
+
+static uint64_t ir_enable_prew(RegisterInfo *reg, uint64_t val64)
+{
+VersalUsb2CtrlRegs *s = 

[PATCH 2/2] virtiofsd: check whether lo_map_reserve returns NULL in main func

[Haotian Li]

In main func, func lo_map_reserve is called without NULL check.
If reallocing new_elems fails in func lo_map_grow, the func
lo_map_reserve may return NULL. We should check whether
lo_map_reserve returns NULL before using it.

Signed-off-by: Haotian Li 
Signed-off-by: Zhiqiang Liu 
---
 tools/virtiofsd/passthrough_ll.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index ec1008bceb..0c279ff9fb 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -3433,6 +3433,7 @@ int main(int argc, char *argv[])
 .proc_self_fd = -1,
 };
 struct lo_map_elem *root_elem;
+struct lo_map_elem *reserve_elem;
 int ret = -1;

 /* Don't mask creation mode, kernel already did that */
@@ -3452,8 +3453,15 @@ int main(int argc, char *argv[])
  * [1] Root inode
  */
 lo_map_init(_map);
-lo_map_reserve(_map, 0)->in_use = false;
+reserve_elem = lo_map_reserve(_map, 0);
+if (!reserve_elem) {
+goto err_out1;
+}
+reserve_elem->in_use = false;
 root_elem = lo_map_reserve(_map, lo.root.fuse_ino);
+if (!root_elem) {
+goto err_out1;
+}
 root_elem->inode = 

 lo_map_init(_map);
-- 

[PATCH 1/2] tools/virtiofsd/buffer.c: check whether buf is NULL in fuse_bufvec_advance func

[Haotian Li]

In fuse_bufvec_advance func, calling fuse_bufvec_current func
may return NULL, so we should check whether buf is NULL before
using it.

Signed-off-by: Haotian Li 
Signed-off-by: Zhiqiang Liu 
---
 tools/virtiofsd/buffer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/virtiofsd/buffer.c b/tools/virtiofsd/buffer.c
index 27c1377f22..bdc608c221 100644
--- a/tools/virtiofsd/buffer.c
+++ b/tools/virtiofsd/buffer.c
@@ -246,6 +246,10 @@ static int fuse_bufvec_advance(struct fuse_bufvec *bufv, 
size_t len)
 {
 const struct fuse_buf *buf = fuse_bufvec_current(bufv);

+if (!buf) {
+return 0;
+}
+
 bufv->off += len;
 assert(bufv->off <= buf->size);
 if (bufv->off == buf->size) {
-- 

[PATCH v2 0/2] virtiofsd: fix some accessing NULL pointer problem

[Haotian Li]

Haotian Li (2):
  tools/virtiofsd/buffer.c: check whether buf is NULL in
fuse_bufvec_advance func
  virtiofsd/passthrough_ll.c: check whether lo_map_reserve returns NULL
in main func

 tools/virtiofsd/buffer.c |  4 
 tools/virtiofsd/passthrough_ll.c | 10 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

-- 

Re: QMP and the 'id' parameter

[Markus Armbruster]

John Snow  writes:

> The QMP specification states:
>
>> NOTE: Some errors can occur before the Server is able to read the "id"
>> member, in these cases the "id" member will not be part of the error
>> response, even if provided by the client.
>
> I am assuming this case ONLY occurs for Parse errors:
>
> {'class': 'GenericError', 'desc': 'JSON parse error, expecting value'}

There are more "desc" possible, actually.

The JSON parser gets fed chunks of input, and calls a callback for every
full JSON value, and on parse error.

QMP's callback is handle_qmp_command().  Parameter @req is the parsed
JSON value, parameter @err is the (parse) error object, and exactly one
of them is non-null.

1. Parse error

If @err, we send an error response for it.  It never has "id".  See
qmp_error_response() caller monitor_qmp_dispatcher_co().  The possible
@err are:

$ grep error_setg qobject/json-*[ch]
qobject/json-parser.c:error_setg(>err, "JSON parse error, %s", 
message);

This is a syntax error.

Search for parse_error() to see the possible @message patterns.

qobject/json-streamer.c:error_setg(, "JSON parse error, stray 
'%s'", input->str);

This is a lexical error.

qobject/json-streamer.c:error_setg(, "JSON token size limit 
exceeded");
qobject/json-streamer.c:error_setg(, "JSON token count limit 
exceeded");
qobject/json-streamer.c:error_setg(, "JSON nesting depth limit 
exceeded");

These are (intentional) parser limits.

2. Successful parse

If @req, it's a successful parse.

If @req is not a JSON object, there is no "id".  qmp_dispatch() reports

error_setg(, "QMP input must be a JSON object");

If @req is a JSON object, it has "id" exactly when the client supplied
one.  The response mirrors @req's "id".  See qmp_error_response() caller
qmp_dispatch().

> And I am assuming, in the context of a client that /always/ sets an
> 'id' for its execute statements, that this means that any error
> response we receive without an 'id' field *must* be associated with
> the most-recently-sent command.

Only if the client keeps no more than one command in flight.

Command responses get sent strictly in order (even parse errors), except
for commands executed out-of-band.

If the client sends N JSON values, and only then reads responses, and
there are no parse errors, then it'll get N responses.  The i-th
response is for the i-th JSON value, except responses to OOB command may
"jump the queue".

With parse errors, it can get a different number of responses.

Questions?

[PATCH 3/4] block/throttle-groups.c: Use lock guard macros

[Gan Qixin]

Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/throttle-groups.c.

Signed-off-by: Gan Qixin 
---
 block/throttle-groups.c | 48 -
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/block/throttle-groups.c b/block/throttle-groups.c
index e2f2813c0f..badb93a3be 100644
--- a/block/throttle-groups.c
+++ b/block/throttle-groups.c
@@ -546,7 +546,7 @@ void throttle_group_register_tgm(ThrottleGroupMember *tgm,
 tgm->aio_context = ctx;
 qatomic_set(>restart_pending, 0);
 
-qemu_mutex_lock(>lock);
+QEMU_LOCK_GUARD(>lock);
 /* If the ThrottleGroup is new set this ThrottleGroupMember as the token */
 for (i = 0; i < 2; i++) {
 if (!tg->tokens[i]) {
@@ -565,8 +565,6 @@ void throttle_group_register_tgm(ThrottleGroupMember *tgm,
 qemu_co_mutex_init(>throttled_reqs_lock);
 qemu_co_queue_init(>throttled_reqs[0]);
 qemu_co_queue_init(>throttled_reqs[1]);
-
-qemu_mutex_unlock(>lock);
 }
 
 /* Unregister a ThrottleGroupMember from its group, removing it from the list,
@@ -594,25 +592,25 @@ void throttle_group_unregister_tgm(ThrottleGroupMember 
*tgm)
 /* Wait for throttle_group_restart_queue_entry() coroutines to finish */
 AIO_WAIT_WHILE(tgm->aio_context, qatomic_read(>restart_pending) > 0);
 
-qemu_mutex_lock(>lock);
-for (i = 0; i < 2; i++) {
-assert(tgm->pending_reqs[i] == 0);
-assert(qemu_co_queue_empty(>throttled_reqs[i]));
-assert(!timer_pending(tgm->throttle_timers.timers[i]));
-if (tg->tokens[i] == tgm) {
-token = throttle_group_next_tgm(tgm);
-/* Take care of the case where this is the last tgm in the group */
-if (token == tgm) {
-token = NULL;
+WITH_QEMU_LOCK_GUARD(>lock) {
+for (i = 0; i < 2; i++) {
+assert(tgm->pending_reqs[i] == 0);
+assert(qemu_co_queue_empty(>throttled_reqs[i]));
+assert(!timer_pending(tgm->throttle_timers.timers[i]));
+if (tg->tokens[i] == tgm) {
+token = throttle_group_next_tgm(tgm);
+/* Take care of the case where this is the last tgm in the 
group */
+if (token == tgm) {
+token = NULL;
+}
+tg->tokens[i] = token;
 }
-tg->tokens[i] = token;
 }
-}
 
-/* remove the current tgm from the list */
-QLIST_REMOVE(tgm, round_robin);
-throttle_timers_destroy(>throttle_timers);
-qemu_mutex_unlock(>lock);
+/* remove the current tgm from the list */
+QLIST_REMOVE(tgm, round_robin);
+throttle_timers_destroy(>throttle_timers);
+}
 
 throttle_group_unref(>ts);
 tgm->throttle_state = NULL;
@@ -638,14 +636,14 @@ void 
throttle_group_detach_aio_context(ThrottleGroupMember *tgm)
 assert(qemu_co_queue_empty(>throttled_reqs[1]));
 
 /* Kick off next ThrottleGroupMember, if necessary */
-qemu_mutex_lock(>lock);
-for (i = 0; i < 2; i++) {
-if (timer_pending(tt->timers[i])) {
-tg->any_timer_armed[i] = false;
-schedule_next_request(tgm, i);
+ WITH_QEMU_LOCK_GUARD(>lock) {
+for (i = 0; i < 2; i++) {
+if (timer_pending(tt->timers[i])) {
+tg->any_timer_armed[i] = false;
+schedule_next_request(tgm, i);
+}
 }
 }
-qemu_mutex_unlock(>lock);
 
 throttle_timers_detach_aio_context(tt);
 tgm->aio_context = NULL;
-- 
2.23.0

[PATCH 2/4] block/curl.c: Use lock guard macros

[Gan Qixin]

Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/curl.c.

Signed-off-by: Gan Qixin 
---
 block/curl.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/block/curl.c b/block/curl.c
index 4f907c47be..d24a4c5897 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -564,23 +564,23 @@ static void curl_detach_aio_context(BlockDriverState *bs)
 BDRVCURLState *s = bs->opaque;
 int i;
 
-qemu_mutex_lock(>mutex);
-for (i = 0; i < CURL_NUM_STATES; i++) {
-if (s->states[i].in_use) {
-curl_clean_state(>states[i]);
+WITH_QEMU_LOCK_GUARD(>mutex) {
+for (i = 0; i < CURL_NUM_STATES; i++) {
+if (s->states[i].in_use) {
+curl_clean_state(>states[i]);
+}
+if (s->states[i].curl) {
+curl_easy_cleanup(s->states[i].curl);
+s->states[i].curl = NULL;
+}
+g_free(s->states[i].orig_buf);
+s->states[i].orig_buf = NULL;
 }
-if (s->states[i].curl) {
-curl_easy_cleanup(s->states[i].curl);
-s->states[i].curl = NULL;
+if (s->multi) {
+curl_multi_cleanup(s->multi);
+s->multi = NULL;
 }
-g_free(s->states[i].orig_buf);
-s->states[i].orig_buf = NULL;
-}
-if (s->multi) {
-curl_multi_cleanup(s->multi);
-s->multi = NULL;
 }
-qemu_mutex_unlock(>mutex);
 
 timer_del(>timer);
 }
-- 
2.23.0

[PATCH 1/4] block/accounting.c: Use lock guard macros

[Gan Qixin]

Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/accounting.c.

Signed-off-by: Gan Qixin 
---
 block/accounting.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/block/accounting.c b/block/accounting.c
index 8d41c8a83a..2030851d79 100644
--- a/block/accounting.c
+++ b/block/accounting.c
@@ -199,29 +199,27 @@ static void block_account_one_io(BlockAcctStats *stats, 
BlockAcctCookie *cookie,
 return;
 }
 
-qemu_mutex_lock(>lock);
-
-if (failed) {
-stats->failed_ops[cookie->type]++;
-} else {
-stats->nr_bytes[cookie->type] += cookie->bytes;
-stats->nr_ops[cookie->type]++;
-}
+WITH_QEMU_LOCK_GUARD(>lock) {
+if (failed) {
+stats->failed_ops[cookie->type]++;
+} else {
+stats->nr_bytes[cookie->type] += cookie->bytes;
+stats->nr_ops[cookie->type]++;
+}
 
-block_latency_histogram_account(>latency_histogram[cookie->type],
-latency_ns);
+
block_latency_histogram_account(>latency_histogram[cookie->type],
+latency_ns);
 
-if (!failed || stats->account_failed) {
-stats->total_time_ns[cookie->type] += latency_ns;
-stats->last_access_time_ns = time_ns;
+if (!failed || stats->account_failed) {
+stats->total_time_ns[cookie->type] += latency_ns;
+stats->last_access_time_ns = time_ns;
 
-QSLIST_FOREACH(s, >intervals, entries) {
-timed_average_account(>latency[cookie->type], latency_ns);
+QSLIST_FOREACH(s, >intervals, entries) {
+timed_average_account(>latency[cookie->type], latency_ns);
+}
 }
 }
 
-qemu_mutex_unlock(>lock);
-
 cookie->type = BLOCK_ACCT_NONE;
 }
 
-- 
2.23.0

[PATCH 4/4] block/iscsi.c: Use lock guard macros

[Gan Qixin]

Replace manual lock()/unlock() calls with lock guard macros
(QEMU_LOCK_GUARD/WITH_QEMU_LOCK_GUARD) in block/iscsi.c.

Signed-off-by: Gan Qixin 
---
 block/iscsi.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index e30a7e3606..f5f657b582 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -322,7 +322,7 @@ iscsi_aio_cancel(BlockAIOCB *blockacb)
 IscsiAIOCB *acb = (IscsiAIOCB *)blockacb;
 IscsiLun *iscsilun = acb->iscsilun;
 
-qemu_mutex_lock(>mutex);
+QEMU_LOCK_GUARD(>mutex);
 
 /* If it was cancelled or completed already, our work is done here */
 if (acb->cancelled || acb->status != -EINPROGRESS) {
@@ -339,8 +339,6 @@ iscsi_aio_cancel(BlockAIOCB *blockacb)
  iscsi_abort_task_cb, acb) < 0) {
 qemu_aio_unref(acb); /* since iscsi_abort_task_cb() won't be called */
 }
-
-qemu_mutex_unlock(>mutex);
 }
 
 static const AIOCBInfo iscsi_aiocb_info = {
@@ -375,22 +373,22 @@ static void iscsi_timed_check_events(void *opaque)
 {
 IscsiLun *iscsilun = opaque;
 
-qemu_mutex_lock(>mutex);
+WITH_QEMU_LOCK_GUARD(>mutex) {
+/* check for timed out requests */
+iscsi_service(iscsilun->iscsi, 0);
 
-/* check for timed out requests */
-iscsi_service(iscsilun->iscsi, 0);
+if (iscsilun->request_timed_out) {
+iscsilun->request_timed_out = false;
+iscsi_reconnect(iscsilun->iscsi);
+}
 
-if (iscsilun->request_timed_out) {
-iscsilun->request_timed_out = false;
-iscsi_reconnect(iscsilun->iscsi);
+/*
+ * newer versions of libiscsi may return zero events. Ensure we are
+ * able to return to service once this situation changes.
+ */
+iscsi_set_events(iscsilun);
 }
 
-/* newer versions of libiscsi may return zero events. Ensure we are able
- * to return to service once this situation changes. */
-iscsi_set_events(iscsilun);
-
-qemu_mutex_unlock(>mutex);
-
 timer_mod(iscsilun->event_timer,
   qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + EVENT_INTERVAL);
 }
-- 
2.23.0

[PATCH 0/4] Use lock guard macros in block

[Gan Qixin]

Hi all,
  I saw some tasks to replace manual lock()/unlock() calls with lock guard 
macros in BiteSizedTasks.
I am very interested in this and modified some of the files under block. Could 
someone help me check the code?

Thanks,
Gan Qixin

Gan Qixin (4):
  block/accounting.c: Use lock guard macros
  block/curl.c: Use lock guard macros
  block/throttle-groups.c: Use lock guard macros
  block/iscsi.c: Use lock guard macros

 block/accounting.c  | 32 +--
 block/curl.c| 28 
 block/iscsi.c   | 28 +++-
 block/throttle-groups.c | 48 -
 4 files changed, 65 insertions(+), 71 deletions(-)

-- 
2.23.0

Re: [PATCH 0/2] virtiofsd: fix some accessing NULL pointer problem

[Haotian Li]

Hi,
Thanks for your suggestion. We will fix the coding style
problems and resend new patches.

> Patchew URL: 
> https://patchew.org/QEMU/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com/
> 
> 
> 
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Message-id: eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com
> Subject: [PATCH 0/2] virtiofsd: fix some accessing NULL pointer problem
> Type: series
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> git rev-parse base > /dev/null || exit 0
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> git config --local diff.algorithm histogram
> ./scripts/checkpatch.pl --mailback base..
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
>  - [tag update]  patchew/20201028185722.2783532-1-kei...@keithp.com -> 
> patchew/20201028185722.2783532-1-kei...@keithp.com
>  * [new tag] patchew/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com 
> -> patchew/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com
> Switched to a new branch 'test'
> c91e972 virtiofsd: check whether lo_map_reserve returns NULL in main func
> 387bda7 tools/virtiofsd/buffer.c: check whether buf is NULL in 
> fuse_bufvec_advance func
> 
> === OUTPUT BEGIN ===
> 1/2 Checking commit 387bda78be64 (tools/virtiofsd/buffer.c: check whether buf 
> is NULL in fuse_bufvec_advance func)
> ERROR: braces {} are necessary for all arms of this statement
> #23: FILE: tools/virtiofsd/buffer.c:249:
> +if (!buf)
> [...]
> 
> total: 1 errors, 0 warnings, 9 lines checked
> 
> Patch 1/2 has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> 2/2 Checking commit c91e9722f323 (virtiofsd: check whether lo_map_reserve 
> returns NULL in main func)
> ERROR: braces {} are necessary for all arms of this statement
> #34: FILE: tools/virtiofsd/passthrough_ll.c:3457:
> +if (!reserve_elem)
> [...]
> 
> ERROR: braces {} are necessary for all arms of this statement
> #38: FILE: tools/virtiofsd/passthrough_ll.c:3461:
> +if (!root_elem)
> [...]
> 
> total: 2 errors, 0 warnings, 21 lines checked
> 
> Patch 2/2 has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> === OUTPUT END ===
> 
> Test command exited with code: 1
> 
> 
> The full log is available at
> http://patchew.org/logs/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com/testing.checkpatch/?type=message.
> ---
> Email generated automatically by Patchew [https://patchew.org/].
> Please send your feedback to patchew-de...@redhat.com
> 

Re: [PATCH 1/4] semihosting: Move ARM semihosting code to shared directories [v3]

[Keith Packard]

Alistair Francis  writes:

> Reviewed-by: Alistair Francis 

Thanks much. I think we'll need some help getting the next two patches
reviewed; that touches ARM code. The last patch is also RISC-V only.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PULL 0/6] riscv-to-apply queue

[Alistair Francis]

On Mon, Nov 9, 2020 at 8:09 PM Alistair Francis
 wrote:
>
> The following changes since commit 3c8c36c9087da957f580a9bb5ebf7814a753d1c6:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/ui-20201104-pull-request' 
> into staging (2020-11-04 16:52:17 +)
>
> are available in the Git repository at:
>
>   g...@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20201109
>
> for you to fetch changes up to 96338fefc19a143abdc91f6c44f37683274b08d4:
>
>   hw/intc/ibex_plic: Clear the claim register when read (2020-11-09 15:09:53 
> -0800)
>
> 
> This fixes two bugs in the RISC-V port. One is a bug in the
> Ibex PLIC, the other fixes the Hypvervisor access functions.
>
> 
> Alistair Francis (6):
>   target/riscv: Add a virtualised MMU Mode
>   target/riscv: Set the virtualised MMU mode when doing hyp accesses
>   target/riscv: Remove the HS_TWO_STAGE flag
>   target/riscv: Remove the hyp load and store functions
>   target/riscv: Split the Hypervisor execute load helpers
>   hw/intc/ibex_plic: Clear the claim register when read

Just a note, the hypervisor related changes look like a big diff for
this late in the cycle. That is true, but the current implementation
(added in this release cycle) is broken and this fixes it. Also most
of the changes only affect the Hypervisor extensions, which are still
experiemental.

Alistair

>
>  target/riscv/cpu-param.h|  11 ++-
>  target/riscv/cpu.h  |  19 -
>  target/riscv/cpu_bits.h |   1 -
>  target/riscv/helper.h   |   5 +-
>  hw/intc/ibex_plic.c |   3 +
>  target/riscv/cpu_helper.c   |  62 ++
>  target/riscv/op_helper.c| 124 ++-
>  target/riscv/translate.c|   2 +
>  target/riscv/insn_trans/trans_rvh.c.inc | 143 
> 
>  9 files changed, 115 insertions(+), 255 deletions(-)

Re: [RFC v5 00/68] support vector extension v1.0

[Alistair Francis]

On Mon, Nov 9, 2020 at 6:09 PM Frank Chang  wrote:
>
> ping 2nd~

I mentioned earlier that I will wait until this becomes a patch series
to review it. Overall it looks like it's on the right track though.

Alistair

>
> On Tue, Oct 20, 2020 at 3:42 PM Frank Chang  wrote:
>>
>> On Wed, Sep 30, 2020 at 3:04 AM  wrote:
>>>
>>> From: Frank Chang 
>>>
>>> This patchset implements the vector extension v1.0 for RISC-V on QEMU.
>>>
>>> This patchset is sent as RFC because RVV v1.0 is still in draft state.
>>> v2 patchset was sent for RVV v0.9 and bumped to RVV v1.0 since v3 patchset.
>>>
>>> The port is available here:
>>> https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v5
>>>
>>> You can change the cpu argument: vext_spec to v1.0 (i.e. vext_spec=v1.0)
>>> to run with RVV v1.0 instructions.
>>>
>>> Note: This patchset depends on two other patchsets listed in Based-on
>>>   section below so it might not able to be built unless those two
>>>   patchsets are applied.
>>>
>>> Changelog:
>>>
>>> v5
>>>   * refactor RVV v1.0 check functions.
>>> (Thanks to Richard Henderson's bitwise tricks.)
>>>   * relax RV_VLEN_MAX to 1024-bits.
>>>   * implement vstart CSR's behaviors.
>>>   * trigger illegal instruction exception if frm is not valid for
>>> vector floating-point instructions.
>>>   * rebase on riscv-to-apply.next.
>>>
>>> v4
>>>   * remove explicit float flmul variable in DisasContext.
>>>   * replace floating-point calculations with shift operations to
>>> improve performance.
>>>   * relax RV_VLEN_MAX to 512-bits.
>>>
>>> v3
>>>   * apply nan-box helpers from Richard Henderson.
>>>   * remove fp16 api changes as they are sent independently in another
>>> pathcset by Chih-Min Chao.
>>>   * remove all tail elements clear functions as tail elements can
>>> retain unchanged for either VTA set to undisturbed or agnostic.
>>>   * add fp16 nan-box check generator function.
>>>   * add floating-point rounding mode enum.
>>>   * replace flmul arithmetic with shifts to avoid floating-point
>>> conversions.
>>>   * add Zvqmac extension.
>>>   * replace gdbstub vector register xml files with dynamic generator.
>>>   * bumped to RVV v1.0.
>>>   * RVV v1.0 related changes:
>>> * add vlre.v and vsr.v vector whole register
>>>   load/store instructions
>>> * add vrgatherei16 instruction.
>>> * rearranged bits in vtype to make vlmul bits into a contiguous
>>>   field.
>>>
>>> v2
>>>   * drop v0.7.1 support.
>>>   * replace invisible return check macros with functions.
>>>   * move mark_vs_dirty() to translators.
>>>   * add SSTATUS_VS flag for s-mode.
>>>   * nan-box scalar fp register for floating-point operations.
>>>   * add gdbstub files for vector registers to allow system-mode
>>> debugging with GDB.
>>>
>>> Based-on: <20200909001647.532249-1-richard.hender...@linaro.org/>
>>> Based-on: <1596102747-20226-1-git-send-email-chihmin.c...@sifive.com/>
>>>
>>> Frank Chang (62):
>>>   target/riscv: drop vector 0.7.1 and add 1.0 support
>>>   target/riscv: Use FIELD_EX32() to extract wd field
>>>   target/riscv: rvv-1.0: introduce writable misa.v field
>>>   target/riscv: rvv-1.0: add translation-time vector context status
>>>   target/riscv: rvv-1.0: remove rvv related codes from fcsr registers
>>>   target/riscv: rvv-1.0: check MSTATUS_VS when accessing vector csr
>>> registers
>>>   target/riscv: rvv-1.0: remove MLEN calculations
>>>   target/riscv: rvv-1.0: add fractional LMUL
>>>   target/riscv: rvv-1.0: add VMA and VTA
>>>   target/riscv: rvv-1.0: update check functions
>>>   target/riscv: introduce more imm value modes in translator functions
>>>   target/riscv: rvv:1.0: add translation-time nan-box helper function
>>>   target/riscv: rvv-1.0: configure instructions
>>>   target/riscv: rvv-1.0: stride load and store instructions
>>>   target/riscv: rvv-1.0: index load and store instructions
>>>   target/riscv: rvv-1.0: fix address index overflow bug of indexed
>>> load/store insns
>>>   target/riscv: rvv-1.0: fault-only-first unit stride load
>>>   target/riscv: rvv-1.0: amo operations
>>>   target/riscv: rvv-1.0: load/store whole register instructions
>>>   target/riscv: rvv-1.0: update vext_max_elems() for load/store insns
>>>   target/riscv: rvv-1.0: take fractional LMUL into vector max elements
>>> calculation
>>>   target/riscv: rvv-1.0: floating-point square-root instruction
>>>   target/riscv: rvv-1.0: floating-point classify instructions
>>>   target/riscv: rvv-1.0: mask population count instruction
>>>   target/riscv: rvv-1.0: find-first-set mask bit instruction
>>>   target/riscv: rvv-1.0: set-X-first mask bit instructions
>>>   target/riscv: rvv-1.0: iota instruction
>>>   target/riscv: rvv-1.0: element index instruction
>>>   target/riscv: rvv-1.0: allow load element with sign-extended
>>>   target/riscv: rvv-1.0: register gather instructions
>>>   target/riscv: rvv-1.0: integer scalar move instructions
>>>   target/riscv: rvv-1.0: 

[PULL 6/6] hw/intc/ibex_plic: Clear the claim register when read

[Alistair Francis]

After claiming the interrupt by reading the claim register we want to
clear the register to make sure the interrupt doesn't appear at the next
read.

This matches the documentation for the claim register as when an interrupt
is claimed by a target the relevant bit of IP is cleared (which we already
do): https://docs.opentitan.org/hw/ip/rv_plic/doc/index.html

This also matches the current hardware.

Signed-off-by: Alistair Francis 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 
68d4575deef2559b7a747f3bda193fcf43af4558.1604629928.git.alistair.fran...@wdc.com
---
 hw/intc/ibex_plic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/intc/ibex_plic.c b/hw/intc/ibex_plic.c
index f49fa67c91..235e6b88ff 100644
--- a/hw/intc/ibex_plic.c
+++ b/hw/intc/ibex_plic.c
@@ -139,6 +139,9 @@ static uint64_t ibex_plic_read(void *opaque, hwaddr addr,
 /* Return the current claimed interrupt */
 ret = s->claim;
 
+/* Clear the claimed interrupt */
+s->claim = 0x;
+
 /* Update the interrupt status after the claim */
 ibex_plic_update(s);
 }
-- 
2.29.2

[PULL 5/6] target/riscv: Split the Hypervisor execute load helpers

[Alistair Francis]

Split the hypervisor execute load functions into two seperate functions.
This avoids us having to pass the memop to the C helper functions.

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
Message-id: 
5b1550f0faa3c435cc77f3c1ae811dea98ab9e36.1604464950.git.alistair.fran...@wdc.com
---
 target/riscv/helper.h   |  3 ++-
 target/riscv/op_helper.c| 36 +++--
 target/riscv/insn_trans/trans_rvh.c.inc | 20 +-
 3 files changed, 17 insertions(+), 42 deletions(-)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index ee35311052..939731c345 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -81,7 +81,8 @@ DEF_HELPER_1(tlb_flush, void, env)
 #ifndef CONFIG_USER_ONLY
 DEF_HELPER_1(hyp_tlb_flush, void, env)
 DEF_HELPER_1(hyp_gvma_tlb_flush, void, env)
-DEF_HELPER_4(hyp_x_load, tl, env, tl, tl, tl)
+DEF_HELPER_2(hyp_hlvx_hu, tl, env, tl)
+DEF_HELPER_2(hyp_hlvx_wu, tl, env, tl)
 #endif
 
 /* Vector functions */
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index 980d4f39e1..d55def76cf 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -227,36 +227,18 @@ void helper_hyp_gvma_tlb_flush(CPURISCVState *env)
 helper_hyp_tlb_flush(env);
 }
 
-target_ulong helper_hyp_x_load(CPURISCVState *env, target_ulong address,
-   target_ulong attrs, target_ulong memop)
+target_ulong helper_hyp_hlvx_hu(CPURISCVState *env, target_ulong address)
 {
-if (env->priv == PRV_M ||
-(env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) ||
-(env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
-get_field(env->hstatus, HSTATUS_HU))) {
-target_ulong pte;
-int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
-
-switch (memop) {
-case MO_TEUW:
-pte = cpu_lduw_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TEUL:
-pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-default:
-g_assert_not_reached();
-}
+int mmu_idx = cpu_mmu_index(env, true) | TB_FLAGS_PRIV_HYP_ACCESS_MASK;
 
-return pte;
-}
+return cpu_lduw_mmuidx_ra(env, address, mmu_idx, GETPC());
+}
 
-if (riscv_cpu_virt_enabled(env)) {
-riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC());
-} else {
-riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
-}
-return 0;
+target_ulong helper_hyp_hlvx_wu(CPURISCVState *env, target_ulong address)
+{
+int mmu_idx = cpu_mmu_index(env, true) | TB_FLAGS_PRIV_HYP_ACCESS_MASK;
+
+return cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
 }
 
 #endif /* !CONFIG_USER_ONLY */
diff --git a/target/riscv/insn_trans/trans_rvh.c.inc 
b/target/riscv/insn_trans/trans_rvh.c.inc
index cc197e7186..ce7ed5affb 100644
--- a/target/riscv/insn_trans/trans_rvh.c.inc
+++ b/target/riscv/insn_trans/trans_rvh.c.inc
@@ -277,20 +277,16 @@ static bool trans_hlvx_hu(DisasContext *ctx, arg_hlvx_hu 
*a)
 #ifndef CONFIG_USER_ONLY
 TCGv t0 = tcg_temp_new();
 TCGv t1 = tcg_temp_new();
-TCGv mem_idx = tcg_temp_new();
-TCGv memop = tcg_temp_new();
+
+check_access(ctx);
 
 gen_get_gpr(t0, a->rs1);
-tcg_gen_movi_tl(mem_idx, ctx->mem_idx);
-tcg_gen_movi_tl(memop, MO_TEUW);
 
-gen_helper_hyp_x_load(t1, cpu_env, t0, mem_idx, memop);
+gen_helper_hyp_hlvx_hu(t1, cpu_env, t0);
 gen_set_gpr(a->rd, t1);
 
 tcg_temp_free(t0);
 tcg_temp_free(t1);
-tcg_temp_free(mem_idx);
-tcg_temp_free(memop);
 return true;
 #else
 return false;
@@ -303,20 +299,16 @@ static bool trans_hlvx_wu(DisasContext *ctx, arg_hlvx_wu 
*a)
 #ifndef CONFIG_USER_ONLY
 TCGv t0 = tcg_temp_new();
 TCGv t1 = tcg_temp_new();
-TCGv mem_idx = tcg_temp_new();
-TCGv memop = tcg_temp_new();
+
+check_access(ctx);
 
 gen_get_gpr(t0, a->rs1);
-tcg_gen_movi_tl(mem_idx, ctx->mem_idx);
-tcg_gen_movi_tl(memop, MO_TEUL);
 
-gen_helper_hyp_x_load(t1, cpu_env, t0, mem_idx, memop);
+gen_helper_hyp_hlvx_wu(t1, cpu_env, t0);
 gen_set_gpr(a->rd, t1);
 
 tcg_temp_free(t0);
 tcg_temp_free(t1);
-tcg_temp_free(mem_idx);
-tcg_temp_free(memop);
 return true;
 #else
 return false;
-- 
2.29.2

[PULL 3/6] target/riscv: Remove the HS_TWO_STAGE flag

[Alistair Francis]

The HS_TWO_STAGE flag is no longer required as the MMU index contains
the information if we are performing a two stage access.

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
Message-id: 
f514b128b1ff0fb41c85f914cee18f905007a922.1604464950.git.alistair.fran...@wdc.com
---
 target/riscv/cpu.h|  3 +-
 target/riscv/cpu_bits.h   |  1 -
 target/riscv/cpu_helper.c | 60 ---
 target/riscv/op_helper.c  | 12 
 4 files changed, 25 insertions(+), 51 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 5d8e54c426..0cf48a1521 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -323,8 +323,7 @@ bool riscv_cpu_virt_enabled(CPURISCVState *env);
 void riscv_cpu_set_virt_enabled(CPURISCVState *env, bool enable);
 bool riscv_cpu_force_hs_excep_enabled(CPURISCVState *env);
 void riscv_cpu_set_force_hs_excep(CPURISCVState *env, bool enable);
-bool riscv_cpu_two_stage_lookup(CPURISCVState *env);
-void riscv_cpu_set_two_stage_lookup(CPURISCVState *env, bool enable);
+bool riscv_cpu_two_stage_lookup(int mmu_idx);
 int riscv_cpu_mmu_index(CPURISCVState *env, bool ifetch);
 hwaddr riscv_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
 void  riscv_cpu_do_unaligned_access(CPUState *cs, vaddr addr,
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index daedad8691..24b24c69c5 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -469,7 +469,6 @@
  * page table fault.
  */
 #define FORCE_HS_EXCEP  2
-#define HS_TWO_STAGE4
 
 /* RV32 satp CSR field masks */
 #define SATP32_MODE 0x8000
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 9dfa7af401..a2787b1d48 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -207,22 +207,9 @@ void riscv_cpu_set_force_hs_excep(CPURISCVState *env, bool 
enable)
 env->virt = set_field(env->virt, FORCE_HS_EXCEP, enable);
 }
 
-bool riscv_cpu_two_stage_lookup(CPURISCVState *env)
+bool riscv_cpu_two_stage_lookup(int mmu_idx)
 {
-if (!riscv_has_ext(env, RVH)) {
-return false;
-}
-
-return get_field(env->virt, HS_TWO_STAGE);
-}
-
-void riscv_cpu_set_two_stage_lookup(CPURISCVState *env, bool enable)
-{
-if (!riscv_has_ext(env, RVH)) {
-return;
-}
-
-env->virt = set_field(env->virt, HS_TWO_STAGE, enable);
+return mmu_idx & TB_FLAGS_PRIV_HYP_ACCESS_MASK;
 }
 
 int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t interrupts)
@@ -333,7 +320,7 @@ static int get_physical_address(CPURISCVState *env, hwaddr 
*physical,
  * was called. Background registers will be used if the guest has
  * forced a two stage translation to be on (in HS or M mode).
  */
-if (riscv_cpu_two_stage_lookup(env) && access_type != MMU_INST_FETCH) {
+if (!riscv_cpu_virt_enabled(env) && riscv_cpu_two_stage_lookup(mmu_idx)) {
 use_background = true;
 }
 
@@ -572,7 +559,7 @@ restart:
 
 static void raise_mmu_exception(CPURISCVState *env, target_ulong address,
 MMUAccessType access_type, bool pmp_violation,
-bool first_stage)
+bool first_stage, bool two_stage)
 {
 CPUState *cs = env_cpu(env);
 int page_fault_exceptions;
@@ -595,8 +582,7 @@ static void raise_mmu_exception(CPURISCVState *env, 
target_ulong address,
 }
 break;
 case MMU_DATA_LOAD:
-if ((riscv_cpu_virt_enabled(env) || riscv_cpu_two_stage_lookup(env)) &&
-!first_stage) {
+if (two_stage && !first_stage) {
 cs->exception_index = RISCV_EXCP_LOAD_GUEST_ACCESS_FAULT;
 } else {
 cs->exception_index = page_fault_exceptions ?
@@ -604,8 +590,7 @@ static void raise_mmu_exception(CPURISCVState *env, 
target_ulong address,
 }
 break;
 case MMU_DATA_STORE:
-if ((riscv_cpu_virt_enabled(env) || riscv_cpu_two_stage_lookup(env)) &&
-!first_stage) {
+if (two_stage && !first_stage) {
 cs->exception_index = RISCV_EXCP_STORE_GUEST_AMO_ACCESS_FAULT;
 } else {
 cs->exception_index = page_fault_exceptions ?
@@ -696,6 +681,7 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int 
size,
 int prot, prot2;
 bool pmp_violation = false;
 bool first_stage_error = true;
+bool two_stage_lookup = false;
 int ret = TRANSLATE_FAIL;
 int mode = mmu_idx;
 target_ulong tlb_size = 0;
@@ -715,11 +701,12 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int 
size,
 access_type != MMU_INST_FETCH &&
 get_field(env->mstatus, MSTATUS_MPRV) &&
 get_field(env->mstatus, MSTATUS_MPV)) {
-riscv_cpu_set_two_stage_lookup(env, true);
+two_stage_lookup = true;
 }
 
 if (riscv_cpu_virt_enabled(env) ||
-(riscv_cpu_two_stage_lookup(env) && access_type != MMU_INST_FETCH)) {
+

[PULL 2/6] target/riscv: Set the virtualised MMU mode when doing hyp accesses

[Alistair Francis]

When performing the hypervisor load/store operations set the MMU mode to
indicate that we are virtualised.

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
Message-id: 
e411c61a1452cad16853f13cac2fb86dc91ebee8.1604464950.git.alistair.fran...@wdc.com
---
 target/riscv/op_helper.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index e20d56dcb8..548c5851ec 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -235,30 +235,31 @@ target_ulong helper_hyp_load(CPURISCVState *env, 
target_ulong address,
 (env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
 get_field(env->hstatus, HSTATUS_HU))) {
 target_ulong pte;
+int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
 
 riscv_cpu_set_two_stage_lookup(env, true);
 
 switch (memop) {
 case MO_SB:
-pte = cpu_ldsb_data_ra(env, address, GETPC());
+pte = cpu_ldsb_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_UB:
-pte = cpu_ldub_data_ra(env, address, GETPC());
+pte = cpu_ldub_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TESW:
-pte = cpu_ldsw_data_ra(env, address, GETPC());
+pte = cpu_ldsw_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TEUW:
-pte = cpu_lduw_data_ra(env, address, GETPC());
+pte = cpu_lduw_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TESL:
-pte = cpu_ldl_data_ra(env, address, GETPC());
+pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TEUL:
-pte = cpu_ldl_data_ra(env, address, GETPC());
+pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TEQ:
-pte = cpu_ldq_data_ra(env, address, GETPC());
+pte = cpu_ldq_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 default:
 g_assert_not_reached();
@@ -284,23 +285,25 @@ void helper_hyp_store(CPURISCVState *env, target_ulong 
address,
 (env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) ||
 (env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
 get_field(env->hstatus, HSTATUS_HU))) {
+int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
+
 riscv_cpu_set_two_stage_lookup(env, true);
 
 switch (memop) {
 case MO_SB:
 case MO_UB:
-cpu_stb_data_ra(env, address, val, GETPC());
+cpu_stb_mmuidx_ra(env, address, val, mmu_idx, GETPC());
 break;
 case MO_TESW:
 case MO_TEUW:
-cpu_stw_data_ra(env, address, val, GETPC());
+cpu_stw_mmuidx_ra(env, address, val, mmu_idx, GETPC());
 break;
 case MO_TESL:
 case MO_TEUL:
-cpu_stl_data_ra(env, address, val, GETPC());
+cpu_stl_mmuidx_ra(env, address, val, mmu_idx, GETPC());
 break;
 case MO_TEQ:
-cpu_stq_data_ra(env, address, val, GETPC());
+cpu_stq_mmuidx_ra(env, address, val, mmu_idx, GETPC());
 break;
 default:
 g_assert_not_reached();
@@ -326,15 +329,16 @@ target_ulong helper_hyp_x_load(CPURISCVState *env, 
target_ulong address,
 (env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
 get_field(env->hstatus, HSTATUS_HU))) {
 target_ulong pte;
+int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
 
 riscv_cpu_set_two_stage_lookup(env, true);
 
 switch (memop) {
 case MO_TEUW:
-pte = cpu_lduw_data_ra(env, address, GETPC());
+pte = cpu_lduw_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 case MO_TEUL:
-pte = cpu_ldl_data_ra(env, address, GETPC());
+pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
 break;
 default:
 g_assert_not_reached();
-- 
2.29.2

[PULL 0/6] riscv-to-apply queue

[Alistair Francis]

The following changes since commit 3c8c36c9087da957f580a9bb5ebf7814a753d1c6:

  Merge remote-tracking branch 'remotes/kraxel/tags/ui-20201104-pull-request' 
into staging (2020-11-04 16:52:17 +)

are available in the Git repository at:

  g...@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20201109

for you to fetch changes up to 96338fefc19a143abdc91f6c44f37683274b08d4:

  hw/intc/ibex_plic: Clear the claim register when read (2020-11-09 15:09:53 
-0800)


This fixes two bugs in the RISC-V port. One is a bug in the
Ibex PLIC, the other fixes the Hypvervisor access functions.


Alistair Francis (6):
  target/riscv: Add a virtualised MMU Mode
  target/riscv: Set the virtualised MMU mode when doing hyp accesses
  target/riscv: Remove the HS_TWO_STAGE flag
  target/riscv: Remove the hyp load and store functions
  target/riscv: Split the Hypervisor execute load helpers
  hw/intc/ibex_plic: Clear the claim register when read

 target/riscv/cpu-param.h|  11 ++-
 target/riscv/cpu.h  |  19 -
 target/riscv/cpu_bits.h |   1 -
 target/riscv/helper.h   |   5 +-
 hw/intc/ibex_plic.c |   3 +
 target/riscv/cpu_helper.c   |  62 ++
 target/riscv/op_helper.c| 124 ++-
 target/riscv/translate.c|   2 +
 target/riscv/insn_trans/trans_rvh.c.inc | 143 
 9 files changed, 115 insertions(+), 255 deletions(-)

[PULL 4/6] target/riscv: Remove the hyp load and store functions

[Alistair Francis]

Remove the special Virtulisation load and store functions and just use
the standard tcg tcg_gen_qemu_ld_tl() and tcg_gen_qemu_st_tl() functions
instead.

As part of this change we ensure we still run an access check to make
sure we can perform the operations.

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
Message-id: 
189ac3e53ef2854824d18aad7074c6649f17de2c.1604464950.git.alistair.fran...@wdc.com
---
 target/riscv/cpu.h  |  12 +++
 target/riscv/helper.h   |   2 -
 target/riscv/op_helper.c|  86 -
 target/riscv/translate.c|   2 +
 target/riscv/insn_trans/trans_rvh.c.inc | 123 +---
 5 files changed, 59 insertions(+), 166 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0cf48a1521..c0a326c843 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -375,6 +375,8 @@ FIELD(TB_FLAGS, VL_EQ_VLMAX, 2, 1)
 FIELD(TB_FLAGS, LMUL, 3, 2)
 FIELD(TB_FLAGS, SEW, 5, 3)
 FIELD(TB_FLAGS, VILL, 8, 1)
+/* Is a Hypervisor instruction load/store allowed? */
+FIELD(TB_FLAGS, HLSX, 9, 1)
 
 /*
  * A simplification for VLMAX
@@ -421,7 +423,17 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState 
*env, target_ulong *pc,
 if (riscv_cpu_fp_enabled(env)) {
 flags |= env->mstatus & MSTATUS_FS;
 }
+
+if (riscv_has_ext(env, RVH)) {
+if (env->priv == PRV_M ||
+(env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) ||
+(env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
+get_field(env->hstatus, HSTATUS_HU))) {
+flags = FIELD_DP32(flags, TB_FLAGS, HLSX, 1);
+}
+}
 #endif
+
 *pflags = flags;
 }
 
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 4b690147fb..ee35311052 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -81,8 +81,6 @@ DEF_HELPER_1(tlb_flush, void, env)
 #ifndef CONFIG_USER_ONLY
 DEF_HELPER_1(hyp_tlb_flush, void, env)
 DEF_HELPER_1(hyp_gvma_tlb_flush, void, env)
-DEF_HELPER_4(hyp_load, tl, env, tl, tl, tl)
-DEF_HELPER_5(hyp_store, void, env, tl, tl, tl, tl)
 DEF_HELPER_4(hyp_x_load, tl, env, tl, tl, tl)
 #endif
 
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index 5759850e69..980d4f39e1 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -227,92 +227,6 @@ void helper_hyp_gvma_tlb_flush(CPURISCVState *env)
 helper_hyp_tlb_flush(env);
 }
 
-target_ulong helper_hyp_load(CPURISCVState *env, target_ulong address,
- target_ulong attrs, target_ulong memop)
-{
-if (env->priv == PRV_M ||
-(env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) ||
-(env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
-get_field(env->hstatus, HSTATUS_HU))) {
-target_ulong pte;
-int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
-
-switch (memop) {
-case MO_SB:
-pte = cpu_ldsb_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_UB:
-pte = cpu_ldub_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TESW:
-pte = cpu_ldsw_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TEUW:
-pte = cpu_lduw_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TESL:
-pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TEUL:
-pte = cpu_ldl_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-case MO_TEQ:
-pte = cpu_ldq_mmuidx_ra(env, address, mmu_idx, GETPC());
-break;
-default:
-g_assert_not_reached();
-}
-
-return pte;
-}
-
-if (riscv_cpu_virt_enabled(env)) {
-riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC());
-} else {
-riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
-}
-return 0;
-}
-
-void helper_hyp_store(CPURISCVState *env, target_ulong address,
-  target_ulong val, target_ulong attrs, target_ulong memop)
-{
-if (env->priv == PRV_M ||
-(env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) ||
-(env->priv == PRV_U && !riscv_cpu_virt_enabled(env) &&
-get_field(env->hstatus, HSTATUS_HU))) {
-int mmu_idx = cpu_mmu_index(env, false) | 
TB_FLAGS_PRIV_HYP_ACCESS_MASK;
-
-switch (memop) {
-case MO_SB:
-case MO_UB:
-cpu_stb_mmuidx_ra(env, address, val, mmu_idx, GETPC());
-break;
-case MO_TESW:
-case MO_TEUW:
-cpu_stw_mmuidx_ra(env, address, val, mmu_idx, GETPC());
-break;
-case MO_TESL:
-case MO_TEUL:
-cpu_stl_mmuidx_ra(env, address, val, mmu_idx, GETPC());
-break;
-case MO_TEQ:
-

[PULL 1/6] target/riscv: Add a virtualised MMU Mode

[Alistair Francis]

Add a new MMU mode that includes the current virt mode.

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
Message-id: 
4b301bc0ea36da962fc1605371b65019ac3073df.1604464950.git.alistair.fran...@wdc.com
---
 target/riscv/cpu-param.h  | 11 ++-
 target/riscv/cpu.h|  4 +++-
 target/riscv/cpu_helper.c |  2 +-
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/target/riscv/cpu-param.h b/target/riscv/cpu-param.h
index 664fc1d371..80eb615f93 100644
--- a/target/riscv/cpu-param.h
+++ b/target/riscv/cpu-param.h
@@ -18,6 +18,15 @@
 # define TARGET_VIRT_ADDR_SPACE_BITS 32 /* sv32 */
 #endif
 #define TARGET_PAGE_BITS 12 /* 4 KiB Pages */
-#define NB_MMU_MODES 4
+/*
+ * The current MMU Modes are:
+ *  - U mode 0b000
+ *  - S mode 0b001
+ *  - M mode 0b011
+ *  - U mode HLV/HLVX/HSV 0b100
+ *  - S mode HLV/HLVX/HSV 0b101
+ *  - M mode HLV/HLVX/HSV 0b111
+ */
+#define NB_MMU_MODES 8
 
 #endif
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 87b68affa8..5d8e54c426 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -363,7 +363,9 @@ void QEMU_NORETURN riscv_raise_exception(CPURISCVState *env,
 target_ulong riscv_cpu_get_fflags(CPURISCVState *env);
 void riscv_cpu_set_fflags(CPURISCVState *env, target_ulong);
 
-#define TB_FLAGS_MMU_MASK   3
+#define TB_FLAGS_MMU_MASK   7
+#define TB_FLAGS_PRIV_MMU_MASK3
+#define TB_FLAGS_PRIV_HYP_ACCESS_MASK   (1 << 2)
 #define TB_FLAGS_MSTATUS_FS MSTATUS_FS
 
 typedef CPURISCVState CPUArchState;
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 3eb3a034db..9dfa7af401 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -323,7 +323,7 @@ static int get_physical_address(CPURISCVState *env, hwaddr 
*physical,
  * (riscv_cpu_do_interrupt) is correct */
 MemTxResult res;
 MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
-int mode = mmu_idx;
+int mode = mmu_idx & TB_FLAGS_PRIV_MMU_MASK;
 bool use_background = false;
 
 /*
-- 
2.29.2

Re: [PATCH 2/5 v4] KVM: SVM: Fill in conforming svm_x86_ops via macro

[kernel test robot]

Hi Krish,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.10-rc3 next-20201109]
[cannot apply to vhost/linux-next kvmarm/next kvm/linux-next kvms390/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Krish-Sadhukhan/KVM-x86-Fill-in-conforming-vmx-svm-_x86_ops-and-vmx-svm-_nested_ops-via-macros/20201110-095653
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
407ab579637ced6dc32cfb2295afb7259cca4b22
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/26275e3a7e11da29dc47a214b3938e7261c61ec7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Krish-Sadhukhan/KVM-x86-Fill-in-conforming-vmx-svm-_x86_ops-and-vmx-svm-_nested_ops-via-macros/20201110-095653
git checkout 26275e3a7e11da29dc47a214b3938e7261c61ec7
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> arch/x86/kvm/svm/svm.c:1651:6: warning: no previous prototype for 
>> 'svm_get_cs_db_l_bits' [-Wmissing-prototypes]
1651 | void svm_get_cs_db_l_bits(struct kvm_vcpu *vcpu, int *db, int *l)
 |  ^~~~
>> arch/x86/kvm/svm/svm.c:3372:6: warning: no previous prototype for 
>> 'svm_tlb_flush_all' [-Wmissing-prototypes]
3372 | void svm_tlb_flush_all(struct kvm_vcpu *vcpu)
 |  ^
>> arch/x86/kvm/svm/svm.c:3377:6: warning: no previous prototype for 
>> 'svm_tlb_flush_current' [-Wmissing-prototypes]
3377 | void svm_tlb_flush_current(struct kvm_vcpu *vcpu)
 |  ^
>> arch/x86/kvm/svm/svm.c:3382:6: warning: no previous prototype for 
>> 'svm_tlb_flush_guest' [-Wmissing-prototypes]
3382 | void svm_tlb_flush_guest(struct kvm_vcpu *vcpu)
 |  ^~~

vim +/svm_get_cs_db_l_bits +1651 arch/x86/kvm/svm/svm.c

  1650  
> 1651  void svm_get_cs_db_l_bits(struct kvm_vcpu *vcpu, int *db, int *l)
  1652  {
  1653  struct kvm_segment cs;
  1654  
  1655  kvm_get_segment(vcpu, , VCPU_SREG_CS);
  1656  *db = cs.db;
  1657  *l = cs.l;
  1658  }
  1659  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] target/arm/translate-neon.c: Handle VTBL UNDEF case before VFP access check

[Richard Henderson]

On 11/9/20 6:53 AM, Peter Maydell wrote:
> Checks for UNDEF cases should go before the "is VFP enabled?" access
> check, except in special cases. Move a stray UNDEF check in the VTBL
> trans function up above the access check.
> 
> Signed-off-by: Peter Maydell 
> ---
> Based-on: 20201105171126.88014-1-richard.hender...@linaro.org
> ("target/arm: Fix neon VTBL/VTBX for len > 1")
> ---
>  target/arm/translate-neon.c.inc | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Richard Henderson 

r~

[Bug 1673957] Re: virtfs: mapped-xattr on mount point

[Thomas Huth]

Thanks for your answer! ... since this is not reproducible anymore, I'm
closing the ticket now.

** Changed in: qemu
   Status: Incomplete => Won't Fix

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

Title:
  virtfs: mapped-xattr on mount point

Status in QEMU:
  Won't Fix

Bug description:
  With
-virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
  in the qemu command line,
shared2 on /mnt/testbis type 9p 
(rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
  in the guest mount points, and
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
  in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep 
/proc/config.gz), running qemu as user "vm-test", trying to "touch a" in 
/mnt/testbis on the VM fails with "Operation not supported". In addition, no 
file or directory actually present in the host's /tmp can be seen in the 
guest's /mnt/testbis.

  When trying to replace "/tmp" with "/tmp/aaa" on the host, with
  /tmp/aaa owned by root:root, still running qemu as vm-test, trying to
  run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading
  directory '.': Cannot allocate memory", while the directory is empty.

  After a "chown vm-test /tmp/aaa", the guest can list the files
  (despite the permissions already allowing it to do so before), but
  still not write new files: "cannot touch 'b': Operation not
  supported".

  Do you have a pointer as to what is happening?

  PS: complete setup is running all this inside a qemu VM that I use for
  testing, I guess it shouldn't matter but saying it just in case

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

[Bug 1671677] Re: vfio-pci passthrough issue after resume from suspend

[Thomas Huth]

Thanks for your answer, and sorry that nobody replied to your original
report - sometimes there is just no expert around, or nobody has a clue
about the right answer... anyway, let's close this ticket now.

** Changed in: qemu
   Status: Incomplete => Won't Fix

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

Title:
  vfio-pci passthrough issue after resume from suspend

Status in QEMU:
  Won't Fix

Bug description:
  
  I'm running into a weird issue with the vfio-pci driver through qemu

  I use it on a laptop and I passthrough an external GPU connected via
  PCI express. In general this works well, however if the laptop has
  *ever* suspended since its last boot, then the windows guest reports
  an error 43 on the card and I get no output on the monitor that it is
  connected to. This is really weird to me since it works fine if I boot
  the latop from power-off, and hotplug the card. It's only if the
  laptop has ever suspended since it's last boot that I see this issue.
  Even if it was suspended before the card was ever hotplugged.

  In other words:
  laptop off -> boot -> hotplug GPU : works great
  laptop off -> boot -> do stuff (GPU *NOT* connected) -> sleep -> resume -> 
hotplug GPU: problem
  laptop off -> boot -> hotplug GPU -> unplug GPU -> hotplug GPU : works great
  laptop off -> boot -> hotplug GPU -> unplug GPU -> sleep -> resume -> hotplug 
GPU: problem

  Weird stuff...

  I'm honestly not sure that vfio-pci/qemu is to blame here since there
  are so many moving parts, but im not really sure where else to report
  this to

  What I have tried is using the sysfs interface to
  remove/rescan/poweroff/etc the PCI devices in questions (graphics card
  and it's HDMI audio) and this also does help.

  QEMU version: 2.6.1

  Please let me know what other information I can provide

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

Re: [PATCH] ppc/translate: Fix unordered f64/f128 comparisons

[Richard Henderson]

On 11/9/20 2:21 AM, LemonBoy wrote:
> According to the PowerISA v3.1 reference, Table 68 "Actions for xscmpudp
> - Part 1: Compare Unordered", whenever one of the two operands is a NaN
> the SO bit is set while the other three bits are cleared.
> 
> Apply the same change to xscmpuqp.
> 
> The respective ordered counterparts are unaffected.
> 
> Signed-off-by: Giuseppe Musacchio 
> ---
>  target/ppc/fpu_helper.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
> index 9b8c8b70b6..b07ff66375 100644
> --- a/target/ppc/fpu_helper.c
> +++ b/target/ppc/fpu_helper.c
> @@ -2479,13 +2479,11 @@ void helper_##op(CPUPPCState *env, uint32_t opcode,   
>\
>  if (float64_is_signaling_nan(xa->VsrD(0), >fp_status) ||\
>  float64_is_signaling_nan(xb->VsrD(0), >fp_status)) {\
>  vxsnan_flag = true;  \
> -cc = CRF_SO; \
>  if (fpscr_ve == 0 && ordered) {  \
>  vxvc_flag = true;\
>  }\
>  } else if (float64_is_quiet_nan(xa->VsrD(0), >fp_status) || \
> float64_is_quiet_nan(xb->VsrD(0), >fp_status)) { \
> -cc = CRF_SO; \
>  if (ordered) {   \
>  vxvc_flag = true;\
>  }\
> @@ -2497,12 +2495,19 @@ void helper_##op(CPUPPCState *env, uint32_t opcode,   
>\
>  float_invalid_op_vxvc(env, 0, GETPC());  \
>  }\
>   \
> -if (float64_lt(xa->VsrD(0), xb->VsrD(0), >fp_status)) { \
> +switch (float64_compare(xa->VsrD(0), xb->VsrD(0), >fp_status)) {\
> +case float_relation_less:\
>  cc |= CRF_LT;\
> -} else if (!float64_le(xa->VsrD(0), xb->VsrD(0), >fp_status)) { \
> -cc |= CRF_GT;\
> -} else { \
> +break;   \
> +case float_relation_equal:   \
>  cc |= CRF_EQ;\
> +break;   \
> +case float_relation_greater: \
> +cc |= CRF_GT;\
> +break;   \
> +case float_relation_unordered:   \
> +cc |= CRF_SO;\
> +break;   \
>  }  

This needs some more cleanup.  There's no point in checking for nans first;
wait until you get to float_relation_unordered.

These macros should be made into straight functions.


r~

[Bug 1719339] Re: serial8250: too much work for irq3

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  serial8250: too much work for irq3

Status in QEMU:
  Incomplete

Bug description:
  It's know issue and sometimes mentioned since 2007. But it seems not
  fixed.

  http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00140.html
  https://bugzilla.redhat.com/show_bug.cgi?id=986761
  
http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-02/msg00696.html

  I don't think fixes like increases PASS_LIMIT
  (/drivers/tty/serial/8250.c) or remove this annoying message
  (https://patchwork.kernel.org/patch/3920801/) is real fix. Some fix
  was proposed by H. Peter Anvin  https://lkml.org/lkml/2008/2/7/485.

  Can reproduce on Debian Strech host (Qemu 1:2.8+dfsg-6+deb9u2), Ubuntu
  16.04.2 LTS (Qemu 1:2.5+dfsg-5ubuntu10.15) also tried to use master
  branch (QEMU emulator version 2.10.50 (v2.10.0-766-ga43415ebfd-dirty))
  if we write a lot of message into console (dmesg or dd if=/dev/zero
  of=/dev/ttyS1).

  /usr/local/bin/qemu-system-x86_64 -name guest=ultra1,debug-threads=on
  -S -object
  secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-ultra1
  /master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-
  core=off -cpu Skylake-
  
Client,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,dtes64=on,monitor=on,ds_cpl=on,vmx=on,smx=on,est=on,tm2=on,xtpr=on,pdcm=on,osxsave=on,tsc_adjust=on,clflushopt=on,pdpe1gb=on
  -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid
  4537ca29-73b2-40c3-9b43-666de182ba5f -display none -no-user-config
  -nodefaults -chardev
  
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-27-ultra1/monitor.sock,server,nowait
  -mon chardev=charmonitor,id=monitor,mode=control -rtc
  base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet
  -no-shutdown -global PIIX4_PM.disable_s3=1 -global
  PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-
  ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -drive
  file=/home/dzagorui/csr/csr_disk.qcow2,format=qcow2,if=none,id=drive-
  ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-
  ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device
  e1000,netdev=hostnet0,id=net0,mac=52:54:00:a9:4c:86,bus=pci.0,addr=0x3
  -chardev
  socket,id=charserial0,host=127.0.0.1,port=4000,telnet,server,nowait
  -device isa-serial,chardev=charserial0,id=serial0 -chardev
  socket,id=charserial1,host=127.0.0.1,port=4001,telnet,server,nowait
  -device isa-serial,chardev=charserial1,id=serial1 -device virtio-
  balloon-pci,id=balloon0,bus=pci.0,addr=0x2 -msg timestamp=on

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

[Bug 1728256] Re: Memory corruption in Windows 10 guest / amd64

[Thomas Huth]

*** This bug is a duplicate of bug 1738972 ***
https://bugs.launchpad.net/bugs/1738972

** This bug has been marked a duplicate of bug 1738972
   [A] KVM Windows BSOD on 4.13.x

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

Title:
  Memory corruption in Windows 10 guest / amd64

Status in QEMU:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 
host. The VM has a physical GPU passed through, as well as the physical USB 
controllers, as well as a dedicated SSD attached via SATA; you can find the 
complete libvirt xml here: https://pastebin.com/U1ZAXBNg
  I built qemu from source using the qemu-minimal-git AUR package; you can find 
the build script here: 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you 
aren't familiar with Arch, this is essentially a bash script where build() and 
package() are run to build the files, and then install them into the $pkgdir to 
later tar them up.)

  Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen
  about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads
  f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0,
  which is running stable for over 50 hours right now.

  During my tests I found that locking the memory pages alleviates the
  problem somewhat, but never completely avoids it. However, with the
  crashes occuring randomly, that could as well be false conclusions; I
  had crashes within minutes after boot with that too.

  I will now start `git bisect`ing; if you have any other suggestions on
  what I could try or possible patches feel free to leave them with me.

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

[Bug 1723731] Re: Qemu turns to black screen while starting to copy installation files of Windows 7

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  Qemu turns to black screen while starting to copy installation files
  of Windows 7

Status in QEMU:
  Incomplete

Bug description:
  Distribution: Arch Linux, Kernel: linux-4.13.5, Qemu: 2.10.1, OVMF: git 
(built 06.10.17).
  Steps to reproduce: create Qemu VM with such config:

  QEMU_VM_NAME=$(basename $(dirname "$0")) #Qemu virtual machine name (taken 
from working directory)
  QEMU_WORKING_DIR="$(dirname "$0")" #Qemu current working directory
  DIF=12 #set 2-digit number here
  QEMU_MONITOR_PORT=370${DIF} #Qemu monitor port
  QEMU_SERIAL_PORT=371${DIF} #Qemu serial port
  QEMU_PARALLEL_PORT=372${DIF} #Qemu parallel port

  qemu-system-x86_64 -daemonize -display gtk -boot menu=on -monitor 
telnet:127.0.0.1:${QEMU_MONITOR_PORT},server,nowait -serial 
telnet:127.0.0.1:${QEMU_SERIAL_PORT},server,nowait -uuid 
fafafafa-1234-bcbc-5678-ff${DIF} -name 
${QEMU_VM_NAME},process=QEMU-${QEMU_VM_NAME} -parallel none -net none 
-nodefconfig -nodefaults -no-user-config -rtc 
base=localtime,clock=vm,driftfix=slew -realtime mlock=off -machine 
type=q35,accel=kvm,usb=off,dump-guest-core=off -smp 
2,sockets=1,cores=2,threads=1 -object iothread,id=iothread1 -object 
iothread,id=iothread2 -cpu Penryn,kvm=off,check,vendor=GenuineIntel,+vmx -m 2G 
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,addr=0x1b.0x0
 -global qxl-vga.revision=4 -device ich9-intel-hda,addr=0x11.0x0,id=sound0 
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device 
ich9-usb-ehci1,id=ehci1,addr=0x12.0x7 -device 
ich9-usb-uhci1,id=uhci1,masterbus=ehci1.0,firstport=0,multifunction=on,addr=0x12.0x0
 -device ich9-usb-uhci2,id=uhci2,masterbus=ehci1.0,firstport=2,addr=0x12.0x1 
-device ich9-usb-uhci3,id=uhci3,masterbus=ehci1.0,firstport=4,addr=0x12.0x2 
-device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -drive 
file="${QEMU_WORKING_DIR}"/${QEMU_VM_NAME}.qcow2,if=none,media=disk,id=drive-sata0-0-0,format=qcow2
 -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -drive 
if=none,media=cdrom,readonly=on,id=drive-sata0-0-1 -device 
usb-tablet,id=tbl0,bus=ehci1.0,port=2,usb_version=2,serial=1123,display=tbl0
  -device 
usb-kbd,id=kbd0,bus=ehci1.0,port=1,usb_version=1,serial=1122,display=kbd0 
-drive if=pflash,format=raw,unit=1,file=${QEMU_WORKING_DIR}/ovmf_vars_x64.bin 
-drive 
if=pflash,format=raw,unit=0,readonly,file=${QEMU_WORKING_DIR}/ovmf_code_x64.bin

  After that connect to Qemu console, insert Windows 7 installation
  media and start installation. You can successfully choose language,
  keyboard layout and partition your harddrive but after 2-3 seconds
  after beginning of copying installation files the graphical console
  screen turns to black and 1 CPU core on the host raises to 100%
  permanently and nothing happens. But if you installed Windows 7 before
  - there is no problems with VM. Tested on GTK, SDL types of screen.

  Qemu was installed from official repo and also I tried with built by
  myself version. Other OSes: Windows 8, 8.1, 10, Arch Linux, Debian,
  FreeBSD installed successfully.

  It happens only in OVMF-mode. I've just tested BIOS mode with no
  problems.

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

[Bug 1728325] Re: POWER8: Wrong behaviour with float-to-int punning

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  POWER8: Wrong behaviour with float-to-int punning

Status in QEMU:
  Incomplete

Bug description:
  Building a reduced test program with 'gcc -O2 -fno-inline
  -mcpu=power8' produces wrong results at runtime. I don't think gcc is
  at fault here.

  ---
  #include 

  int getWord(const float x)
  {
return *(int*)
  }

  void main()
  {
  int foo = getWord(+123.456f);
  int bar = getWord(-123.456f);

  printf("%d\n", foo);
  printf("%d\n", bar);
  return;
  }
  ---

  This prints:
  ---
  0
  0
  ---

  Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the 
expected result:
  ---
  1123477881
  -1024005767
  ---

  
  The different between the two programs is:

  --- power7.s
  +++ power8.s
  @@ -6,9 +6,9 @@
.globl getWord
.type   getWord, @function
   getWord:
  - stfs 1,-16(1)
  - ori 2,2,0
  - lwa 3,-16(1)
  + xscvdpspn 0,1
  + mfvsrwz 3,0
  + extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
  .size   getWord,.-getWord

  
  Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly.

  https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40
  https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1

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

[Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  QEMU sends excess VNC data to websockify even when network is poor

Status in QEMU:
  Incomplete

Bug description:
  Description of problem
  -
  In my latest topic, I reported a bug relate to QEMU's websocket:
  https://bugs.launchpad.net/qemu/+bug/1718964

  It has been fixed but someone mentioned that he met the same problem when 
using QEMU with a standalone websocket proxy.
  That makes me confused because in that scenario QEMU will get a "RAW" VNC 
connection.
  So I did a test and found that there indeed existed some problems. The 
problem is:

  When the client's network is poor (on a low speed WAN), QEMU still
  sends a lot of data to the websocket proxy, then the client get stuck.
  It seems that only QEMU has this problem, other VNC servers works
  fine.

  Environment
  -
  All of the following versions have been tested:

  QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date)
  Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611
  Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master
  VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master
  Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8

  Steps to reproduce:
  -
  100% reproducible.

  1. Launch a QEMU instance (No need websocket option):
  qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0

  2. Launch websockify on a separate host and connect to QEMU's VNC port

  3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to
  websockify

  4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame
  buffer update)

  5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S
  (To simulate a low speed WAN)

  6. Then client's output gets stuck(less than 1 fps), the cursor is
  almost impossible to move

  7. Monitor network traffic on the proxy server

  Current result:
  -
  Monitor Downlink/Uplink network traffic on the proxy server
  (Refer to the attachments for more details).

  1. Used with QEMU
  - D: 5.9 MB/s U: 5.7 MB/s (Client on LAN)
  - D: 4.3 MB/s U: 334 KB/s (Client on WAN)

  2. Used with other VNC servers
  - D: 5.9 MB/s U: 5.6 MB/s (Client on LAN)
  - D: 369 KB/s U: 328 KB/s (Client on WAN)

  It is found that when the client's network is poor, all the VNC
  servers (tigervnc/x11vnc/tightvnc) will reduce the VNC data send to
  websocket proxy (uplink and downlink symmetry), but QEMU never drop
  any frames and still sends a lot of data to websockify, the client has
  no capacity to accept so much data, more and more data are accumulated
  in the websockify, then it crashes.

  Expected results:
  -
  When the client's network is poor (WAN), QEMU will reduce the VNC data send 
to websocket proxy.

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

[Bug 1728635] Re: qemu-io crashes with SIGSEGV when did -c aio_write 9233408 28160 on a image_fuzzer image

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  qemu-io crashes with SIGSEGV when did  -c aio_write 9233408 28160 on a
  image_fuzzer image

Status in QEMU:
  Incomplete

Bug description:
  git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4
  This is on ppc64le architecture.

  Re-production steps:

  1. Copy the attached file named test.img to a directory
  2. And customize the following command to point to the above directory and 
run the same.
  # cp test.img copy.img
  # qemu/qemu-io /copy.img -c "aio_write 9233408 28160"

  from gdb:
  Program terminated with signal 11, Segmentation fault.
  #0  0x3fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6
  Missing separate debuginfos, use: debuginfo-install 
cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le 
glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le 
keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le 
libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le 
libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le 
libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le 
libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le 
libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le 
nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le 
nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le 
nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le 
openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le 
pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le
  (gdb) bt
  #0  0x3fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6
  #1  0x10056738 in qcow2_refcount_area (bs=0x25f56f60, 
start_offset=137438953472, additional_clusters=0, exact_size=false, 
new_refblock_index=0,
  new_refblock_offset=524288) at block/qcow2-refcount.c:573
  #2  0x10056374 in alloc_refcount_block (bs=0x25f56f60, 
cluster_index=0, refcount_block=0x3fff9dadf838) at block/qcow2-refcount.c:479
  #3  0x10057520 in update_refcount (bs=0x25f56f60, offset=0, 
length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER)
  at block/qcow2-refcount.c:834
  #4  0x10057c24 in qcow2_alloc_clusters (bs=0x25f56f60, size=524288) 
at block/qcow2-refcount.c:996
  #5  0x10063684 in do_alloc_cluster_offset (bs=0x25f56f60, 
guest_offset=9233408, host_offset=0x3fff9dadf9e0, nb_clusters=0x3fff9dadf9d8)
  at block/qcow2-cluster.c:1213
  #6  0x10063afc in handle_alloc (bs=0x25f56f60, guest_offset=9233408, 
host_offset=0x3fff9dadfab0, bytes=0x3fff9dadfab8, m=0x3fff9dadfb60)
  at block/qcow2-cluster.c:1324
  #7  0x10064178 in qcow2_alloc_cluster_offset (bs=0x25f56f60, 
offset=9233408, bytes=0x3fff9dadfb4c, host_offset=0x3fff9dadfb58, 
m=0x3fff9dadfb60)
  at block/qcow2-cluster.c:1511
  #8  0x1004d3f4 in qcow2_co_pwritev (bs=0x25f56f60, offset=9233408, 
bytes=28160, qiov=0x25f6fa08, flags=0) at block/qcow2.c:1919
  #9  0x100a9648 in bdrv_driver_pwritev (bs=0x25f56f60, offset=9233408, 
bytes=28160, qiov=0x25f6fa08, flags=16) at block/io.c:898
  #10 0x100ab630 in bdrv_aligned_pwritev (child=0x25f627f0, 
req=0x3fff9dadfdd8, offset=9233408, bytes=28160, align=1, qiov=0x25f6fa08, 
flags=16)
  at block/io.c:1440
  #11 0x100ac4ac in bdrv_co_pwritev (child=0x25f627f0, offset=9233408, 
bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/io.c:1691
  #12 0x1008da0c in blk_co_pwritev (blk=0x25f49410, offset=9233408, 
bytes=28160, qiov=0x25f6fa08, flags=BDRV_REQ_FUA) at block/block-backend.c:1085
  #13 0x1008e718 in blk_aio_write_entry (opaque=0x25f6fa70) at 
block/block-backend.c:1276
  #14 0x101aa444 in coroutine_trampoline (i0=636902032, i1=0) at 
util/coroutine-ucontext.c:79
  #15 0x3fffa0022b9c in makecontext () from /lib64/libc.so.6
  #16 0x in ?? ()
  (gdb) bt full
  #0  0x3fffa0077644 in __memcpy_power7 () from /lib64/libc.so.6
  No symbol table info available.
  #1  0x10056738 in qcow2_refcount_area (bs=0x25f56f60, 
start_offset=137438953472, additional_clusters=0, exact_size=false, 
new_refblock_index=0,
  new_refblock_offset=524288) at block/qcow2-refcount.c:573
  s = 0x25f63210
  

[Bug 1731277] Re: Provide target specific qemu man pages

[Thomas Huth]

** Changed in: qemu
   Importance: Undecided => Wishlist

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

Title:
  Provide target specific qemu man pages

Status in QEMU:
  New

Bug description:
  Right now, all qemu target binaries (qemu-system-...) share the same
  man page.

  The current man page is primarily focused on x86, and therefore the
  information given is entirely wrong for e.g. arm, powerpc or s390x.

  NAME
 qemu-doc - QEMU Emulator User Documentation

  SYNOPSIS
 qemu-system-i386 [options] [disk_image]

  DESCRIPTION
 The QEMU PC System emulator simulates the following peripherals:

 -   i440FX host PCI bridge and PIIX3 PCI to ISA bridge

 -   Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA 
extensions (hardware level, including all non
 standard modes).

 -   PS/2 mouse and keyboard

 -   2 PCI IDE interfaces with hard disk and CD-ROM support

 -   Floppy disk

  ...

  We should have target specific man pages, with the common
  options/settings factored out, so they are included in all target
  specific man pages.

  "man qemu-system-s390x" should give s390x specific (+common)
  information and "man qemu-system-x86_64" should contain x86 specific
  (+common) information.

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

[Bug 1731347] Re: VFIO Passthrough of SAS2008-based HBA card fails on E3-1225v3 due to failed DMA mapping (-14)

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.


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

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

Title:
  VFIO Passthrough of SAS2008-based HBA card fails on E3-1225v3 due to
  failed DMA mapping (-14)

Status in QEMU:
  Incomplete

Bug description:
  There is a bug preventing multiple people with my combination of
  hardware from using PCI passthrough. I am not actually sure whether
  the bug is in kernel/kvm, vfio or qemu, however, as qemu is the
  highest-level of these, I am reporting the bug here as you will likely
  know better where the origin of the bug may be found.

  When attempting to pass through this device to a KVM using VFIO, this
  results in error -14 (Bad Address):

  # qemu-system-x86_64 -enable-kvm -m 10G -net none -monitor stdio -serial
  # none -parallel none -vnc :1 -device vfio-pci,host=1:00.0 -S
  QEMU 2.9.1 monitor - type 'help' for more information
  (qemu) c
  (qemu) qemu-system-x86_64: VFIO_MAP_DMA: -14
  qemu-system-x86_64: vfio_dma_map(0x7f548f0a1fc0, 0xfebd, 0x2000, 
0x7f54a909d000) = -14 (Bad address)
  qemu: hardware error: vfio: DMA mapping failed, unable to continue

  See also:
  https://bugzilla.proxmox.com/show_bug.cgi?id=1556
  https://www.redhat.com/archives/vfio-users/2016-May/msg00088.html

  This has occurred on Proxmox (Proxmox and Debian packages, Ubuntu kernel), 
Ubuntu,
  and pure Debian packages and kernel on Proxmox. However, this error
  reportedly does NOT occur for:

  - different distributions(!) (Fedora 24, 25)
  - different HBA cards (SAS2308, SAS3008)
  - different CPU (E3-1220v5)

  I would be thankful for any input and I'll be happy to provide any
  further info necessary. This is my first time delving this deep into
  anything close to the kernel.

  Thanks and best regards,
  Johannes Falke

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

Re: [PATCH-for-5.2 v3] configure: Check vhost-user is available for vhost-user-blk-server

[Thomas Huth]

On 09/11/2020 20.15, Philippe Mathieu-Daudé wrote:
> On 11/9/20 7:52 PM, Philippe Mathieu-Daudé wrote:
>> On 11/9/20 7:44 PM, Thomas Huth wrote:
>>> On 09/11/2020 19.41, Philippe Mathieu-Daudé wrote:
 On Mon, Nov 9, 2020 at 6:22 PM Thomas Huth  wrote:
> On 09/11/2020 15.07, Philippe Mathieu-Daudé wrote:
>> Check vhost-user is available when building vhost-user-blk-server.
>>
>> This fixes:
>>
>>  $ ../configure \
>>   --disable-vhost-user --enable-vhost-user-blk-server && \
>>make qemu-nbd
>>  ...
>>  [505/505] Linking target qemu-nbd
>>  FAILED: qemu-nbd
>>  cc  -o qemu-nbd qemu-nbd.p/qemu-nbd.c.o -Wl,--as-needed 
>> -Wl,--no-undefined -pie -Wl,--whole-archive libblockdev.fa libblock.fa 
>> libcrypto.fa libauthz.fa libqom.fa libio.fa -Wl,--no-whole-archive 
>> -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -fstack-protector-strong 
>> -Wl,--start-group libqemuutil.a libblockdev.fa libblock.fa libcrypto.fa 
>> libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 
>> -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lgnutls -lutil 
>> -lm -lgthread-2.0 -lglib-2.0 -lbz2 -lgthread-2.0 -lglib-2.0 -lssh -lrbd 
>> -lrados -lcurl -lxml2 -lzstd -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr 
>> -luuid -laio /usr/lib64/libz.so -L/usr/lib64/iscsi -liscsi -lnettle 
>> -lgnutls -lpam -Wl,--end-group
>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): in 
>> function `vu_blk_process_vq':
>>  block/export/vhost-user-blk-server.c:203: undefined reference to 
>> `vu_get_queue'
>>  /usr/bin/ld: block/export/vhost-user-blk-server.c:208: undefined 
>> reference to `vu_queue_pop'
>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): in 
>> function `vu_blk_queue_set_started':
>>  block/export/vhost-user-blk-server.c:228: undefined reference to 
>> `vu_get_queue'
>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): in 
>> function `vu_blk_req_complete':
>>  block/export/vhost-user-blk-server.c:55: undefined reference to 
>> `vu_queue_push'
>>  /usr/bin/ld: block/export/vhost-user-blk-server.c:56: undefined 
>> reference to `vu_queue_notify'
>>  /usr/bin/ld: libblockdev.fa(block_export_vhost-user-blk-server.c.o): in 
>> function `vu_blk_queue_set_started':
>>  block/export/vhost-user-blk-server.c:229: undefined reference to 
>> `vu_set_queue_handler'
>>  /usr/bin/ld: libqemuutil.a(util_vhost-user-server.c.o): in function 
>> `vu_client_trip':
>>  util/vhost-user-server.c:176: undefined reference to `vu_dispatch'
>>  /usr/bin/ld: util/vhost-user-server.c:180: undefined reference to 
>> `vu_deinit'
>>  /usr/bin/ld: libqemuutil.a(util_vhost-user-server.c.o): in function 
>> `vu_accept':
>>  util/vhost-user-server.c:291: undefined reference to `vu_init'
>>  collect2: error: ld returned 1 exit status
>>  ninja: build stopped: subcommand failed.
>>  make: *** [Makefile:171: run-ninja] Error 1
>>
>> Now we get:
>>
>>  $ ../configure \
>>   --disable-vhost-user --enable-vhost-user-blk-server && \
>>  ERROR: --enable-vhost-user-blk-server requires --enable-vhost-user
>>
>> Fixes: bc15e44cb21 ("configure: introduce 
>> --enable-vhost-user-blk-server")
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> Since v1:
>> - Addressed Thomas review comments
>> https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02188.html
>> ---
>>  configure | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 805f7791503..3124be82da1 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2375,6 +2375,10 @@ test "$vhost_user_fs" = "" && 
>> vhost_user_fs=$vhost_user
>>  if test "$vhost_user_fs" = "yes" && test "$vhost_user" = "no"; then
>>error_exit "--enable-vhost-user-fs requires --enable-vhost-user"
>>  fi
>> +test "$vhost_user_blk_server" = "" && vhost_user_blk_server=$vhost_user
>> +if test "$vhost_user_blk_server" = "yes" && test "$vhost_user" = "no"; 
>> then
>> +  error_exit "--enable-vhost-user-blk-server requires 
>> --enable-vhost-user"
>> +fi
>
> A little bit later in this file, we've got :
>
> # libvhost-user is Linux-only
> test "$vhost_user_blk_server" = "" && vhost_user_blk_server=$linux
> if test "$vhost_user_blk_server" = "yes" && test "$linux" = "no"; then
>   error_exit "--enable-vhost-user-blk-server is only available on Linux"
> fi
>
> I think it would be better to add the new code there instead.
> Also maybe better do something like:
>
> test "$vhost_user_blk_server" = "" && test "$vhost_user" = "yes" \
>  &&  vhost_user_blk_server=$linux
>
> instead?

 I understood this option is similar to 

Re: [PATCH v3 0/3] tcg-cpus: split into 3 tcg variants

[Richard Henderson]

On 11/9/20 8:02 AM, Claudio Fontana wrote:
> On 10/19/20 5:00 PM, Richard Henderson wrote:
>> On 10/15/20 7:32 AM, Claudio Fontana wrote:
>>> Claudio Fontana (3):
>>>   accel/tcg: split CpusAccel into three TCG variants
>>>   accel/tcg: split tcg_start_vcpu_thread
>>>   accel/tcg: rename tcg-cpus functions to match module name
>>
>> Reviewed-by: Richard Henderson 
>>
>> r~
>>
>>
> 
> Hi all, just pinging about the status of this series, is it already in 
> someone's queue?
> 
> Otherwise it's fine of course to delay it if there are concerns about 
> tightening up the upcoming release.

Oof da.  It has been a month.  Since Paolo picked up the first part, I assumed
he'd get the second too.

Since it's not critical, I'll queue it for 6.0.
But at least it'll be queued somewhere...


r~

Re: [PATCH] pvpanic: Advertise the PVPANIC_CRASHLOADED event support

[Alejandro Jimenez]

(CC Maciej)

Hi Paolo,

Thank you for fixing the patch. One comment below..

On 11/9/2020 9:33 AM, Paolo Bonzini wrote:

Advertise both types of events as supported when the guest OS
queries the pvpanic device.  Currently only PVPANIC_PANICKED is
exposed; PVPANIC_CRASHLOADED must also be advertised, but only on
new machine types.

Fixes: 7dc58deea79a ("pvpanic: implement crashloaded event handling")
Reported-by: Alejandro Jimenez 
Signed-off-by: Paolo Bonzini 
---
  hw/core/machine.c | 1 +
  hw/misc/pvpanic.c | 5 -
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 98b87f76cb..d0408049b5 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -35,6 +35,7 @@ GlobalProperty hw_compat_5_1[] = {
  { "virtio-blk-device", "num-queues", "1"},
  { "virtio-scsi-device", "num_queues", "1"},
  { "nvme", "use-intel-id", "on"},
+{ "pvpanic", "events", "1"}, /* PVPANIC_PANICKED */
  };
  const size_t hw_compat_5_1_len = G_N_ELEMENTS(hw_compat_5_1);
  
diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c

index 598d5471a4..35d6797831 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -61,12 +61,14 @@ struct PVPanicState {
  
  MemoryRegion io;

  uint16_t ioport;
+uint8_t events;
  };
  
  /* return supported events on read */

  static uint64_t pvpanic_ioport_read(void *opaque, hwaddr addr, unsigned size)
  {
-return PVPANIC_PANICKED;
+PVPanicState *pvp = opaque;
+return pvp->events;
  }
  
  static void pvpanic_ioport_write(void *opaque, hwaddr addr, uint64_t val,

@@ -112,6 +114,7 @@ static void pvpanic_isa_realizefn(DeviceState *dev, Error 
**errp)
  
  static Property pvpanic_isa_properties[] = {

  DEFINE_PROP_UINT16(PVPANIC_IOPORT_PROP, PVPanicState, ioport, 0x505),
+DEFINE_PROP_UINT8("events", PVPanicState, events, PVPANIC_PANICKED | 
PVPANIC_CRASHLOADED),
  DEFINE_PROP_END_OF_LIST(),
  };
One side effect of defining the "events" property (as Maciej pointed out 
to me), is that we are able to overwrite it with an alternative value in 
the cmdline. e.g.


-device pvpanic,events=

This can be used to force QEMU to report a set of events different than 
what it actually supports to a guest OS reading from the pvpanic device. 
I assume you are not concerned about this scenario, since it would have 
to be deliberately triggered, and even then it would not cause any 
serious issues, correct?


Assuming the above is not a problem:
Reviewed-by: Alejandro Jimenez 

Re: [RFC PATCH 0/6] eBPF RSS support for virtio-net

[Jason Wang]

On 2020/11/9 下午9:33, Yuri Benditovich wrote:



On Mon, Nov 9, 2020 at 4:14 AM Jason Wang > wrote:



On 2020/11/5 下午11:13, Yuri Benditovich wrote:
> First of all, thank you for all your feedbacks
>
> Please help me to summarize and let us understand better what we
do in v2:
> Major questions are:
> 1. Building eBPF from source during qemu build vs. regenerating
it on
> demand and keeping in the repository
> Solution 1a (~ as in v1): keep instructions or ELF in H file,
generate
> it out of qemu build. In general we'll need to have BE and LE
binaries.
> Solution 1b: build ELF or instructions during QEMU build if llvm +
> clang exist. Then we will have only one (BE or LE, depending on
> current QEMU build)
> We agree with any solution - I believe you know the requirements
better.


I think we can go with 1a. (See Danial's comment)


>
> 2. Use libbpf or not
> In general we do not see any advantage of using libbpf. It works
with
> object files (does ELF parsing at time of loading), but it does
not do
> any magic.
> Solution 2a. Switch to libbpf, generate object files (LE and BE)
from
> source, keep them inside QEMU (~8k each) or aside


Can we simply use dynamic linking here?


Can you please explain, where exactly you suggest to use dynamic linking?



Yes. If I understand your 2a properly, you meant static linking of 
libbpf. So what I want to ask is the possibility of dynamic linking of 
libbpf here.





> Solution 2b. (as in v1) Use python script to parse object ->
> instructions (~2k each)
> We'd prefer not to use libbpf at the moment.
> If due to some unknown reason we'll find it useful in future, we
can
> switch to it, this does not create any incompatibility. Then
this will
> create a dependency on libbpf.so


I think we need to care about compatibility. E.g we need to enable
BTF
so I don't know how hard if we add BTF support in the current
design. It
would be probably OK it's not a lot of effort.


As far as we understand BTF helps in BPF debugging and libbpf supports 
it as is.

Without libbpf we in v1 load the BPF instructions only.
If you think the BTF is mandatory (BTW, why?) I think it is better to 
switch to libbpf and keep the entire ELF in the qemu data.



It is used to make sure the BPF can do compile once run everywhere.

This is explained in detail in here: 
https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html.


Thanks





>
> 3. Keep instructions or ELF inside QEMU or as separate external file
> Solution 3a (~as in v1): Built-in array of instructions or ELF.
If we
> generate them out of QEMU build - keep 2 arrays or instructions
or ELF
> (BE and LE),
> Solution 3b: Install them as separate files (/usr/share/qemu).
> We'd prefer 3a:
>  Then there is a guarantee that the eBPF is built with exactly the
> same config structures as QEMU (qemu creates a mapping of its
> structures, eBPF uses them).
>  No need to take care on scenarios like 'file not found', 'file
is not
> suitable' etc


Yes, let's go 3a for upstream.


>
> 4. Is there some real request to have the eBPF for big-endian?
> If no, we can enable eBPF only for LE builds


We can go with LE first.

Thanks


>
> Jason, Daniel, Michael
> Can you please let us know what you think and why?
>
> On Thu, Nov 5, 2020 at 3:19 PM Daniel P. Berrangé
mailto:berra...@redhat.com>
> >> wrote:
>
>     On Thu, Nov 05, 2020 at 10:01:09AM +, Daniel P. Berrangé
wrote:
>     > On Thu, Nov 05, 2020 at 11:46:18AM +0800, Jason Wang wrote:
>     > >
>     > > On 2020/11/4 下午5:31, Daniel P. Berrangé wrote:
>     > > > On Wed, Nov 04, 2020 at 10:07:52AM +0800, Jason Wang
wrote:
>     > > > > On 2020/11/3 下午6:32, Yuri Benditovich wrote:
>     > > > > >
>     > > > > > On Tue, Nov 3, 2020 at 11:02 AM Jason Wang
>     mailto:jasow...@redhat.com>
>
>     > > > > > 
>          > > > > >
>     > > > > >
>     > > > > >      On 2020/11/3 上午2:51, Andrew Melnychenko wrote:
>     > > > > >      > Basic idea is to use eBPF to calculate and
steer
>     packets in TAP.
>     > > > > >      > RSS(Receive Side Scaling) is used to distribute
>     network packets
>     > > > > >      to guest virtqueues
>     > > > > >      > by calculating packet hash.
>     > > > > >      > eBPF RSS allows us to use RSS with vhost TAP.
>     > > > > >      >
>     > > > > >      > This set 

Re: [RFC v5 00/68] support vector extension v1.0

[Frank Chang]

ping 2nd~

On Tue, Oct 20, 2020 at 3:42 PM Frank Chang  wrote:

> On Wed, Sep 30, 2020 at 3:04 AM  wrote:
>
>> From: Frank Chang 
>>
>> This patchset implements the vector extension v1.0 for RISC-V on QEMU.
>>
>> This patchset is sent as RFC because RVV v1.0 is still in draft state.
>> v2 patchset was sent for RVV v0.9 and bumped to RVV v1.0 since v3
>> patchset.
>>
>> The port is available here:
>> https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v5
>>
>> You can change the cpu argument: vext_spec to v1.0 (i.e. vext_spec=v1.0)
>> to run with RVV v1.0 instructions.
>>
>> Note: This patchset depends on two other patchsets listed in Based-on
>>   section below so it might not able to be built unless those two
>>   patchsets are applied.
>>
>> Changelog:
>>
>> v5
>>   * refactor RVV v1.0 check functions.
>> (Thanks to Richard Henderson's bitwise tricks.)
>>   * relax RV_VLEN_MAX to 1024-bits.
>>   * implement vstart CSR's behaviors.
>>   * trigger illegal instruction exception if frm is not valid for
>> vector floating-point instructions.
>>   * rebase on riscv-to-apply.next.
>>
>> v4
>>   * remove explicit float flmul variable in DisasContext.
>>   * replace floating-point calculations with shift operations to
>> improve performance.
>>   * relax RV_VLEN_MAX to 512-bits.
>>
>> v3
>>   * apply nan-box helpers from Richard Henderson.
>>   * remove fp16 api changes as they are sent independently in another
>> pathcset by Chih-Min Chao.
>>   * remove all tail elements clear functions as tail elements can
>> retain unchanged for either VTA set to undisturbed or agnostic.
>>   * add fp16 nan-box check generator function.
>>   * add floating-point rounding mode enum.
>>   * replace flmul arithmetic with shifts to avoid floating-point
>> conversions.
>>   * add Zvqmac extension.
>>   * replace gdbstub vector register xml files with dynamic generator.
>>   * bumped to RVV v1.0.
>>   * RVV v1.0 related changes:
>> * add vlre.v and vsr.v vector whole register
>>   load/store instructions
>> * add vrgatherei16 instruction.
>> * rearranged bits in vtype to make vlmul bits into a contiguous
>>   field.
>>
>> v2
>>   * drop v0.7.1 support.
>>   * replace invisible return check macros with functions.
>>   * move mark_vs_dirty() to translators.
>>   * add SSTATUS_VS flag for s-mode.
>>   * nan-box scalar fp register for floating-point operations.
>>   * add gdbstub files for vector registers to allow system-mode
>> debugging with GDB.
>>
>> Based-on: <20200909001647.532249-1-richard.hender...@linaro.org/>
>> Based-on: <1596102747-20226-1-git-send-email-chihmin.c...@sifive.com/>
>>
>> Frank Chang (62):
>>   target/riscv: drop vector 0.7.1 and add 1.0 support
>>   target/riscv: Use FIELD_EX32() to extract wd field
>>   target/riscv: rvv-1.0: introduce writable misa.v field
>>   target/riscv: rvv-1.0: add translation-time vector context status
>>   target/riscv: rvv-1.0: remove rvv related codes from fcsr registers
>>   target/riscv: rvv-1.0: check MSTATUS_VS when accessing vector csr
>> registers
>>   target/riscv: rvv-1.0: remove MLEN calculations
>>   target/riscv: rvv-1.0: add fractional LMUL
>>   target/riscv: rvv-1.0: add VMA and VTA
>>   target/riscv: rvv-1.0: update check functions
>>   target/riscv: introduce more imm value modes in translator functions
>>   target/riscv: rvv:1.0: add translation-time nan-box helper function
>>   target/riscv: rvv-1.0: configure instructions
>>   target/riscv: rvv-1.0: stride load and store instructions
>>   target/riscv: rvv-1.0: index load and store instructions
>>   target/riscv: rvv-1.0: fix address index overflow bug of indexed
>> load/store insns
>>   target/riscv: rvv-1.0: fault-only-first unit stride load
>>   target/riscv: rvv-1.0: amo operations
>>   target/riscv: rvv-1.0: load/store whole register instructions
>>   target/riscv: rvv-1.0: update vext_max_elems() for load/store insns
>>   target/riscv: rvv-1.0: take fractional LMUL into vector max elements
>> calculation
>>   target/riscv: rvv-1.0: floating-point square-root instruction
>>   target/riscv: rvv-1.0: floating-point classify instructions
>>   target/riscv: rvv-1.0: mask population count instruction
>>   target/riscv: rvv-1.0: find-first-set mask bit instruction
>>   target/riscv: rvv-1.0: set-X-first mask bit instructions
>>   target/riscv: rvv-1.0: iota instruction
>>   target/riscv: rvv-1.0: element index instruction
>>   target/riscv: rvv-1.0: allow load element with sign-extended
>>   target/riscv: rvv-1.0: register gather instructions
>>   target/riscv: rvv-1.0: integer scalar move instructions
>>   target/riscv: rvv-1.0: floating-point move instruction
>>   target/riscv: rvv-1.0: floating-point scalar move instructions
>>   target/riscv: rvv-1.0: whole register move instructions
>>   target/riscv: rvv-1.0: integer extension instructions
>>   target/riscv: rvv-1.0: single-width averaging add and subtract
>> instructions
>>   

Re: [RFC PATCH 1/6] migration: Add multi-thread compress method

[Zeyu Jin]

On 2020/11/9 23:57, Eric Blake wrote:
> On 11/9/20 3:08 AM, Zeyu Jin wrote:
>> A multi-thread compress method parameter is added to hold the method we
>> are going to use. By default the 'zlib' method is used to maintain the
>> compatibility as before.
>>
>> Signed-off-by: Zeyu Jin 
>> Signed-off-by: Ying Fang 
>> ---
> 
> Focusing on just the UI:
> 
>> +++ b/qapi/migration.json
>> @@ -525,6 +525,19 @@
>>'data': [ 'none', 'zlib',
>>  { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
>>  
>> +##
>> +# @CompressMethod:
>> +#
>> +# An enumeration of multi-thread compression methods.
>> +#
>> +# @zlib: use zlib compression method.
>> +#
>> +# Since: 5.0
> 
> This will have to be Since: 6.0, as it has missed feature freeze for 5.2.
> 

Thank you for noticing. I will fix that.

>> +#
>> +##
>> +{ 'enum': 'CompressMethod',
>> +  'data': [ 'zlib' ] }
>> +
>>  ##
>>  # @BitmapMigrationBitmapAlias:
>>  #
>> @@ -599,6 +612,9 @@
>>  #  compression, so set the decompress-threads to the 
>> number about 1/4
>>  #  of compress-threads is adequate.
>>  #
>> +# @compress-method: Set compression method to use in multi-thread 
>> compression.
>> +#   Defaults to none. (Since 5.0)
> 
> Looks like it will be a recurring issue in the series, so I'll quit
> pointing it out.
> 
> CompressMethod above does not have a 'none' option, so how can it
> default to none?  Did you forget an enum option?
> 

Actually this is a comment mistake. The default option is expected to
be 'zlib'. I will fix the comment.

Re: [PATCH for-5.2] vhost-user: fix VHOST_USER_ADD/REM_MEM_REG truncation

[Raphael Norwitz]

On Mon, Nov 9, 2020 at 12:59 PM Stefan Hajnoczi  wrote:
>
> QEMU currently truncates the mmap_offset field when sending
> VHOST_USER_ADD_MEM_REG and VHOST_USER_REM_MEM_REG messages. The struct
> layout looks like this:
>
>   typedef struct VhostUserMemoryRegion {
>   uint64_t guest_phys_addr;
>   uint64_t memory_size;
>   uint64_t userspace_addr;
>   uint64_t mmap_offset;
>   } VhostUserMemoryRegion;
>
>   typedef struct VhostUserMemRegMsg {
>   uint32_t padding;
>   /* WARNING: there is a 32-bit hole here! */
>   VhostUserMemoryRegion region;
>   } VhostUserMemRegMsg;
>
> The payload size is calculated as follows when sending the message in
> hw/virtio/vhost-user.c:
>
>   msg->hdr.size = sizeof(msg->payload.mem_reg.padding) +
>   sizeof(VhostUserMemoryRegion);
>
> This calculation produces an incorrect result of only 36 bytes.
> sizeof(VhostUserMemRegMsg) is actually 40 bytes.
>
> The consequence of this is that the final field, mmap_offset, is
> truncated. This breaks x86_64 TCG guests on s390 hosts. Other guest/host
> combinations may get lucky if either of the following holds:
> 1. The guest memory layout does not need mmap_offset != 0.
> 2. The host is little-endian and mmap_offset <= 0x so the
>truncation has no effect.
>
> Fix this by extending the existing 32-bit padding field to 64-bit. Now
> the padding reflects the actual compiler padding. This can be verified
> using pahole(1).
>
> Also document the layout properly in the vhost-user specification.  The
> vhost-user spec did not document the exact layout. It would be
> impossible to implement the spec without looking at the QEMU source
> code.
>
> Existing vhost-user frontends and device backends continue to work after
> this fix has been applied. The only change in the wire protocol is that
> QEMU now sets hdr.size to 40 instead of 36. If a vhost-user
> implementation has a hardcoded size check for 36 bytes, then it will
> fail with new QEMUs. Both QEMU and DPDK/SPDK don't check the exact
> payload size, so they continue to work.
>
> Fixes: f1aeb14b0809e313c74244d838645ed25e85ea63 ("Transmit vhost-user memory 
> regions individually")
> Cc: Raphael Norwitz 
> Cc: Cornelia Huck 
> Cc: Michael S. Tsirkin 
> Cc: Christian Borntraeger 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  docs/interop/vhost-user.rst   | 21 +++--
>  contrib/libvhost-user/libvhost-user.h |  2 +-
>  hw/virtio/vhost-user.c|  5 ++---
>  3 files changed, 22 insertions(+), 6 deletions(-)
>

Reviewed-by: Raphael Norwitz 

Re: [PATCH 4/5 v4] KVM: VMX: Fill in conforming vmx_x86_ops via macro

[Like Xu]

Hi Krish,

On 2020/11/10 9:23, Krish Sadhukhan wrote:

@@ -1192,7 +1192,7 @@ void vmx_set_host_fs_gs(struct vmcs_host_state *host, u16 
fs_sel, u16 gs_sel,
}
  }
  
-void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu)

+void vmx_prepare_guest_switch(struct kvm_vcpu *vcpu)


What do you think of renaming it to

void vmx_prepare_switch_for_guest(struct kvm_vcpu *vcpu)；

?

Thanks,
Like Xu


  {
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct vmcs_host_state *host_state;

@@ -311,7 +311,7 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu,
  int allocate_vpid(void);
  void free_vpid(int vpid);
  void vmx_set_constant_host_state(struct vcpu_vmx *vmx);
-void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu);
+void vmx_prepare_guest_switch(struct kvm_vcpu *vcpu);
  void vmx_set_host_fs_gs(struct vmcs_host_state *host, u16 fs_sel, u16 gs_sel,
unsigned long fs_base, unsigned long gs_base);
  int vmx_get_cpl(struct kvm_vcpu *vcpu);

QMP and the 'id' parameter

[John Snow]

The QMP specification states:

> NOTE: Some errors can occur before the Server is able to read the "id"
> member, in these cases the "id" member will not be part of the error
> response, even if provided by the client.

I am assuming this case ONLY occurs for Parse errors:

{'class': 'GenericError', 'desc': 'JSON parse error, expecting value'}

And I am assuming, in the context of a client that /always/ sets an 'id' 
for its execute statements, that this means that any error response we 
receive without an 'id' field *must* be associated with the 
most-recently-sent command.


Correct?

--js

Re: Question on UEFI ACPI tables setup and probing on arm64

[Ying Fang]

On 11/7/2020 1:09 AM, Laszlo Ersek wrote:

On 11/05/20 05:30, Ying Fang wrote:


I see it in Qemu the *loader_start* is fixed at 1 GiB on the
physical address space which points to the DRAM base. In ArmVirtQemu.dsc
PcdDeviceTreeInitialBaseAddress is set 0x4000 with correspondence.

Here I also see the discussion about DRAM base for ArmVirtQemu.
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03127.html

I am still not sure how UEFI knows that it is running on a ArmVirtQemu
machine type.


It doesn't know. It remains a convention.

This part is not auto-detected; the constants in QEMU and edk2 are
independently open-coded, their values were synchronized by human effort
initially.

The user or the management layer have to make sure they boot a UEFI
firmware binary on the machine type that is compatible with the machine
type.

There is some meta-data to help with that:



Thanks so much for the reply,
I now have the basic understanding how QEMU and EDK2 works together
after reading the docs and code there.


Does UEFI derive it from the fdt *compatible* property ?


Please see the schema "docs/interop/firmware.json" in the QEMU tree; in
particular the @FirmwareTarget element.

For an actual example: QEMU bundles some edk2 firmware binaries (purely
as a convenience, not for production), and those are accompanied by
matching descriptor files. See
"pc-bios/descriptors/60-edk2-aarch64.json". (It is a template that's
fixed up during QEMU installation, but that's tangential here.)

 "targets": [
 {
 "architecture": "aarch64",
 "machines": [
 "virt-*"
 ]
 }
 ],



Thanks, I'll look closer into it.


Thanks
Laszlo

.

[Bug 1902470] Re: migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts

[Chuan Zheng]

this commit is sent and may fix this issue, waiting for review.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg758017.html

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

Title:
  migration with TLS-MultiFD is stuck when the dst-libvirtd service
  restarts

Status in QEMU:
  In Progress

Bug description:
  hi,

  I found that the multi-channel TLS-handshake will be stuck when the
  dst-libvirtd restarts, both the src and dst sockets are blocked in
  recvmsg. In the meantime, live_migration thread is blocked in
  multifd_send_sync_main, so migration cannot be cancelled though src-
  libvirt has delivered the QMP command.

  Is there any way to exit migration when the multi-channel TLS-
  handshake is stuck? Does setting TLS-handshake timeout function take
  effect?

  The stack trace are as follows:

  =src qemu-system-aar stack=:
  #0  0x87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0
  #1  0xe3817424 in qio_channel_socket_readv (ioc=0xe9e30a30, 
iov=0xdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at 
../io/channel-socket.c:502
  #2  0xe380f468 in qio_channel_readv_full (ioc=0xe9e30a30, 
iov=0xdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66
  #3  0xe380f9e8 in qio_channel_read (ioc=0xe9e30a30, 
buf=0xea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at 
../io/channel.c:217
  #4  0xe380e7d4 in qio_channel_tls_read_handler (buf=0xea204e9b 
"\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53
  #5  0xe3801114 in qcrypto_tls_session_pull (opaque=0xe99d5700, 
buf=0xea204e9b, len=5) at ../crypto/tlssession.c:89
  #6  0x8822ed30 in _gnutls_stream_read (ms=0xdb58eaac, 
pull_func=0xfffd38001870, size=5, bufel=, 
session=0xe983cd60) at buffers.c:346
  #7  _gnutls_read (ms=0xdb58eaac, pull_func=0xfffd38001870, size=5, 
bufel=, session=0xe983cd60) at buffers.c:426
  #8  _gnutls_io_read_buffered (session=session@entry=0xe983cd60, total=5, 
recv_type=recv_type@entry=4294967295, ms=0xdb58eaac) at buffers.c:581
  #9  0x88224954 in recv_headers (ms=, 
record=0x883cd000 , 
htype=65535, type=2284006288, record_params=0xe9e22a60, 
session=0xe983cd60) at record.c:1163
  #10 _gnutls_recv_in_buffers (session=session@entry=0xe983cd60, 
type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, 
htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, ms=, 
ms@entry=0) at record.c:1302
  #11 0x88230568 in _gnutls_handshake_io_recv_int 
(session=session@entry=0xe983cd60, 
htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, 
hsk=hsk@entry=0xdb58ec38, optional=optional@entry=1) at buffers.c:1445
  #12 0x88232b90 in _gnutls_recv_handshake 
(session=session@entry=0xe983cd60, 
type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, 
optional=optional@entry=1, buf=buf@entry=0x0) at handshake.c:1534
  #13 0x88235b40 in handshake_client 
(session=session@entry=0xe983cd60) at handshake.c:2925
  #14 0x88237824 in gnutls_handshake (session=0xe983cd60) at 
handshake.c:2739
  #15 0xe380213c in qcrypto_tls_session_handshake 
(session=0xe99d5700, errp=0xdb58ee58) at ../crypto/tlssession.c:493
  #16 0xe380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, 
task=0xea61d4e0, context=0x0) at ../io/channel-tls.c:161
  #17 0xe380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, 
func=0xe3394d20 , opaque=0xea189c30, 
destroy=0x0, context=0x0) at ../io/channel-tls.c:239
  #18 0xe3394e78 in multifd_tls_channel_connect (p=0xea189c30, 
ioc=0xe9e30a30, errp=0xdb58ef28) at ../migration/multifd.c:782
  #19 0xe3394f30 in multifd_channel_connect (p=0xea189c30, 
ioc=0xe9e30a30, error=0x0) at ../migration/multifd.c:804
  #20 0xe33950b8 in multifd_new_send_channel_async 
(task=0xea6855a0, opaque=0xea189c30) at ../migration/multifd.c:858
  #21 0xe3810cf8 in qio_task_complete (task=0xea6855a0) at 
../io/task.c:197
  #22 0xe381096c in qio_task_thread_result (opaque=0xea6855a0) at 
../io/task.c:112
  #23 0x88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0
  #24 0x88705a7c in g_main_context_dispatch () from 
target:/usr/lib64/libglib-2.0.so.0
  #25 0xe3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221
  #26 0xe3a5a324 in os_host_main_loop_wait (timeout=0) at 
../util/main-loop.c:244
  #27 0xe3a5a444 in main_loop_wait (nonblocking=0) at 
../util/main-loop.c:520
  #28 0xe3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677
  #29 0xe30949e4 in main (argc=81, argv=0xdb58f2c8, 
envp=0xdb58f558) at ../softmmu/main.c:50

  =src live_migration stack=:
  #0  0x87d6a5d8 in 

Re: [PATCH v2] migration/multifd: close TLS channel before socket finalize

[Zheng Chuan]

Kindly ping.
Maybe this bugfix is need for qemu-5.2 version.

On 2020/11/6 18:54, Chuan Zheng wrote:
> Since we now support tls multifd, when we cancel migration, the TLS
> sockets will be left as CLOSE-WAIT On Src which results in socket
> leak.
> Fix it by closing TLS channel before socket finalize.
> 
> Signed-off-by: Chuan Zheng 
> ---
>  migration/multifd.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/migration/multifd.c b/migration/multifd.c
> index 68b171f..a6838dc 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -523,6 +523,19 @@ static void multifd_send_terminate_threads(Error *err)
>  }
>  }
>  
> +static void multifd_tls_socket_close(QIOChannel *ioc, Error *err)
> +{
> +if (ioc &&
> +object_dynamic_cast(OBJECT(ioc),
> +TYPE_QIO_CHANNEL_TLS)) {
> +/*
> + * TLS channel is special, we need close it before
> + * socket finalize.
> + */
> +qio_channel_close(ioc, );
> +}
> +}
> +
>  void multifd_save_cleanup(void)
>  {
>  int i;
> @@ -542,6 +555,7 @@ void multifd_save_cleanup(void)
>  MultiFDSendParams *p = _send_state->params[i];
>  Error *local_err = NULL;
>  
> +multifd_tls_socket_close(p->c, NULL);
>  socket_send_channel_destroy(p->c);
>  p->c = NULL;
>  qemu_mutex_destroy(>mutex);
> 

-- 
Regards.
Chuan

[PATCH 3/5 v4] KVM: nSVM: Fill in conforming svm_nested_ops via macro

[Krish Sadhukhan]

The names of the nested_svm_ops functions do not have a corresponding
'nested_svm_' prefix. Generate the names using a macro so that the names are
conformant. Fixing the naming will help in better readability and
maintenance of the code.

Suggested-by: Vitaly Kuznetsov 
Suggested-by: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Krish Sadhukhan 
---
 arch/x86/kvm/svm/nested.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 200674190449..4cdeacaf768f 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -196,7 +196,7 @@ static bool nested_svm_vmrun_msrpm(struct vcpu_svm *svm)
return true;
 }
 
-static bool svm_get_nested_state_pages(struct kvm_vcpu *vcpu)
+static bool nested_svm_get_pages(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
if (!nested_svm_vmrun_msrpm(svm)) {
@@ -834,7 +834,7 @@ static int nested_svm_intercept(struct vcpu_svm *svm)
/*
 * Host-intercepted exceptions have been checked already in
 * nested_svm_exit_special.  There is nothing to do here,
-* the vmexit is injected by svm_check_nested_events.
+* the vmexit is injected by nested_svm_check_events.
 */
vmexit = NESTED_EXIT_DONE;
break;
@@ -965,7 +965,7 @@ static void nested_svm_init(struct vcpu_svm *svm)
 }
 
 
-static int svm_check_nested_events(struct kvm_vcpu *vcpu)
+static int nested_svm_check_events(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
bool block_nested_events =
@@ -1049,7 +1049,7 @@ int nested_svm_exit_special(struct vcpu_svm *svm)
return NESTED_EXIT_CONTINUE;
 }
 
-static int svm_get_nested_state(struct kvm_vcpu *vcpu,
+static int nested_svm_get_state(struct kvm_vcpu *vcpu,
struct kvm_nested_state __user 
*user_kvm_nested_state,
u32 user_data_size)
 {
@@ -1106,7 +1106,7 @@ static int svm_get_nested_state(struct kvm_vcpu *vcpu,
return kvm_state.size;
 }
 
-static int svm_set_nested_state(struct kvm_vcpu *vcpu,
+static int nested_svm_set_state(struct kvm_vcpu *vcpu,
struct kvm_nested_state __user 
*user_kvm_nested_state,
struct kvm_nested_state *kvm_state)
 {
@@ -1209,9 +1209,11 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu,
return ret;
 }
 
+#define KVM_X86_NESTED_OP_NAME(name) .name = nested_svm_##name
+
 struct kvm_x86_nested_ops svm_nested_ops = {
-   .check_events = svm_check_nested_events,
-   .get_pages = svm_get_nested_state_pages,
-   .get_state = svm_get_nested_state,
-   .set_state = svm_set_nested_state,
+   KVM_X86_NESTED_OP_NAME(check_events),
+   KVM_X86_NESTED_OP_NAME(get_pages),
+   KVM_X86_NESTED_OP_NAME(get_state),
+   KVM_X86_NESTED_OP_NAME(set_state),
 };
-- 
2.18.4

[PATCH 2/5 v4] KVM: SVM: Fill in conforming svm_x86_ops via macro

[Krish Sadhukhan]

The names of some of the svm_x86_ops functions do not have a corresponding
'svm_' prefix. Generate the names using a macro so that the names are
conformant. Fixing the naming will help in better readability and
maintenance of the code.

Suggested-by: Vitaly Kuznetsov 
Suggested-by: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Krish Sadhukhan 
---
 arch/x86/kvm/pmu.h  |   2 +-
 arch/x86/kvm/svm/avic.c |  11 +-
 arch/x86/kvm/svm/pmu.c  |   2 +-
 arch/x86/kvm/svm/sev.c  |   4 +-
 arch/x86/kvm/svm/svm.c  | 296 ++--
 arch/x86/kvm/svm/svm.h  |  15 +-
 arch/x86/kvm/x86.c  |  11 +-
 7 files changed, 187 insertions(+), 154 deletions(-)

diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index 067fef51760c..a7f1f048c6a8 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -161,5 +161,5 @@ int kvm_vm_ioctl_set_pmu_event_filter(struct kvm *kvm, void 
__user *argp);
 bool is_vmware_backdoor_pmc(u32 pmc_idx);
 
 extern struct kvm_pmu_ops intel_pmu_ops;
-extern struct kvm_pmu_ops amd_pmu_ops;
+extern struct kvm_pmu_ops svm_pmu_ops;
 #endif /* __KVM_X86_PMU_H */
diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 8c550999ace0..1e709237a77f 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -577,7 +577,12 @@ int avic_init_vcpu(struct vcpu_svm *svm)
return ret;
 }
 
-void avic_post_state_restore(struct kvm_vcpu *vcpu)
+int svm_sync_pir_to_irr(struct kvm_vcpu *vcpu)
+{
+   return kvm_lapic_find_highest_irr(vcpu);
+}
+
+void svm_apicv_post_state_restore(struct kvm_vcpu *vcpu)
 {
if (avic_handle_apic_id_update(vcpu) != 0)
return;
@@ -658,7 +663,7 @@ void svm_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu)
 * we need to check and update the AVIC logical APIC ID table
 * accordingly before re-activating.
 */
-   avic_post_state_restore(vcpu);
+   svm_apicv_post_state_restore(vcpu);
vmcb->control.int_ctl |= AVIC_ENABLE_MASK;
} else {
vmcb->control.int_ctl &= ~AVIC_ENABLE_MASK;
@@ -673,7 +678,7 @@ void svm_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 
*eoi_exit_bitmap)
return;
 }
 
-int svm_deliver_avic_intr(struct kvm_vcpu *vcpu, int vec)
+int svm_deliver_interrupt(struct kvm_vcpu *vcpu, int vec)
 {
if (!vcpu->arch.apicv_active)
return -1;
diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
index 035da07500e8..e518372ab292 100644
--- a/arch/x86/kvm/svm/pmu.c
+++ b/arch/x86/kvm/svm/pmu.c
@@ -311,7 +311,7 @@ static void amd_pmu_reset(struct kvm_vcpu *vcpu)
}
 }
 
-struct kvm_pmu_ops amd_pmu_ops = {
+struct kvm_pmu_ops svm_pmu_ops = {
.find_arch_event = amd_find_arch_event,
.find_fixed_event = amd_find_fixed_event,
.pmc_is_enabled = amd_pmc_is_enabled,
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index c0b14106258a..53d8a6fbaf8e 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -984,7 +984,7 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
return r;
 }
 
-int svm_register_enc_region(struct kvm *kvm,
+int svm_mem_enc_register_region(struct kvm *kvm,
struct kvm_enc_region *range)
 {
struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
@@ -1053,7 +1053,7 @@ static void __unregister_enc_region_locked(struct kvm 
*kvm,
kfree(region);
 }
 
-int svm_unregister_enc_region(struct kvm *kvm,
+int svm_mem_enc_unregister_region(struct kvm *kvm,
  struct kvm_enc_region *range)
 {
struct enc_region *region;
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 5ee8eef1905a..6a845c9625ad 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -332,7 +332,7 @@ static void svm_set_interrupt_shadow(struct kvm_vcpu *vcpu, 
int mask)
 
 }
 
-static int skip_emulated_instruction(struct kvm_vcpu *vcpu)
+static int svm_skip_emulated_instruction(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
 
@@ -371,7 +371,7 @@ static void svm_queue_exception(struct kvm_vcpu *vcpu)
 * raises a fault that is not intercepted. Still better than
 * failing in all cases.
 */
-   (void)skip_emulated_instruction(>vcpu);
+   (void)svm_skip_emulated_instruction(>vcpu);
rip = kvm_rip_read(>vcpu);
svm->int3_rip = rip + svm->vmcb->save.cs.base;
svm->int3_injected = rip - old_rip;
@@ -1284,7 +1284,7 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
avic_update_vapic_bar(svm, APIC_DEFAULT_PHYS_BASE);
 }
 
-static int svm_create_vcpu(struct kvm_vcpu *vcpu)
+static int svm_vcpu_create(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm;
struct page *vmcb_page;
@@ -1338,7 +1338,7 @@ static void svm_clear_current_vmcb(struct 

[PATCH 1/5 v4] KVM: x86: Change names of some of the kvm_x86_ops functions to make them more semantical and readable

[Krish Sadhukhan]

Suggested-by: Vitaly Kuznetsov 
Suggested-by: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Krish Sadhukhan 
---
 arch/arm64/include/asm/kvm_host.h   |  2 +-
 arch/mips/include/asm/kvm_host.h|  2 +-
 arch/powerpc/include/asm/kvm_host.h |  2 +-
 arch/s390/kvm/kvm-s390.c|  2 +-
 arch/x86/include/asm/kvm_host.h | 16 +++
 arch/x86/kvm/lapic.c|  2 +-
 arch/x86/kvm/svm/nested.c   |  2 +-
 arch/x86/kvm/svm/svm.c  | 14 +++---
 arch/x86/kvm/vmx/nested.c   |  2 +-
 arch/x86/kvm/vmx/vmx.c  | 10 +-
 arch/x86/kvm/x86.c  | 30 ++---
 include/linux/kvm_host.h|  2 +-
 include/uapi/linux/kvm.h|  6 +++---
 tools/include/uapi/linux/kvm.h  |  6 +++---
 virt/kvm/kvm_main.c |  4 ++--
 15 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index 781d029b8aa8..50d0768f3aef 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -592,7 +592,7 @@ static inline bool kvm_arch_requires_vhe(void)
 
 void kvm_arm_vcpu_ptrauth_trap(struct kvm_vcpu *vcpu);
 
-static inline void kvm_arch_hardware_unsetup(void) {}
+static inline void kvm_arch_hardware_teardown(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
 static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 24f3d0f9996b..88ec47f7a56a 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -1145,7 +1145,7 @@ extern unsigned long kvm_mips_get_ramsize(struct kvm 
*kvm);
 extern int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu,
 struct kvm_mips_interrupt *irq);
 
-static inline void kvm_arch_hardware_unsetup(void) {}
+static inline void kvm_arch_hardware_teardown(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_free_memslot(struct kvm *kvm,
 struct kvm_memory_slot *slot) {}
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index d67a470e95a3..5a702ce6398a 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -860,7 +860,7 @@ struct kvm_vcpu_arch {
 #define __KVM_HAVE_CREATE_DEVICE
 
 static inline void kvm_arch_hardware_disable(void) {}
-static inline void kvm_arch_hardware_unsetup(void) {}
+static inline void kvm_arch_hardware_teardown(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_memslots_updated(struct kvm *kvm, u64 gen) {}
 static inline void kvm_arch_flush_shadow_all(struct kvm *kvm) {}
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 6b74b92c1a58..e503263a0ef7 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -312,7 +312,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
 }
 
-void kvm_arch_hardware_unsetup(void)
+void kvm_arch_hardware_teardown(void)
 {
gmap_unregister_pte_notifier(_notifier);
gmap_unregister_pte_notifier(_gmap_notifier);
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d44858b69353..3f3948f08440 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1085,7 +1085,7 @@ static inline u16 kvm_lapic_irq_dest_mode(bool 
dest_mode_logical)
 struct kvm_x86_ops {
int (*hardware_enable)(void);
void (*hardware_disable)(void);
-   void (*hardware_unsetup)(void);
+   void (*hardware_teardown)(void);
bool (*cpu_has_accelerated_tpr)(void);
bool (*has_emulated_msr)(u32 index);
void (*vcpu_after_set_cpuid)(struct kvm_vcpu *vcpu);
@@ -1146,7 +1146,7 @@ struct kvm_x86_ops {
 */
void (*tlb_flush_guest)(struct kvm_vcpu *vcpu);
 
-   enum exit_fastpath_completion (*run)(struct kvm_vcpu *vcpu);
+   enum exit_fastpath_completion (*vcpu_run)(struct kvm_vcpu *vcpu);
int (*handle_exit)(struct kvm_vcpu *vcpu,
enum exit_fastpath_completion exit_fastpath);
int (*skip_emulated_instruction)(struct kvm_vcpu *vcpu);
@@ -1155,8 +1155,8 @@ struct kvm_x86_ops {
u32 (*get_interrupt_shadow)(struct kvm_vcpu *vcpu);
void (*patch_hypercall)(struct kvm_vcpu *vcpu,
unsigned char *hypercall_addr);
-   void (*set_irq)(struct kvm_vcpu *vcpu);
-   void (*set_nmi)(struct kvm_vcpu *vcpu);
+   void (*inject_irq)(struct kvm_vcpu *vcpu);
+   void (*inject_nmi)(struct kvm_vcpu *vcpu);
void (*queue_exception)(struct kvm_vcpu *vcpu);
void (*cancel_injection)(struct kvm_vcpu *vcpu);
int 

[PATCH 4/5 v4] KVM: VMX: Fill in conforming vmx_x86_ops via macro

[Krish Sadhukhan]

The names of some of the vmx_x86_ops functions do not have a corresponding
'vmx_' prefix. Generate the names using a macro so that the names are
conformant. Fixing the naming will help in better readability and
maintenance of the code.

Suggested-by: Vitaly Kuznetsov 
Suggested-by: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Krish Sadhukhan 
---
 arch/x86/kvm/pmu.h |   2 +-
 arch/x86/kvm/vmx/nested.c  |   4 +-
 arch/x86/kvm/vmx/pmu_intel.c   |   2 +-
 arch/x86/kvm/vmx/posted_intr.c |   6 +-
 arch/x86/kvm/vmx/posted_intr.h |   4 +-
 arch/x86/kvm/vmx/vmx.c | 262 +
 arch/x86/kvm/vmx/vmx.h |   4 +-
 7 files changed, 144 insertions(+), 140 deletions(-)

diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index a7f1f048c6a8..b8049ee4d1ab 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -160,6 +160,6 @@ int kvm_vm_ioctl_set_pmu_event_filter(struct kvm *kvm, void 
__user *argp);
 
 bool is_vmware_backdoor_pmc(u32 pmc_idx);
 
-extern struct kvm_pmu_ops intel_pmu_ops;
+extern struct kvm_pmu_ops vmx_pmu_ops;
 extern struct kvm_pmu_ops svm_pmu_ops;
 #endif /* __KVM_X86_PMU_H */
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 6c32f73cffd5..d97fbf1a6a17 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2532,7 +2532,7 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct 
vmcs12 *vmcs12,
 * bitwise-or of what L1 wants to trap for L2, and what we want to
 * trap. Note that CR0.TS also needs updating - we do this later.
 */
-   update_exception_bitmap(vcpu);
+   vmx_update_exception_bitmap(vcpu);
vcpu->arch.cr0_guest_owned_bits &= ~vmcs12->cr0_guest_host_mask;
vmcs_writel(CR0_GUEST_HOST_MASK, ~vcpu->arch.cr0_guest_owned_bits);
 
@@ -3034,7 +3034,7 @@ static int nested_vmx_check_vmentry_hw(struct kvm_vcpu 
*vcpu)
 
preempt_disable();
 
-   vmx_prepare_switch_to_guest(vcpu);
+   vmx_prepare_guest_switch(vcpu);
 
/*
 * Induce a consistency check VMExit by clearing bit 1 in GUEST_RFLAGS,
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index a886a47daebd..c39f1dbcd436 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -427,7 +427,7 @@ static void intel_pmu_reset(struct kvm_vcpu *vcpu)
pmu->global_ovf_ctrl = 0;
 }
 
-struct kvm_pmu_ops intel_pmu_ops = {
+struct kvm_pmu_ops vmx_pmu_ops = {
.find_arch_event = intel_find_arch_event,
.find_fixed_event = intel_find_fixed_event,
.pmc_is_enabled = intel_pmc_is_enabled,
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index f02962dcc72c..39c7ccabfd82 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -228,7 +228,7 @@ void __init pi_init_cpu(int cpu)
spin_lock_init(_cpu(blocked_vcpu_on_cpu_lock, cpu));
 }
 
-bool pi_has_pending_interrupt(struct kvm_vcpu *vcpu)
+bool vmx_dy_apicv_has_pending_interrupt(struct kvm_vcpu *vcpu)
 {
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
 
@@ -238,7 +238,7 @@ bool pi_has_pending_interrupt(struct kvm_vcpu *vcpu)
 
 
 /*
- * pi_update_irte - set IRTE for Posted-Interrupts
+ * vmx_pi_update_irte - set IRTE for Posted-Interrupts
  *
  * @kvm: kvm
  * @host_irq: host irq of the interrupt
@@ -246,7 +246,7 @@ bool pi_has_pending_interrupt(struct kvm_vcpu *vcpu)
  * @set: set or unset PI
  * returns 0 on success, < 0 on failure
  */
-int pi_update_irte(struct kvm *kvm, unsigned int host_irq, uint32_t guest_irq,
+int vmx_update_pi_irte(struct kvm *kvm, unsigned int host_irq, uint32_t 
guest_irq,
   bool set)
 {
struct kvm_kernel_irq_routing_entry *e;
diff --git a/arch/x86/kvm/vmx/posted_intr.h b/arch/x86/kvm/vmx/posted_intr.h
index 0bdc41391c5b..76ab06faec26 100644
--- a/arch/x86/kvm/vmx/posted_intr.h
+++ b/arch/x86/kvm/vmx/posted_intr.h
@@ -92,8 +92,8 @@ int pi_pre_block(struct kvm_vcpu *vcpu);
 void pi_post_block(struct kvm_vcpu *vcpu);
 void pi_wakeup_handler(void);
 void __init pi_init_cpu(int cpu);
-bool pi_has_pending_interrupt(struct kvm_vcpu *vcpu);
-int pi_update_irte(struct kvm *kvm, unsigned int host_irq, uint32_t guest_irq,
+bool vmx_dy_apicv_has_pending_interrupt(struct kvm_vcpu *vcpu);
+int vmx_update_pi_irte(struct kvm *kvm, unsigned int host_irq, uint32_t 
guest_irq,
   bool set);
 
 #endif /* __KVM_X86_VMX_POSTED_INTR_H */
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index ddfc127d5c4f..b077d7cf5d01 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -629,7 +629,7 @@ static inline bool cpu_need_virtualize_apic_accesses(struct 
kvm_vcpu *vcpu)
return flexpriority_enabled && lapic_in_kernel(vcpu);
 }
 
-static inline bool report_flexpriority(void)
+static inline bool vmx_cpu_has_accelerated_tpr(void)
 {
return flexpriority_enabled;
 }
@@ -807,7 +807,7 @@ static 

[PATCH 5/5 v4] KVM: nVMX: Fill in conforming vmx_nested_ops via macro

[Krish Sadhukhan]

The names of some of the vmx_nested_ops functions do not have a corresponding
'nested_vmx_' prefix. Generate the names using a macro so that the names are
conformant. Fixing the naming will help in better readability and
maintenance of the code.

Suggested-by: Vitaly Kuznetsov 
Suggested-by: Paolo Bonzini 
Signed-off-by: Sean Christopherson 
Signed-off-by: Krish Sadhukhan 
---
 arch/x86/kvm/vmx/evmcs.c  |  6 +++---
 arch/x86/kvm/vmx/evmcs.h  |  4 ++--
 arch/x86/kvm/vmx/nested.c | 35 +--
 3 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kvm/vmx/evmcs.c b/arch/x86/kvm/vmx/evmcs.c
index f3199bb02f22..e54b366ea114 100644
--- a/arch/x86/kvm/vmx/evmcs.c
+++ b/arch/x86/kvm/vmx/evmcs.c
@@ -324,7 +324,7 @@ bool nested_enlightened_vmentry(struct kvm_vcpu *vcpu, u64 
*evmcs_gpa)
return true;
 }
 
-uint16_t nested_get_evmcs_version(struct kvm_vcpu *vcpu)
+uint16_t nested_vmx_get_evmcs_version(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
/*
@@ -418,7 +418,7 @@ int nested_evmcs_check_controls(struct vmcs12 *vmcs12)
return ret;
 }
 
-int nested_enable_evmcs(struct kvm_vcpu *vcpu,
+int nested_vmx_enable_evmcs(struct kvm_vcpu *vcpu,
uint16_t *vmcs_version)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -426,7 +426,7 @@ int nested_enable_evmcs(struct kvm_vcpu *vcpu,
vmx->nested.enlightened_vmcs_enabled = true;
 
if (vmcs_version)
-   *vmcs_version = nested_get_evmcs_version(vcpu);
+   *vmcs_version = nested_vmx_get_evmcs_version(vcpu);
 
return 0;
 }
diff --git a/arch/x86/kvm/vmx/evmcs.h b/arch/x86/kvm/vmx/evmcs.h
index bd41d9462355..150e7921b5fd 100644
--- a/arch/x86/kvm/vmx/evmcs.h
+++ b/arch/x86/kvm/vmx/evmcs.h
@@ -205,8 +205,8 @@ enum nested_evmptrld_status {
 };
 
 bool nested_enlightened_vmentry(struct kvm_vcpu *vcpu, u64 *evmcs_gpa);
-uint16_t nested_get_evmcs_version(struct kvm_vcpu *vcpu);
-int nested_enable_evmcs(struct kvm_vcpu *vcpu,
+uint16_t nested_vmx_get_evmcs_version(struct kvm_vcpu *vcpu);
+int nested_vmx_enable_evmcs(struct kvm_vcpu *vcpu,
uint16_t *vmcs_version);
 void nested_evmcs_filter_control_msr(u32 msr_index, u64 *pdata);
 int nested_evmcs_check_controls(struct vmcs12 *vmcs12);
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index d97fbf1a6a17..c26acf1dcce4 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3223,7 +3223,12 @@ static bool nested_get_vmcs12_pages(struct kvm_vcpu 
*vcpu)
return true;
 }
 
-static int nested_vmx_write_pml_buffer(struct kvm_vcpu *vcpu, gpa_t gpa)
+static bool nested_vmx_get_pages(struct kvm_vcpu *vcpu)
+{
+   return nested_get_vmcs12_pages(vcpu);
+}
+
+static int nested_vmx_write_log_dirty(struct kvm_vcpu *vcpu, gpa_t gpa)
 {
struct vmcs12 *vmcs12;
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -3769,13 +3774,13 @@ static void nested_vmx_update_pending_dbg(struct 
kvm_vcpu *vcpu)
vcpu->arch.exception.payload);
 }
 
-static bool nested_vmx_preemption_timer_pending(struct kvm_vcpu *vcpu)
+static bool nested_vmx_hv_timer_pending(struct kvm_vcpu *vcpu)
 {
return nested_cpu_has_preemption_timer(get_vmcs12(vcpu)) &&
   to_vmx(vcpu)->nested.preemption_timer_expired;
 }
 
-static int vmx_check_nested_events(struct kvm_vcpu *vcpu)
+static int nested_vmx_check_events(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qual;
@@ -3830,7 +3835,7 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu)
return 0;
}
 
-   if (nested_vmx_preemption_timer_pending(vcpu)) {
+   if (nested_vmx_hv_timer_pending(vcpu)) {
if (block_nested_events)
return -EBUSY;
nested_vmx_vmexit(vcpu, EXIT_REASON_PREEMPTION_TIMER, 0, 0);
@@ -5964,7 +5969,7 @@ bool nested_vmx_reflect_vmexit(struct kvm_vcpu *vcpu)
return true;
 }
 
-static int vmx_get_nested_state(struct kvm_vcpu *vcpu,
+static int nested_vmx_get_state(struct kvm_vcpu *vcpu,
struct kvm_nested_state __user 
*user_kvm_nested_state,
u32 user_data_size)
 {
@@ -6088,7 +6093,7 @@ void vmx_leave_nested(struct kvm_vcpu *vcpu)
free_nested(vcpu);
 }
 
-static int vmx_set_nested_state(struct kvm_vcpu *vcpu,
+static int nested_vmx_set_state(struct kvm_vcpu *vcpu,
struct kvm_nested_state __user 
*user_kvm_nested_state,
struct kvm_nested_state *kvm_state)
 {
@@ -6568,13 +6573,15 @@ __init int nested_vmx_hardware_setup(int 
(*exit_handlers[])(struct kvm_vcpu *))
return 0;
 }
 
+#define KVM_X86_NESTED_OP_NAME(name) .name = nested_vmx_##name
+
 struct kvm_x86_nested_ops vmx_nested_ops = {
-   .check_events = vmx_check_nested_events,
-   .hv_timer_pending = 

[PATCH 0/5 v4] KVM: x86: Fill in conforming {vmx|svm}_x86_ops and {vmx|svm}_nested_ops via macros

[Krish Sadhukhan]

v3 -> v4:
1. v3 did not include a few x86_ops and x86_nested_ops in the macro
   expansion process of function names. This set has covered all those
   left-out ops.
2. Patch# 6 from v3 has been dropped as those changes already exist in
   QEMU source.


[PATCH 1/5 v4] KVM: x86: Change names of some of the kvm_x86_ops
[PATCH 2/5 v4] KVM: SVM: Fill in conforming svm_x86_ops via macro
[PATCH 3/5 v4] KVM: nSVM: Fill in conforming svm_nested_ops via macro
[PATCH 4/5 v4] KVM: VMX: Fill in conforming vmx_x86_ops via macro
[PATCH 5/5 v4] KVM: nVMX: Fill in conforming vmx_nested_ops via macro

 arch/arm64/include/asm/kvm_host.h   |   2 +-
 arch/mips/include/asm/kvm_host.h|   2 +-
 arch/powerpc/include/asm/kvm_host.h |   2 +-
 arch/s390/kvm/kvm-s390.c|   2 +-
 arch/x86/include/asm/kvm_host.h |  16 +-
 arch/x86/kvm/lapic.c|   2 +-
 arch/x86/kvm/pmu.h  |   4 +-
 arch/x86/kvm/svm/avic.c |  11 +-
 arch/x86/kvm/svm/nested.c   |  20 +--
 arch/x86/kvm/svm/pmu.c  |   2 +-
 arch/x86/kvm/svm/sev.c  |   4 +-
 arch/x86/kvm/svm/svm.c  | 296 
 arch/x86/kvm/svm/svm.h  |  15 +-
 arch/x86/kvm/vmx/evmcs.c|   6 +-
 arch/x86/kvm/vmx/evmcs.h|   4 +-
 arch/x86/kvm/vmx/nested.c   |  39 +++--
 arch/x86/kvm/vmx/pmu_intel.c|   2 +-
 arch/x86/kvm/vmx/posted_intr.c  |   6 +-
 arch/x86/kvm/vmx/posted_intr.h  |   4 +-
 arch/x86/kvm/vmx/vmx.c  | 262 +++
 arch/x86/kvm/vmx/vmx.h  |   4 +-
 arch/x86/kvm/x86.c  |  41 ++---
 include/linux/kvm_host.h|   2 +-
 include/uapi/linux/kvm.h|   6 +-
 tools/include/uapi/linux/kvm.h  |   6 +-
 virt/kvm/kvm_main.c |   4 +-
 26 files changed, 405 insertions(+), 359 deletions(-)

Krish Sadhukhan (5):
  KVM: x86: Change names of some of the kvm_x86_ops functions to make them 
more semantical and readable
  KVM: SVM: Fill in conforming svm_x86_ops via macro
  KVM: nSVM: Fill in conforming svm_nested_ops via macro
  KVM: VMX: Fill in conforming vmx_x86_ops via macro
  KVM: nVMX: Fill in conforming vmx_nested_ops via macro

Re: [PATCH-for-6.0 0/2] target/mips: CP0 housekeeping patches for Nov 2020

[chen huacai]

Reviewed-by: Huacai Chen 

On Tue, Nov 10, 2020 at 1:37 AM Richard Henderson
 wrote:
>
> On 11/9/20 1:04 AM, Philippe Mathieu-Daudé wrote:
> > Based-on: <20201108234234.2389789-1-f4...@amsat.org>
> >
> > Philippe Mathieu-Daudé (2):
> >   target/mips: Replace magic values by CP0PM_MASK or
> > TARGET_PAGE_BITS_MIN
> >   target/mips: Do not include CP0 helpers in user-mode emulation
>
> Reviewed-by: Richard Henderson 
>
> r~
>


-- 
Huacai Chen

Re: [PATCH 0/2] virtiofsd: fix some accessing NULL pointer problem

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com/



Hi,

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

Message-id: eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com
Subject: [PATCH 0/2] virtiofsd: fix some accessing NULL pointer problem
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20201028185722.2783532-1-kei...@keithp.com -> 
patchew/20201028185722.2783532-1-kei...@keithp.com
 * [new tag] patchew/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com -> 
patchew/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com
Switched to a new branch 'test'
c91e972 virtiofsd: check whether lo_map_reserve returns NULL in main func
387bda7 tools/virtiofsd/buffer.c: check whether buf is NULL in 
fuse_bufvec_advance func

=== OUTPUT BEGIN ===
1/2 Checking commit 387bda78be64 (tools/virtiofsd/buffer.c: check whether buf 
is NULL in fuse_bufvec_advance func)
ERROR: braces {} are necessary for all arms of this statement
#23: FILE: tools/virtiofsd/buffer.c:249:
+if (!buf)
[...]

total: 1 errors, 0 warnings, 9 lines checked

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

2/2 Checking commit c91e9722f323 (virtiofsd: check whether lo_map_reserve 
returns NULL in main func)
ERROR: braces {} are necessary for all arms of this statement
#34: FILE: tools/virtiofsd/passthrough_ll.c:3457:
+if (!reserve_elem)
[...]

ERROR: braces {} are necessary for all arms of this statement
#38: FILE: tools/virtiofsd/passthrough_ll.c:3461:
+if (!root_elem)
[...]

total: 2 errors, 0 warnings, 21 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/eeb2fd1d-a53d-eae6-4727-7f1a6b20a...@huawei.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH 2/2] virtiofsd: check whether lo_map_reserve returns NULL in main func

[Haotian Li]

In main func, func lo_map_reserve is called without NULL check.
If reallocing new_elems fails in func lo_map_grow, the func
lo_map_reserve may return NULL. We should check whether
lo_map_reserve returns NULL before using it.

Signed-off-by: Haotian Li 
Signed-off-by: Zhiqiang Liu 
---
 tools/virtiofsd/passthrough_ll.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index ec1008bceb..147c5381e9 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -3433,6 +3433,7 @@ int main(int argc, char *argv[])
 .proc_self_fd = -1,
 };
 struct lo_map_elem *root_elem;
+struct lo_map_elem *reserve_elem;
 int ret = -1;

 /* Don't mask creation mode, kernel already did that */
@@ -3452,8 +3453,13 @@ int main(int argc, char *argv[])
  * [1] Root inode
  */
 lo_map_init(_map);
-lo_map_reserve(_map, 0)->in_use = false;
+reserve_elem = lo_map_reserve(_map, 0);
+if (!reserve_elem)
+goto err_out1;
+reserve_elem->in_use = false;
 root_elem = lo_map_reserve(_map, lo.root.fuse_ino);
+if (!root_elem)
+goto err_out1;
 root_elem->inode = 

 lo_map_init(_map);
-- 

[PATCH 1/2] tools/virtiofsd/buffer.c: check whether buf is NULL in fuse_bufvec_advance func

[Haotian Li]

In fuse_bufvec_advance func, calling fuse_bufvec_current func
may return NULL, so we should check whether buf is NULL before
using it.

Signed-off-by: Haotian Li 
Signed-off-by: Zhiqiang Liu 
---
 tools/virtiofsd/buffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/virtiofsd/buffer.c b/tools/virtiofsd/buffer.c
index 27c1377f22..c94993b936 100644
--- a/tools/virtiofsd/buffer.c
+++ b/tools/virtiofsd/buffer.c
@@ -246,6 +246,9 @@ static int fuse_bufvec_advance(struct fuse_bufvec *bufv, 
size_t len)
 {
 const struct fuse_buf *buf = fuse_bufvec_current(bufv);

+if (!buf)
+return 0;
+
 bufv->off += len;
 assert(bufv->off <= buf->size);
 if (bufv->off == buf->size) {
-- 

[PATCH 0/2] virtiofsd: fix some accessing NULL pointer problem

[Haotian Li]

Hi,
  We find some potential NULL pointer bugs on tools/virtiofsd.
Two patches are made to fix them.

Haotian Li (2):
  tools/virtiofsd/buffer.c: check whether buf is NULL in
fuse_bufvec_advance func
  virtiofsd/passthrough_ll.c: check whether lo_map_reserve returns NULL
in main func

 tools/virtiofsd/buffer.c | 3 +++
 tools/virtiofsd/passthrough_ll.c | 8 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

RE: [PATCH] hw/intc: fix heap-buffer-overflow in rxicu_realize()

[Chenqun (kuhn)]

Ping,

Fix: e78597cc457ff7611 
Maybe this bug needs to qemu-5.2 version.

The "icu->nr_sense" is array length.  It's a typical out-of-bounds array bug.


Thanks,
Chen Qun

> -Original Message-
> From: Chenqun (kuhn)
> Sent: Thursday, November 5, 2020 3:06 PM
> To: qemu-devel@nongnu.org; qemu-triv...@nongnu.org
> Cc: Zhanghailiang ; ganqixin
> ; Chenqun (kuhn) ;
> Euler Robot ; Yoshinori Sato
> 
> Subject: [PATCH] hw/intc: fix heap-buffer-overflow in rxicu_realize()
> 
> When 'j = icu->nr_sense – 1', the 'j < icu->nr_sense' condition is true, then 
> 'j =
> icu->nr_sense', the'icu->init_sense[j]' has out-of-bounds access.
> Maybe this could lead to some security problems.
> 
> The asan showed stack:
> ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60404d7d at
> pc 0x55852cd26a76 bp 0x7ffe39f26200 sp 0x7ffe39f261f0 READ of size 1 at
> 0x60404d7d thread T0
> #0 0x55852cd26a75 in rxicu_realize ../hw/intc/rx_icu.c:311
> #1 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
> #2 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
> #3 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
> #4 0x55852cd54f3f in
> object_property_set_qobject ../qom/qom-qobject.c:28
> #5 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
> #6 0x55852cbf0b27 in register_icu ../hw/rx/rx62n.c:156
> #7 0x55852cbf12a6 in rx62n_realize ../hw/rx/rx62n.c:261
> #8 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
> #9 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
> #10 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
> #11 0x55852cd54f3f in
> object_property_set_qobject ../qom/qom-qobject.c:28
> #12 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
> #13 0x55852cbf1a85 in rx_gdbsim_init ../hw/rx/rx-gdbsim.c:109
> #14 0x55852cd22de0 in qemu_init ../softmmu/vl.c:4380
> #15 0x55852ca57088 in main ../softmmu/main.c:49
> #16 0x7feefafa5d42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
> 
> Change the 'j < icu->nr_sense' condition place to fix it.
> 
> Reported-by: Euler Robot 
> Signed-off-by: Chen Qun 
> ---
> Cc: Yoshinori Sato 
> ---
>  hw/intc/rx_icu.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/intc/rx_icu.c b/hw/intc/rx_icu.c index 94e17a9dea..692a4c78e0
> 100644
> --- a/hw/intc/rx_icu.c
> +++ b/hw/intc/rx_icu.c
> @@ -308,11 +308,9 @@ static void rxicu_realize(DeviceState *dev, Error
> **errp)
>  return;
>  }
>  for (i = j = 0; i < NR_IRQS; i++) {
> -if (icu->init_sense[j] == i) {
> +if (j < icu->nr_sense && icu->init_sense[j] == i) {
>  icu->src[i].sense = TRG_LEVEL;
> -if (j < icu->nr_sense) {
> -j++;
> -}
> +j++;
>  } else {
>  icu->src[i].sense = TRG_PEDGE;
>  }
> --
> 2.27.0

RE: [PATCH v3 1/3] hw/block/m25p80: Fix Numonyx NVCFG DIO and QIO bit polarity

[Joe Komlodi]

Hi Philippe,

-Original Message-
From: Philippe Mathieu-Daudé  
Sent: Monday, November 9, 2020 6:21 AM
To: Joe Komlodi ; qemu-devel@nongnu.org; Cédric Le Goater 
; Edgar Iglesias 
Cc: Francisco Eduardo Iglesias ; alist...@alistair23.me; 
philippe.mathieu.da...@gmail.com; qemu-bl...@nongnu.org; mre...@redhat.com
Subject: Re: [PATCH v3 1/3] hw/block/m25p80: Fix Numonyx NVCFG DIO and QIO bit 
polarity

On 11/6/20 2:32 AM, Joe Komlodi wrote:
> QIO and DIO modes should be enabled when the bits in NVCFG are set to 0.
> This matches the behavior of the other bits in the NVCFG register.

Is this material for the 5.2 release?

[Joe] If possible, yeah.  Otherwise if it's too late for 5.2 I have no problems 
pushing it to a later release.
Thanks!
Joe

> 
> Signed-off-by: Joe Komlodi 
> ---
>  hw/block/m25p80.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c index 
> 483925f..4255a6a 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -783,10 +783,10 @@ static void reset_memory(Flash *s)
>  s->enh_volatile_cfg |= EVCFG_OUT_DRIVER_STRENGTH_DEF;
>  s->enh_volatile_cfg |= EVCFG_VPP_ACCELERATOR;
>  s->enh_volatile_cfg |= EVCFG_RESET_HOLD_ENABLED;
> -if (s->nonvolatile_cfg & NVCFG_DUAL_IO_MASK) {
> +if (!(s->nonvolatile_cfg & NVCFG_DUAL_IO_MASK)) {
>  s->enh_volatile_cfg |= EVCFG_DUAL_IO_ENABLED;
>  }
> -if (s->nonvolatile_cfg & NVCFG_QUAD_IO_MASK) {
> +if (!(s->nonvolatile_cfg & NVCFG_QUAD_IO_MASK)) {
>  s->enh_volatile_cfg |= EVCFG_QUAD_IO_ENABLED;
>  }
>  if (!(s->nonvolatile_cfg & NVCFG_4BYTE_ADDR_MASK)) {
> 

Re: [PATCH v2 4/4] hw/riscv: Load the kernel after the firmware

[Alistair Francis]

On Thu, Nov 5, 2020 at 8:15 PM Anup Patel  wrote:
>
>
>
> > -Original Message-
> > From: Qemu-riscv  > bounces+anup.patel=wdc@nongnu.org> On Behalf Of Palmer Dabbelt
> > Sent: 06 November 2020 08:19
> > To: alistai...@gmail.com
> > Cc: qemu-ri...@nongnu.org; bmeng...@gmail.com; Alistair Francis
> > ; qemu-devel@nongnu.org
> > Subject: Re: [PATCH v2 4/4] hw/riscv: Load the kernel after the firmware
> >
> > On Tue, 20 Oct 2020 08:46:45 PDT (-0700), alistai...@gmail.com wrote:
> > > On Mon, Oct 19, 2020 at 4:17 PM Palmer Dabbelt 
> > wrote:
> > >>
> > >> On Tue, 13 Oct 2020 17:17:33 PDT (-0700), Alistair Francis wrote:
> > >> > Instead of loading the kernel at a hardcoded start address, let's
> > >> > load the kernel at the next alligned address after the end of the
> > firmware.
> > >> >
> > >> > This should have no impact for current users of OpenSBI, but will
> > >> > allow loading a noMMU kernel at the start of memory.
> > >> >
> > >> > Signed-off-by: Alistair Francis 
> > >> > ---
> > >> >  include/hw/riscv/boot.h |  3 +++
> > >> >  hw/riscv/boot.c | 19 ++-
> > >> >  hw/riscv/opentitan.c|  3 ++-
> > >> >  hw/riscv/sifive_e.c |  3 ++-
> > >> >  hw/riscv/sifive_u.c | 10 --
> > >> >  hw/riscv/spike.c| 11 ---
> > >> >  hw/riscv/virt.c | 11 ---
> > >> >  7 files changed, 45 insertions(+), 15 deletions(-)
> > >> >
> > >> > diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
> > >> > index 2975ed1a31..0b01988727 100644
> > >> > --- a/include/hw/riscv/boot.h
> > >> > +++ b/include/hw/riscv/boot.h
> > >> > @@ -25,6 +25,8 @@
> > >> >
> > >> >  bool riscv_is_32_bit(MachineState *machine);
> > >> >
> > >> > +target_ulong riscv_calc_kernel_start_addr(MachineState *machine,
> > >> > +  target_ulong
> > >> > +firmware_end_addr);
> > >> >  target_ulong riscv_find_and_load_firmware(MachineState *machine,
> > >> >const char 
> > >> > *default_machine_firmware,
> > >> >hwaddr
> > >> > firmware_load_addr, @@ -34,6 +36,7 @@ target_ulong
> > riscv_load_firmware(const char *firmware_filename,
> > >> >   hwaddr firmware_load_addr,
> > >> >   symbol_fn_t sym_cb);
> > >> > target_ulong riscv_load_kernel(const char *kernel_filename,
> > >> > +   target_ulong firmware_end_addr,
> > >> > symbol_fn_t sym_cb);  hwaddr
> > >> > riscv_load_initrd(const char *filename, uint64_t mem_size,
> > >> >   uint64_t kernel_entry, hwaddr *start);
> > >> > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c index
> > >> > 5dea644f47..9b3fe3fb1e 100644
> > >> > --- a/hw/riscv/boot.c
> > >> > +++ b/hw/riscv/boot.c
> > >> > @@ -33,10 +33,8 @@
> > >> >  #include 
> > >> >
> > >> >  #if defined(TARGET_RISCV32)
> > >> > -# define KERNEL_BOOT_ADDRESS 0x8040
> > >> >  #define fw_dynamic_info_data(__val) cpu_to_le32(__val)
> > >> >  #else
> > >> > -# define KERNEL_BOOT_ADDRESS 0x8020
> > >> >  #define fw_dynamic_info_data(__val) cpu_to_le64(__val)
> > >> >  #endif
> > >> >
> > >> > @@ -49,6 +47,15 @@ bool riscv_is_32_bit(MachineState *machine)
> > >> >  }
> > >> >  }
> > >> >
> > >> > +target_ulong riscv_calc_kernel_start_addr(MachineState *machine,
> > >> > +  target_ulong 
> > >> > firmware_end_addr) {
> > >> > +if (riscv_is_32_bit(machine)) {
> > >> > +return QEMU_ALIGN_UP(firmware_end_addr, 4 * MiB);
> > >> > +} else {
> > >> > +return QEMU_ALIGN_UP(firmware_end_addr, 2 * MiB);
> > >> > +}
> > >> > +}
> > >> > +
> > >> >  target_ulong riscv_find_and_load_firmware(MachineState *machine,
> > >> >const char 
> > >> > *default_machine_firmware,
> > >> >hwaddr
> > >> > firmware_load_addr, @@ -123,7 +130,9 @@ target_ulong
> > riscv_load_firmware(const char *firmware_filename,
> > >> >  exit(1);
> > >> >  }
> > >> >
> > >> > -target_ulong riscv_load_kernel(const char *kernel_filename,
> > >> > symbol_fn_t sym_cb)
> > >> > +target_ulong riscv_load_kernel(const char *kernel_filename,
> > >> > +   target_ulong kernel_start_addr,
> > >> > +   symbol_fn_t sym_cb)
> > >> >  {
> > >> >  uint64_t kernel_entry;
> > >> >
> > >> > @@ -138,9 +147,9 @@ target_ulong riscv_load_kernel(const char
> > *kernel_filename, symbol_fn_t sym_cb)
> > >> >  return kernel_entry;
> > >> >  }
> > >> >
> > >> > -if (load_image_targphys_as(kernel_filename,
> > KERNEL_BOOT_ADDRESS,
> > >> > +if (load_image_targphys_as(kernel_filename, kernel_start_addr,
> > >> > ram_size, NULL) > 0) {
> > >> > -return KERNEL_BOOT_ADDRESS;
> > >> > +  

Re: [PATCH 1/4] semihosting: Move ARM semihosting code to shared directories [v3]

[Alistair Francis]

On Wed, Oct 28, 2020 at 11:57 AM Keith Packard via
 wrote:
>
> This commit renames two files which provide ARM semihosting support so
> that they can be shared by other architectures:
>
>  1. target/arm/arm-semi.c -> hw/semihosting/common-semi.c
>  2. linux-user/arm/semihost.c -> linux-user/semihost.c
>
> The build system was modified use a new config variable,
> CONFIG_ARM_COMPATIBLE_SEMIHOSTING, which has been added to the ARM
> softmmu and linux-user default configs. The contents of the source
> files has not been changed in this patch.
>
> Signed-off-by: Keith Packard 

Reviewed-by: Alistair Francis 

Alistair

>
> 
>
> v2
> Place common-semi.c name in arm_ss, just as arm-semi.c was
>
> v3
> Create CONFIG_ARM_COMPATIBLE_SEMIHOSTING and assign in
> arm config files
> ---
>  default-configs/devices/arm-softmmu.mak   | 1 +
>  default-configs/targets/aarch64-linux-user.mak| 1 +
>  default-configs/targets/arm-linux-user.mak| 1 +
>  hw/semihosting/Kconfig| 3 +++
>  target/arm/arm-semi.c => hw/semihosting/common-semi.c | 0
>  hw/semihosting/meson.build| 3 +++
>  linux-user/arm/meson.build| 3 ---
>  linux-user/meson.build| 1 +
>  linux-user/{arm => }/semihost.c   | 0
>  target/arm/meson.build| 2 --
>  10 files changed, 10 insertions(+), 5 deletions(-)
>  rename target/arm/arm-semi.c => hw/semihosting/common-semi.c (100%)
>  rename linux-user/{arm => }/semihost.c (100%)
>
> diff --git a/default-configs/devices/arm-softmmu.mak 
> b/default-configs/devices/arm-softmmu.mak
> index 08a32123b4..0500156a0c 100644
> --- a/default-configs/devices/arm-softmmu.mak
> +++ b/default-configs/devices/arm-softmmu.mak
> @@ -42,4 +42,5 @@ CONFIG_FSL_IMX25=y
>  CONFIG_FSL_IMX7=y
>  CONFIG_FSL_IMX6UL=y
>  CONFIG_SEMIHOSTING=y
> +CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
>  CONFIG_ALLWINNER_H3=y
> diff --git a/default-configs/targets/aarch64-linux-user.mak 
> b/default-configs/targets/aarch64-linux-user.mak
> index 163c9209f4..4713253709 100644
> --- a/default-configs/targets/aarch64-linux-user.mak
> +++ b/default-configs/targets/aarch64-linux-user.mak
> @@ -2,3 +2,4 @@ TARGET_ARCH=aarch64
>  TARGET_BASE_ARCH=arm
>  TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml 
> gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml gdb-xml/arm-vfp3.xml 
> gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
>  TARGET_HAS_BFLT=y
> +CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
> diff --git a/default-configs/targets/arm-linux-user.mak 
> b/default-configs/targets/arm-linux-user.mak
> index c7cd872e86..e741ffd4d3 100644
> --- a/default-configs/targets/arm-linux-user.mak
> +++ b/default-configs/targets/arm-linux-user.mak
> @@ -3,3 +3,4 @@ TARGET_SYSTBL_ABI=common,oabi
>  TARGET_SYSTBL=syscall.tbl
>  TARGET_XML_FILES= gdb-xml/arm-core.xml gdb-xml/arm-vfp.xml 
> gdb-xml/arm-vfp3.xml gdb-xml/arm-neon.xml gdb-xml/arm-m-profile.xml
>  TARGET_HAS_BFLT=y
> +CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
> diff --git a/hw/semihosting/Kconfig b/hw/semihosting/Kconfig
> index efe0a30734..4c30dc6b16 100644
> --- a/hw/semihosting/Kconfig
> +++ b/hw/semihosting/Kconfig
> @@ -1,3 +1,6 @@
>
>  config SEMIHOSTING
> bool
> +
> +config ARM_COMPATIBLE_SEMIHOSTING
> +   bool
> diff --git a/target/arm/arm-semi.c b/hw/semihosting/common-semi.c
> similarity index 100%
> rename from target/arm/arm-semi.c
> rename to hw/semihosting/common-semi.c
> diff --git a/hw/semihosting/meson.build b/hw/semihosting/meson.build
> index f40ac574c4..5b4a170270 100644
> --- a/hw/semihosting/meson.build
> +++ b/hw/semihosting/meson.build
> @@ -2,3 +2,6 @@ specific_ss.add(when: 'CONFIG_SEMIHOSTING', if_true: files(
>'config.c',
>'console.c',
>  ))
> +
> +specific_ss.add(when: ['CONFIG_ARM_COMPATIBLE_SEMIHOSTING'],
> +   if_true: files('common-semi.c'))
> diff --git a/linux-user/arm/meson.build b/linux-user/arm/meson.build
> index 432984b58e..5a93c925cf 100644
> --- a/linux-user/arm/meson.build
> +++ b/linux-user/arm/meson.build
> @@ -1,6 +1,3 @@
> -linux_user_ss.add(when: 'TARGET_AARCH64', if_true: files('semihost.c'))
> -linux_user_ss.add(when: 'TARGET_ARM', if_true: files('semihost.c'))
> -
>  subdir('nwfpe')
>
>  syscall_nr_generators += {
> diff --git a/linux-user/meson.build b/linux-user/meson.build
> index 2b94e4ba24..7fe28d659e 100644
> --- a/linux-user/meson.build
> +++ b/linux-user/meson.build
> @@ -16,6 +16,7 @@ linux_user_ss.add(rt)
>
>  linux_user_ss.add(when: 'TARGET_HAS_BFLT', if_true: files('flatload.c'))
>  linux_user_ss.add(when: 'TARGET_I386', if_true: files('vm86.c'))
> +linux_user_ss.add(when: 'CONFIG_ARM_COMPATIBLE_SEMIHOSTING', if_true: 
> files('semihost.c'))
>
>
>  syscall_nr_generators = {}
> diff --git a/linux-user/arm/semihost.c b/linux-user/semihost.c
> similarity index 100%
> rename from linux-user/arm/semihost.c
> rename to 

Re: [PATCH v1 1/1] hw/intc/ibex_plic: Clear the claim register when read

[Alistair Francis]

On Fri, Nov 6, 2020 at 6:20 AM Philippe Mathieu-Daudé  wrote:
>
> On 11/6/20 3:32 AM, Alistair Francis wrote:
> > After claiming the interrupt by reading the claim register we want to
> > clear the register to make sure the interrupt doesn't appear at the next
> > read.
> >
> > This matches the documentation for the claim register as it clears the
> > pending bit (which we already do): 
> > https://docs.opentitan.org/hw/ip/rv_plic/doc/index.html
>
> "When an interrupt is claimed by a target the relevant bit of IP is
> cleared." Correct.

Yep, I improved this.

>
> Reviewed-by: Philippe Mathieu-Daudé 

Thanks

Alistair

>
> >
> > This also matches the current hardware.
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >  hw/intc/ibex_plic.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/hw/intc/ibex_plic.c b/hw/intc/ibex_plic.c
> > index f49fa67c91..235e6b88ff 100644
> > --- a/hw/intc/ibex_plic.c
> > +++ b/hw/intc/ibex_plic.c
> > @@ -139,6 +139,9 @@ static uint64_t ibex_plic_read(void *opaque, hwaddr 
> > addr,
> >  /* Return the current claimed interrupt */
> >  ret = s->claim;
> >
> > +/* Clear the claimed interrupt */
> > +s->claim = 0x;
> > +
> >  /* Update the interrupt status after the claim */
> >  ibex_plic_update(s);
> >  }
> >
>

[Bug 1734474] Re: Maemo does not boot on emulated N800

[Peter Maydell]

This change on current head-of-git, which is effectively just reverting the 
logic-change part of commit cb5ef3fa1871522a08, is sufficient to allow the n800 
image to boot again. 
But that commit was trying to fix a bug, so we probably need to look more 
carefully at the logic rather than just reverting it...

diff --git a/hw/misc/tmp105.c b/hw/misc/tmp105.c
index b47120492a..1813477268 100644
--- a/hw/misc/tmp105.c
+++ b/hw/misc/tmp105.c
@@ -161,14 +161,12 @@ static int tmp105_tx(I2CSlave *i2c, uint8_t data)
 {
 TMP105State *s = TMP105(i2c);
 
-if (s->len == 0) {
+if (!s->len++) {
 s->pointer = data;
-s->len++;
 } else {
 if (s->len <= 2) {
 s->buf[s->len - 1] = data;
 }
-s->len++;
 tmp105_write(s);
 }

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

Title:
  Maemo does not boot on emulated N800

Status in QEMU:
  Confirmed

Bug description:
  I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock 
maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2"
  On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and 
newer (including latest versions) I see only white screen and no signs of life. 
Was this caused by regression or any syntax change?

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

[Bug 1734474] Re: Maemo does not boot on emulated N800

[Peter Maydell]

Bisection thinks commit cb5ef3fa1871522a08 is the cause.

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

Title:
  Maemo does not boot on emulated N800

Status in QEMU:
  Confirmed

Bug description:
  I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock 
maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2"
  On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and 
newer (including latest versions) I see only white screen and no signs of life. 
Was this caused by regression or any syntax change?

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

[Bug 1734474] Re: Maemo does not boot on emulated N800

[Peter Maydell]

Thanks. I can confirm that there's been a regression since 1.2.0 that's
still not fixed in master.


** 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/1734474

Title:
  Maemo does not boot on emulated N800

Status in QEMU:
  Confirmed

Bug description:
  I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock 
maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2"
  On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and 
newer (including latest versions) I see only white screen and no signs of life. 
Was this caused by regression or any syntax change?

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

[RFC 2/2] docs: Build and install all the docs in a single manual

[Peter Maydell]

When we first converted our documentation to Sphinx, we split it into
multiple manuals (system, interop, tools, etc), which are all built
separately.  The primary driver for this was wanting to be able to
avoid shipping the 'devel' manual to end-users.  However, this is
working against the grain of the way Sphinx wants to be used and
causes some annoyances:
 * Cross-references between documents become much harder or
   possibly impossible
 * There is no single index to the whole documentation
 * Within one manual there's no links or table-of-contents info
   that lets you easily navigate to the others
 * The devel manual doesn't get published on the QEMU website
   (it would be nice to able to refer to it there)

Merely hiding our developer documentation from end users seems like
it's not enough benefit for these costs.  Combine all the
documentation into a single manual (the same way that the readthedocs
site builds it) and install the whole thing.  The previous manual
divisions remain as the new top level sections in the manual.

 * The per-manual conf.py files are no longer needed
 * The man_pages[] specifications previously in each per-manual
   conf.py move to the top level conf.py
 * docs/meson.build logic is simplified as we now only need to run
   Sphinx once for the HTML and then once for the manpages5B
 * The old index.html.in that produced the top-level page with
   links to each manual is no longer needed

Unfortunately this means that we now have to build the HTML
documentation into docs/manual in the build tree rather than directly
into docs/; otherwise it is too awkward to ensure we install only the
built manual and not also the dependency info, stamp file, etc.  The
manual still ends up in the same place in the final installed
directory, but anybody who was consulting documentation from within
the build tree will have to adjust where they're looking.

Signed-off-by: Peter Maydell 
---
 docs/conf.py | 37 -
 docs/devel/conf.py   | 15 ---
 docs/index.html.in   | 17 
 docs/interop/conf.py | 26 --
 docs/meson.build | 64 +---
 docs/specs/conf.py   | 16 ---
 docs/system/conf.py  | 28 ---
 docs/tools/conf.py   | 33 ---
 docs/user/conf.py| 15 ---
 9 files changed, 61 insertions(+), 190 deletions(-)
 delete mode 100644 docs/devel/conf.py
 delete mode 100644 docs/index.html.in
 delete mode 100644 docs/interop/conf.py
 delete mode 100644 docs/specs/conf.py
 delete mode 100644 docs/system/conf.py
 delete mode 100644 docs/tools/conf.py
 delete mode 100644 docs/user/conf.py

diff --git a/docs/conf.py b/docs/conf.py
index e584f683938..3bc9b35872a 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -223,7 +223,42 @@ latex_documents = [
 
 # -- Options for manual page output ---
 # Individual manual/conf.py can override this to create man pages
-man_pages = []
+man_pages = [
+('interop/qemu-ga', 'qemu-ga',
+ 'QEMU Guest Agent',
+ ['Michael Roth '], 8),
+('interop/qemu-ga-ref', 'qemu-ga-ref',
+ 'QEMU Guest Agent Protocol Reference',
+ [], 7),
+('interop/qemu-qmp-ref', 'qemu-qmp-ref',
+ 'QEMU QMP Reference Manual',
+ [], 7),
+('system/qemu-manpage', 'qemu',
+ 'QEMU User Documentation',
+ ['Fabrice Bellard'], 1),
+('system/qemu-block-drivers', 'qemu-block-drivers',
+ 'QEMU block drivers reference',
+ ['Fabrice Bellard and the QEMU Project developers'], 7),
+('system/qemu-cpu-models', 'qemu-cpu-models',
+ 'QEMU CPU Models',
+ ['The QEMU Project developers'], 7),
+('tools/qemu-img', 'qemu-img',
+ 'QEMU disk image utility',
+ ['Fabrice Bellard'], 1),
+('tools/qemu-nbd', 'qemu-nbd',
+ 'QEMU Disk Network Block Device Server',
+ ['Anthony Liguori '], 8),
+('tools/qemu-trace-stap', 'qemu-trace-stap',
+ 'QEMU SystemTap trace tool',
+ [], 1),
+('tools/virtfs-proxy-helper', 'virtfs-proxy-helper',
+ 'QEMU 9p virtfs proxy filesystem helper',
+ ['M. Mohan Kumar'], 1),
+('tools/virtiofsd', 'virtiofsd',
+ 'QEMU virtio-fs shared file system daemon',
+ ['Stefan Hajnoczi ',
+  'Masayoshi Mizuma '], 1),
+]
 
 # -- Options for Texinfo output ---
 
diff --git a/docs/devel/conf.py b/docs/devel/conf.py
deleted file mode 100644
index 7441f87e7f5..000
--- a/docs/devel/conf.py
+++ /dev/null
@@ -1,15 +0,0 @@
-# -*- coding: utf-8 -*-
-#
-# QEMU documentation build configuration file for the 'devel' manual.
-#
-# This includes the top level conf file and then makes any necessary tweaks.
-import sys
-import os
-
-qemu_docdir = os.path.abspath("..")
-parent_config = os.path.join(qemu_docdir, "conf.py")
-exec(compile(open(parent_config, "rb").read(), parent_config, 'exec'))
-
-# This slightly misuses the 'description', but is the best way to get
-# the manual title 

[RFC 0/2] Build a single Sphinx manual, not five

[Peter Maydell]

When we first converted our documentation to Sphinx, we split it into
multiple manuals (system, interop, tools, etc), which are all built
separately.  The primary driver for this was wanting to be able to
avoid shipping the 'devel' manual to end-users.  However, this is
working against the grain of the way Sphinx wants to be used and
causes some annoyances:
 * Cross-references between documents become much harder or
   possibly impossible (currently we don't even try)
 * There is no single index to the whole documentation
 * Within one manual there's no links or table-of-contents info
   that lets you easily navigate to the others
 * The devel manual doesn't get published on the QEMU website
   (it would be nice to able to refer to it there)
 * Common information like the QEMU license, supported platforms,
   and deprecation information either gets duplicated across manuals,
   split between them, or shoved into the system manual as the
   closest to a generic one

Merely hiding our developer documentation from end users seems like
it's not enough benefit for these costs.

This RFC series switches over to building a single big manual,
the same way that the readthedocs version builds it.

Patch 1 in the set suppresses the warnings that would otherwise
be caused by the handful of 'orphan' rst files in the top level
directory. This is not the correct long-term thing to do with these
files -- my suggestions for most of them are in this thread:
https://lore.kernel.org/qemu-devel/CAFEAcA_ff6bRythvzJWs0McUSz3=2=1=hv9wx_btv00jpfs...@mail.gmail.com/
 -- but for the purposes of this series and until somebody
cleans them up properly, this is the minimal necessary change,
because it's patch 2 that I'm really interested in opinions on.

Earlier discussion on one manual vs multiple was partly on IRC
but also in this thread:
https://lore.kernel.org/qemu-devel/CAFEAcA_4wXqGeOgsY2GbY1mk==dcz--j-jhs+odgqnohef+...@mail.gmail.com/

Incidentally, historically we did ship some internals documentation
to end users -- the old qemu-tech.texi "translator internals"
ended up in the user manual. The new 'devel' manual is a lot
bigger, of course.

If you don't want to apply this patch and build the docs to see
what the effect is, you can just look at the readthedocs output
to see what one-big-manual looks like:
https://qemu.readthedocs.io/en/latest/

Side note: it would be nice not to have to duplicate the
list of manpages in docs/conf.py and docs/meson.build. I think
if we didn't insist on only installing the manpages that apply
to the configuration we built for (ie if we installed the full
manpage docs the same way we install the full HTML docs
regardless of config) we could do that, by having Sphinx
build the manpages into a manpages/man[178]/ hierarchy and
just having meson.build do an install_subdir() on it. But
for this patchset I've retained the current behaviour.

thanks
-- PMM

Peter Maydell (2):
  docs: Mark rst files in the top level directory as orphan
  docs: Build and install all the docs in a single manual

 docs/conf.py | 37 -
 docs/cpu-hotplug.rst |  2 ++
 docs/devel/conf.py   | 15 -
 docs/index.html.in   | 17 --
 docs/interop/conf.py | 26 ---
 docs/meson.build | 64 ++--
 docs/microvm.rst |  2 ++
 docs/pr-manager.rst  |  2 ++
 docs/specs/conf.py   | 16 -
 docs/system/conf.py  | 28 
 docs/tools/conf.py   | 33 ---
 docs/user/conf.py| 15 -
 docs/virtio-net-failover.rst |  2 ++
 docs/virtio-pmem.rst |  1 +
 14 files changed, 70 insertions(+), 190 deletions(-)
 delete mode 100644 docs/devel/conf.py
 delete mode 100644 docs/index.html.in
 delete mode 100644 docs/interop/conf.py
 delete mode 100644 docs/specs/conf.py
 delete mode 100644 docs/system/conf.py
 delete mode 100644 docs/tools/conf.py
 delete mode 100644 docs/user/conf.py

-- 
2.20.1

[RFC 1/2] docs: Mark rst files in the top level directory as orphan

[Peter Maydell]

We have a handful of rst files currently in the top level docs
directory. These need to be moved into their proper places in the
new manual framework, possibly involving splitting them into
multiple pieces.

In the meantime, to avoid warnings about these documents being
orphaned if you build a single Sphinx manual rooted in docs/,
mark each of them as being deliberate orphans.

Signed-off-by: Peter Maydell 
---
 docs/cpu-hotplug.rst | 2 ++
 docs/microvm.rst | 2 ++
 docs/pr-manager.rst  | 2 ++
 docs/virtio-net-failover.rst | 2 ++
 docs/virtio-pmem.rst | 1 +
 5 files changed, 9 insertions(+)

diff --git a/docs/cpu-hotplug.rst b/docs/cpu-hotplug.rst
index d0b06403f19..d5fe2c7db1a 100644
--- a/docs/cpu-hotplug.rst
+++ b/docs/cpu-hotplug.rst
@@ -1,3 +1,5 @@
+:orphan:
+
 ===
 Virtual CPU hotplug
 ===
diff --git a/docs/microvm.rst b/docs/microvm.rst
index fcf41fc1f6f..8de8cea1864 100644
--- a/docs/microvm.rst
+++ b/docs/microvm.rst
@@ -1,3 +1,5 @@
+:orphan:
+
 
 microvm Machine Type
 
diff --git a/docs/pr-manager.rst b/docs/pr-manager.rst
index 9b1de198b1b..87a2f237f52 100644
--- a/docs/pr-manager.rst
+++ b/docs/pr-manager.rst
@@ -1,3 +1,5 @@
+:orphan:
+
 ==
 Persistent reservation managers
 ==
diff --git a/docs/virtio-net-failover.rst b/docs/virtio-net-failover.rst
index 6002dc5d96e..9d50d457e72 100644
--- a/docs/virtio-net-failover.rst
+++ b/docs/virtio-net-failover.rst
@@ -1,3 +1,5 @@
+:orphan:
+
 ==
 QEMU virtio-net standby (net_failover)
 ==
diff --git a/docs/virtio-pmem.rst b/docs/virtio-pmem.rst
index 4bf5d004432..aab35489851 100644
--- a/docs/virtio-pmem.rst
+++ b/docs/virtio-pmem.rst
@@ -1,3 +1,4 @@
+:orphan:
 
 
 QEMU virtio pmem
-- 
2.20.1

Re: [PATCH v2 6/6] qemu-option: warn for short-form boolean options

[Paolo Bonzini]

Il lun 9 nov 2020, 22:19 Markus Armbruster  ha scritto:

> This function now warns, except for "help" and "?".  The exception
> applies even when we treat "help" and "?" as sugar for "help=on" and
> "?=on" because opts_accepts_any().
>

Right, because again help_wanted will be false for non-validated
QemuOptsList.

Summary: only qemu_opts_parse_noisily() warns.  This is airtight only if
> all user input flows through qemu_opts_parse_noisily().


HMP doesn't. But that's too hard to change now, and it's not considered as
much of a stable interface as the command line.

Anyway I am not going to push this for 5.2. Thanks for the speedy reviews
anyway!

Paolo

Re: [PATCH 0/8] qom: Use qlit to represent property defaults

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20201109212556.3934583-1-ehabk...@redhat.com/



Hi,

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

Message-id: 20201109212556.3934583-1-ehabk...@redhat.com
Subject: [PATCH 0/8] qom: Use qlit to represent property defaults
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20201109212556.3934583-1-ehabk...@redhat.com -> 
patchew/20201109212556.3934583-1-ehabk...@redhat.com
Switched to a new branch 'test'
514115e qom: Use qlit to represent property defaults
2ca3561 qom: Make object_property_set_default() public
4c261ae qlit: qlit_type() function
8b601c4 qlit: Support all types of QNums
2d5f1af qnum: qnum_value_is_equal() function
be74c49 qnum: QNumValue type for QNum value literals
87b0edc qnum: Make qnum_get_double() get const pointer
ab4b510 qobject: Include API docs in docs/devel/qobject.html

=== OUTPUT BEGIN ===
1/8 Checking commit ab4b510c0e22 (qobject: Include API docs in 
docs/devel/qobject.html)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#23: 
new file mode 100644

total: 0 errors, 1 warnings, 201 lines checked

Patch 1/8 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/8 Checking commit 87b0edcb50a7 (qnum: Make qnum_get_double() get const 
pointer)
3/8 Checking commit be74c4978f05 (qnum: QNumValue type for QNum value literals)
4/8 Checking commit 2d5f1af84646 (qnum: qnum_value_is_equal() function)
5/8 Checking commit 8b601c44266e (qlit: Support all types of QNums)
ERROR: line over 90 characters
#64: FILE: qobject/qlit.c:74:
+return qnum_value_is_equal(>value.qnum, 
qnum_get_value(qobject_to(QNum, rhs)));

total: 1 errors, 0 warnings, 154 lines checked

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

6/8 Checking commit 4c261ae4c3f2 (qlit: qlit_type() function)
7/8 Checking commit 2ca3561ee690 (qom: Make object_property_set_default() 
public)
8/8 Checking commit 514115e597f1 (qom: Use qlit to represent property defaults)
WARNING: Block comments use a leading /* on a separate line
#148: FILE: include/qom/property-types.h:33:
+/* Note that __VA_ARGS__ can still override .defval */   \

total: 0 errors, 1 warnings, 325 lines checked

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

Test command exited with code: 1


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

[PATCH 8/8] qom: Use qlit to represent property defaults

[Eduardo Habkost]

Using QLitObject lets us get rid of most of the
.set_default_value functions, and just use
object_property_set_default() directly.

Signed-off-by: Eduardo Habkost 
---
 include/hw/qdev-properties-system.h   |  2 +-
 include/qom/field-property-internal.h |  4 ---
 include/qom/field-property.h  | 26 ---
 include/qom/property-types.h  | 21 +++-
 hw/core/qdev-properties-system.c  |  8 --
 qom/field-property.c  | 27 ++--
 qom/property-types.c  | 36 ---
 7 files changed, 44 insertions(+), 80 deletions(-)

diff --git a/include/hw/qdev-properties-system.h 
b/include/hw/qdev-properties-system.h
index 0ac327ae60..a586424a33 100644
--- a/include/hw/qdev-properties-system.h
+++ b/include/hw/qdev-properties-system.h
@@ -65,7 +65,7 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 
 #define DEFINE_PROP_UUID(_name, _state, _field) \
 DEFINE_PROP(_name, _state, _field, qdev_prop_uuid, QemuUUID, \
-.set_default = true)
+.defval = QLIT_QSTR("auto"))
 
 #define DEFINE_PROP_AUDIODEV(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_audiodev, QEMUSoundCard)
diff --git a/include/qom/field-property-internal.h 
b/include/qom/field-property-internal.h
index 7aa27ce836..09877d9d6f 100644
--- a/include/qom/field-property-internal.h
+++ b/include/qom/field-property-internal.h
@@ -15,10 +15,6 @@ void field_prop_set_enum(Object *obj, Visitor *v, const char 
*name,
 
 void field_prop_set_default_value_enum(ObjectProperty *op,
const Property *prop);
-void field_prop_set_default_value_int(ObjectProperty *op,
-  const Property *prop);
-void field_prop_set_default_value_uint(ObjectProperty *op,
-   const Property *prop);
 
 void field_prop_get_int32(Object *obj, Visitor *v, const char *name,
   void *opaque, Error **errp);
diff --git a/include/qom/field-property.h b/include/qom/field-property.h
index bc866e1c93..b83b424a5e 100644
--- a/include/qom/field-property.h
+++ b/include/qom/field-property.h
@@ -6,6 +6,7 @@
 
 #include "qom/object.h"
 #include "qapi/util.h"
+#include "qapi/qmp/qlit.h"
 
 /**
  * struct Property: definition of a field property
@@ -29,21 +30,8 @@ struct Property {
 const PropertyInfo *info;
 ptrdiff_toffset;
 uint8_t  bitnr;
-/**
- * @set_default: true if the default value should be set from @defval,
- *in which case @info->set_default_value must not be NULL
- *(if false then no default value is set by the property system
- * and the field retains whatever value it was given by instance_init).
- */
-bool set_default;
-/**
- * @defval: default value for the property. This is used only if 
@set_default
- * is true.
- */
-union {
-int64_t i;
-uint64_t u;
-} defval;
+/** @defval: If not QNull, the default value for the property */
+QLitObject defval;
 /* private: */
 int  arrayoffset;
 const PropertyInfo *arrayinfo;
@@ -63,7 +51,13 @@ struct PropertyInfo {
 const QEnumLookup *enum_table;
 /** @print: String formatting function, for the human monitor */
 int (*print)(Object *obj, Property *prop, char *dest, size_t len);
-/** @set_default_value: Callback for initializing the default value */
+/**
+ * @set_default_value: Optional callback for initializing the default value
+ *
+ * Most property types don't need to set this, as by default
+ * object_property_set_default() is called with the value at
+ * Property.defval.
+ */
 void (*set_default_value)(ObjectProperty *op, const Property *prop);
 /** @create: Optional callback for creation of property */
 ObjectProperty *(*create)(ObjectClass *oc, const char *name,
diff --git a/include/qom/property-types.h b/include/qom/property-types.h
index 3a36e1fec5..36ca6f9e55 100644
--- a/include/qom/property-types.h
+++ b/include/qom/property-types.h
@@ -5,6 +5,7 @@
 #define QOM_PROPERTY_TYPES_H
 
 #include "qom/field-property.h"
+#include "qapi/qmp/qlit.h"
 
 extern const PropertyInfo prop_info_bit;
 extern const PropertyInfo prop_info_bit64;
@@ -28,13 +29,14 @@ extern const PropertyInfo prop_info_link;
 .info  = &(_prop),   \
 .offset= offsetof(_state, _field)\
 + type_check(_type, typeof_field(_state, _field)),   \
+.defval = QLIT_QNULL,\
+/* Note that __VA_ARGS__ can still override .defval */   \
 __VA_ARGS__  \
 }
 
 #define DEFINE_PROP_SIGNED(_name, _state, _field, _defval, _prop, _type) \
 DEFINE_PROP(_name, _state, _field, _prop, _type, \
-.set_default 

[PATCH 7/8] qom: Make object_property_set_default() public

[Eduardo Habkost]

The function will be used outside qom/object.c, to simplify the
field property code that sets the property default value.

Signed-off-by: Eduardo Habkost 
---
 include/qom/object.h | 11 +++
 qom/object.c |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index 2ab124b8f0..4234cc9b66 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1090,6 +1090,17 @@ ObjectProperty *object_class_property_add(ObjectClass 
*klass, const char *name,
   ObjectPropertyRelease *release,
   void *opaque);
 
+/**
+ * object_property_set_default:
+ * @prop: the property to set
+ * @value: the value to be written to the property
+ *
+ * Set the property default value.
+ *
+ * Ownership of @value is transferred to the property.
+ */
+void object_property_set_default(ObjectProperty *prop, QObject *value);
+
 /**
  * object_property_set_default_bool:
  * @prop: the property to set
diff --git a/qom/object.c b/qom/object.c
index 7c11bcd3b1..6b0d9d8c79 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -1547,7 +1547,7 @@ static void object_property_init_defval(Object *obj, 
ObjectProperty *prop)
 visit_free(v);
 }
 
-static void object_property_set_default(ObjectProperty *prop, QObject *defval)
+void object_property_set_default(ObjectProperty *prop, QObject *defval)
 {
 assert(!prop->defval);
 assert(!prop->init);
-- 
2.28.0

[PATCH 5/8] qlit: Support all types of QNums

[Eduardo Habkost]

Use QNumValue to represent QNums, so we can also support uint64_t
and double QNum values.  Add new QLIT_QNUM_(INT|UINT|DOUBLE)
macros for each case.

The QLIT_QNUM() macro is being kept for compatibility with
existing code, but becomes just a wrapper for QLIT_QNUM_INT().

Signed-off-by: Eduardo Habkost 
---
 include/qapi/qmp/qlit.h | 11 +--
 qobject/qlit.c  |  4 +--
 tests/check-qjson.c | 72 ++---
 3 files changed, 78 insertions(+), 9 deletions(-)

diff --git a/include/qapi/qmp/qlit.h b/include/qapi/qmp/qlit.h
index c0676d5daf..f9e356d31e 100644
--- a/include/qapi/qmp/qlit.h
+++ b/include/qapi/qmp/qlit.h
@@ -15,6 +15,7 @@
 #define QLIT_H
 
 #include "qobject.h"
+#include "qnum.h"
 
 typedef struct QLitDictEntry QLitDictEntry;
 typedef struct QLitObject QLitObject;
@@ -23,7 +24,7 @@ struct QLitObject {
 QType type;
 union {
 bool qbool;
-int64_t qnum;
+QNumValue qnum;
 const char *qstr;
 QLitDictEntry *qdict;
 QLitObject *qlist;
@@ -39,8 +40,14 @@ struct QLitDictEntry {
 { .type = QTYPE_QNULL }
 #define QLIT_QBOOL(val) \
 { .type = QTYPE_QBOOL, .value.qbool = (val) }
+#define QLIT_QNUM_INT(val) \
+{ .type = QTYPE_QNUM, .value.qnum = QNUM_VAL_INT(val) }
+#define QLIT_QNUM_UINT(val) \
+{ .type = QTYPE_QNUM, .value.qnum = QNUM_VAL_UINT(val) }
+#define QLIT_QNUM_DOUBLE(val) \
+{ .type = QTYPE_QNUM, .value.qnum = QNUM_VAL_DOUBLE(val) }
 #define QLIT_QNUM(val) \
-{ .type = QTYPE_QNUM, .value.qnum = (val) }
+QLIT_QNUM_INT(val)
 #define QLIT_QSTR(val) \
 { .type = QTYPE_QSTRING, .value.qstr = (val) }
 #define QLIT_QDICT(val) \
diff --git a/qobject/qlit.c b/qobject/qlit.c
index be8332136c..ec11a39518 100644
--- a/qobject/qlit.c
+++ b/qobject/qlit.c
@@ -71,7 +71,7 @@ bool qlit_equal_qobject(const QLitObject *lhs, const QObject 
*rhs)
 case QTYPE_QBOOL:
 return lhs->value.qbool == qbool_get_bool(qobject_to(QBool, rhs));
 case QTYPE_QNUM:
-return lhs->value.qnum ==  qnum_get_int(qobject_to(QNum, rhs));
+return qnum_value_is_equal(>value.qnum, 
qnum_get_value(qobject_to(QNum, rhs)));
 case QTYPE_QSTRING:
 return (strcmp(lhs->value.qstr,
qstring_get_str(qobject_to(QString, rhs))) == 0);
@@ -94,7 +94,7 @@ QObject *qobject_from_qlit(const QLitObject *qlit)
 case QTYPE_QNULL:
 return QOBJECT(qnull());
 case QTYPE_QNUM:
-return QOBJECT(qnum_from_int(qlit->value.qnum));
+return QOBJECT(qnum_from_value(qlit->value.qnum));
 case QTYPE_QSTRING:
 return QOBJECT(qstring_from_str(qlit->value.qstr));
 case QTYPE_QDICT: {
diff --git a/tests/check-qjson.c b/tests/check-qjson.c
index 07a773e653..711030cffd 100644
--- a/tests/check-qjson.c
+++ b/tests/check-qjson.c
@@ -796,20 +796,23 @@ static void simple_number(void)
 int i;
 struct {
 const char *encoded;
+QLitObject qlit;
 int64_t decoded;
 int skip;
 } test_cases[] = {
-{ "0", 0 },
-{ "1234", 1234 },
-{ "1", 1 },
-{ "-32", -32 },
-{ "-0", 0, .skip = 1 },
+{ "0",QLIT_QNUM(0),0, },
+{ "1234", QLIT_QNUM(1234), 1234, },
+{ "1",QLIT_QNUM(1),1, },
+{ "-32",  QLIT_QNUM(-32),  -32, },
+{ "-0",   QLIT_QNUM(0),0, .skip = 1 },
 { },
 };
 
 for (i = 0; test_cases[i].encoded; i++) {
 QNum *qnum;
 int64_t val;
+QNum *qlit_num;
+int64_t qlit_val;
 
 qnum = qobject_to(QNum,
   qobject_from_json(test_cases[i].encoded,
@@ -817,6 +820,7 @@ static void simple_number(void)
 g_assert(qnum);
 g_assert(qnum_get_try_int(qnum, ));
 g_assert_cmpint(val, ==, test_cases[i].decoded);
+
 if (test_cases[i].skip == 0) {
 QString *str;
 
@@ -826,9 +830,66 @@ static void simple_number(void)
 }
 
 qobject_unref(qnum);
+
+qlit_num = qobject_to(QNum,
+  qobject_from_qlit(_cases[i].qlit));
+g_assert(qlit_num);
+g_assert(qnum_get_try_int(qlit_num, _val));
+g_assert_cmpint(qlit_val, ==, test_cases[i].decoded);
+
+qobject_unref(qlit_num);
 }
 }
 
+static void qlit_large_number(void)
+{
+QLitObject maxu64 = QLIT_QNUM_UINT(UINT64_MAX);
+QLitObject maxi64 = QLIT_QNUM(INT64_MAX);
+QLitObject mini64 = QLIT_QNUM(INT64_MIN);
+QLitObject gtu64  = QLIT_QNUM_DOUBLE(18446744073709552e3);
+QLitObject lti64  = QLIT_QNUM_DOUBLE(-92233720368547758e2);
+QNum *qnum;
+uint64_t val;
+int64_t ival;
+
+qnum = qobject_to(QNum, qobject_from_qlit());
+g_assert(qnum);
+g_assert_cmpuint(qnum_get_uint(qnum), ==, UINT64_MAX);
+g_assert(!qnum_get_try_int(qnum, ));
+
+qobject_unref(qnum);
+
+qnum = qobject_to(QNum, qobject_from_qlit());
+g_assert(qnum);
+

[PATCH 6/8] qlit: qlit_type() function

[Eduardo Habkost]

Useful function where we need to check for the qlit type before
converting it to an actual QObject.

Signed-off-by: Eduardo Habkost 
---
 include/qapi/qmp/qlit.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/qapi/qmp/qlit.h b/include/qapi/qmp/qlit.h
index f9e356d31e..acddb80831 100644
--- a/include/qapi/qmp/qlit.h
+++ b/include/qapi/qmp/qlit.h
@@ -59,4 +59,9 @@ bool qlit_equal_qobject(const QLitObject *lhs, const QObject 
*rhs);
 
 QObject *qobject_from_qlit(const QLitObject *qlit);
 
+static inline QType qlit_type(const QLitObject *qlit)
+{
+return qlit->type;
+}
+
 #endif /* QLIT_H */
-- 
2.28.0

[PATCH 2/8] qnum: Make qnum_get_double() get const pointer

[Eduardo Habkost]

qnum_get_double() won't change the object, the argument can be
const.

Signed-off-by: Eduardo Habkost 
---
 include/qapi/qmp/qnum.h | 2 +-
 qobject/qnum.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/qapi/qmp/qnum.h b/include/qapi/qmp/qnum.h
index 25f4733efc..55c27b1c24 100644
--- a/include/qapi/qmp/qnum.h
+++ b/include/qapi/qmp/qnum.h
@@ -66,7 +66,7 @@ int64_t qnum_get_int(const QNum *qn);
 bool qnum_get_try_uint(const QNum *qn, uint64_t *val);
 uint64_t qnum_get_uint(const QNum *qn);
 
-double qnum_get_double(QNum *qn);
+double qnum_get_double(const QNum *qn);
 
 char *qnum_to_string(QNum *qn);
 
diff --git a/qobject/qnum.c b/qobject/qnum.c
index 017c8aa739..69fd9a82d9 100644
--- a/qobject/qnum.c
+++ b/qobject/qnum.c
@@ -154,7 +154,7 @@ uint64_t qnum_get_uint(const QNum *qn)
  *
  * qnum_get_double() loses precision for integers beyond 53 bits.
  */
-double qnum_get_double(QNum *qn)
+double qnum_get_double(const QNum *qn)
 {
 switch (qn->kind) {
 case QNUM_I64:
-- 
2.28.0

[PATCH 1/8] qobject: Include API docs in docs/devel/qobject.html

[Eduardo Habkost]

Render existing doc comments at docs/devel/qobject.html.

Signed-off-by: Eduardo Habkost 
---
 docs/devel/index.rst   |  1 +
 docs/devel/qobject.rst | 11 +
 include/qapi/qmp/qnum.h|  4 +++-
 include/qapi/qmp/qobject.h | 48 +-
 qobject/qnum.c | 19 ---
 5 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 docs/devel/qobject.rst

diff --git a/docs/devel/index.rst b/docs/devel/index.rst
index 77baae5c77..7f8e5e3071 100644
--- a/docs/devel/index.rst
+++ b/docs/devel/index.rst
@@ -34,3 +34,4 @@ Contents:
clocks
qom
block-coroutine-wrapper
+   qobject
diff --git a/docs/devel/qobject.rst b/docs/devel/qobject.rst
new file mode 100644
index 00..4f192ced7c
--- /dev/null
+++ b/docs/devel/qobject.rst
@@ -0,0 +1,11 @@
+QObject API
+===
+
+.. kernel-doc:: include/qapi/qmp/qobject.h
+
+QNum module
+---
+
+.. kernel-doc:: include/qapi/qmp/qnum.h
+
+.. kernel-doc:: qobject/qnum.c
diff --git a/include/qapi/qmp/qnum.h b/include/qapi/qmp/qnum.h
index bbae0a5ec8..25f4733efc 100644
--- a/include/qapi/qmp/qnum.h
+++ b/include/qapi/qmp/qnum.h
@@ -23,7 +23,9 @@ typedef enum {
 QNUM_DOUBLE
 } QNumKind;
 
-/*
+/**
+ * DOC:
+ *
  * QNum encapsulates how our dialect of JSON fills in the blanks left
  * by the JSON specification (RFC 8259) regarding numbers.
  *
diff --git a/include/qapi/qmp/qobject.h b/include/qapi/qmp/qobject.h
index fcfd549220..bdc33bdb65 100644
--- a/include/qapi/qmp/qobject.h
+++ b/include/qapi/qmp/qobject.h
@@ -1,5 +1,5 @@
 /*
- * QEMU Object Model.
+ * QObject API
  *
  * Based on ideas by Avi Kivity 
  *
@@ -10,24 +10,31 @@
  *
  * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
  * See the COPYING.LIB file in the top-level directory.
+ */
+
+/**
+ * DOC: QObject Reference Counts Terminology
  *
- * QObject Reference Counts Terminology
- * 
+ * Returning references
+ * 
  *
- *  - Returning references: A function that returns an object may
- *  return it as either a weak or a strong reference.  If the
- *  reference is strong, you are responsible for calling
- *  qobject_unref() on the reference when you are done.
+ * A function that returns an object may return it as either a
+ * weak or a strong reference.  If the reference is strong, you
+ * are responsible for calling qobject_unref() on the reference
+ * when you are done.
  *
- *  If the reference is weak, the owner of the reference may free it at
- *  any time in the future.  Before storing the reference anywhere, you
- *  should call qobject_ref() to make the reference strong.
+ * If the reference is weak, the owner of the reference may free it at
+ * any time in the future.  Before storing the reference anywhere, you
+ * should call qobject_ref() to make the reference strong.
  *
- *  - Transferring ownership: when you transfer ownership of a reference
- *  by calling a function, you are no longer responsible for calling
- *  qobject_unref() when the reference is no longer needed.  In other words,
- *  when the function returns you must behave as if the reference to the
- *  passed object was weak.
+ * Transferring ownership
+ * --
+ *
+ * When you transfer ownership of a reference by calling a
+ * function, you are no longer responsible for calling
+ * qobject_unref() when the reference is no longer needed.  In
+ * other words, when the function returns you must behave as if
+ * the reference to the passed object was weak.
  */
 #ifndef QOBJECT_H
 #define QOBJECT_H
@@ -81,6 +88,8 @@ static inline void qobject_ref_impl(QObject *obj)
 
 /**
  * qobject_is_equal(): Return whether the two objects are equal.
+ * @x: QObject pointer
+ * @y: QObject pointer
  *
  * Any of the pointers may be NULL; return true if both are.  Always
  * return false if only one is (therefore a QNull object is not
@@ -90,6 +99,7 @@ bool qobject_is_equal(const QObject *x, const QObject *y);
 
 /**
  * qobject_destroy(): Free resources used by the object
+ * @obj: QObject pointer
  */
 void qobject_destroy(QObject *obj);
 
@@ -103,6 +113,7 @@ static inline void qobject_unref_impl(QObject *obj)
 
 /**
  * qobject_ref(): Increment QObject's reference count
+ * @obj: QObject pointer
  *
  * Returns: the same @obj. The type of @obj will be propagated to the
  * return type.
@@ -115,12 +126,14 @@ static inline void qobject_unref_impl(QObject *obj)
 
 /**
  * qobject_unref(): Decrement QObject's reference count, deallocate
- * when it reaches zero
+ *  when it reaches zero
+ * @obj: QObject pointer
  */
 #define qobject_unref(obj) qobject_unref_impl(QOBJECT(obj))
 
 /**
  * qobject_type(): Return the QObject's type
+ * @obj: QObject pointer
  */
 static inline QType qobject_type(const QObject *obj)
 {
@@ -130,6 +143,9 @@ static inline QType qobject_type(const QObject *obj)
 
 /**
  * qobject_check_type(): Helper function for the 

[PATCH 4/8] qnum: qnum_value_is_equal() function

[Eduardo Habkost]

Extract the QNum value comparison logic to a function that takes
QNumValue* as argument.

Signed-off-by: Eduardo Habkost 
---
 include/qapi/qmp/qnum.h |  1 +
 qobject/qnum.c  | 29 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/include/qapi/qmp/qnum.h b/include/qapi/qmp/qnum.h
index 62fbdfda68..0327ecd0f0 100644
--- a/include/qapi/qmp/qnum.h
+++ b/include/qapi/qmp/qnum.h
@@ -106,6 +106,7 @@ double qnum_get_double(const QNum *qn);
 
 char *qnum_to_string(QNum *qn);
 
+bool qnum_value_is_equal(const QNumValue *num_x, const QNumValue *num_y);
 bool qnum_is_equal(const QObject *x, const QObject *y);
 void qnum_destroy_obj(QObject *obj);
 
diff --git a/qobject/qnum.c b/qobject/qnum.c
index f80d4efd76..6a0f948b16 100644
--- a/qobject/qnum.c
+++ b/qobject/qnum.c
@@ -207,9 +207,9 @@ char *qnum_to_string(QNum *qn)
 }
 
 /**
- * qnum_is_equal(): Test whether the two QNums are equal
- * @x: QNum object
- * @y: QNum object
+ * qnum_value_is_equal(): Test whether two QNumValues are equal
+ * @num_x: QNum value
+ * @num_y: QNum value
  *
  * Negative integers are never considered equal to unsigned integers,
  * but positive integers in the range [0, INT64_MAX] are considered
@@ -217,13 +217,8 @@ char *qnum_to_string(QNum *qn)
  *
  * Doubles are never considered equal to integers.
  */
-bool qnum_is_equal(const QObject *x, const QObject *y)
+bool qnum_value_is_equal(const QNumValue *num_x, const QNumValue *num_y)
 {
-const QNum *qnum_x = qobject_to(QNum, x);
-const QNum *qnum_y = qobject_to(QNum, y);
-const QNumValue *num_x = _x->value;
-const QNumValue *num_y = _y->value;
-
 switch (num_x->kind) {
 case QNUM_I64:
 switch (num_y->kind) {
@@ -241,7 +236,7 @@ bool qnum_is_equal(const QObject *x, const QObject *y)
 case QNUM_U64:
 switch (num_y->kind) {
 case QNUM_I64:
-return qnum_is_equal(y, x);
+return qnum_value_is_equal(num_y, num_x);
 case QNUM_U64:
 /* Comparison in native uint64_t type */
 return num_x->u.u64 == num_y->u.u64;
@@ -264,6 +259,20 @@ bool qnum_is_equal(const QObject *x, const QObject *y)
 abort();
 }
 
+/**
+ * qnum_is_equal(): Test whether the two QNums are equal
+ * @x: QNum object
+ * @y: QNum object
+ *
+ * See qnum_value_is_equal() for details on the comparison rules.
+ */
+bool qnum_is_equal(const QObject *x, const QObject *y)
+{
+const QNum *qnum_x = qobject_to(QNum, x);
+const QNum *qnum_y = qobject_to(QNum, y);
+return qnum_value_is_equal(_x->value, _y->value);
+}
+
 /**
  * qnum_destroy_obj(): Free all memory allocated by a QNum object
  *
-- 
2.28.0

[PATCH 3/8] qnum: QNumValue type for QNum value literals

[Eduardo Habkost]

Provide a separate QNumValue type that can be used for QNum value
literals without the referencing counting and memory allocation
features provided by QObject.

Signed-off-by: Eduardo Habkost 
---
 include/qapi/qmp/qnum.h | 40 +++--
 qobject/qnum.c  | 78 -
 2 files changed, 77 insertions(+), 41 deletions(-)

diff --git a/include/qapi/qmp/qnum.h b/include/qapi/qmp/qnum.h
index 55c27b1c24..62fbdfda68 100644
--- a/include/qapi/qmp/qnum.h
+++ b/include/qapi/qmp/qnum.h
@@ -46,20 +46,56 @@ typedef enum {
  * in range: qnum_get_try_int() / qnum_get_try_uint() check range and
  * convert under the hood.
  */
-struct QNum {
-struct QObjectBase_ base;
+
+/**
+ * struct QNumValue: the value of a QNum
+ *
+ * QNumValue literals can be constructed using the `QNUM_VAL_INT`,
+ * `QNUM_VAL_UINT`, and `QNUM_VAL_DOUBLE` macros.
+ */
+typedef struct QNumValue {
+/* private: */
 QNumKind kind;
 union {
 int64_t i64;
 uint64_t u64;
 double dbl;
 } u;
+} QNumValue;
+
+#define QNUM_VAL_INT(value) \
+{ .kind = QNUM_I64, .u.i64 = value }
+#define QNUM_VAL_UINT(value) \
+{ .kind = QNUM_U64, .u.u64 = value }
+#define QNUM_VAL_DOUBLE(value) \
+{ .kind = QNUM_DOUBLE, .u.dbl = value }
+
+struct QNum {
+struct QObjectBase_ base;
+QNumValue value;
 };
 
+/**
+ * qnum_from_int(): Create a new QNum from a QNumValue
+ * @value: QNumValue
+ *
+ * Return strong reference.
+ */
+QNum *qnum_from_value(QNumValue value);
+
 QNum *qnum_from_int(int64_t value);
 QNum *qnum_from_uint(uint64_t value);
 QNum *qnum_from_double(double value);
 
+/**
+ * qnum_get_value(): Get QNumValue from QNum
+ * @qn: QNum object
+ */
+static inline const QNumValue *qnum_get_value(const QNum *qn)
+{
+return >value;
+}
+
 bool qnum_get_try_int(const QNum *qn, int64_t *val);
 int64_t qnum_get_int(const QNum *qn);
 
diff --git a/qobject/qnum.c b/qobject/qnum.c
index 69fd9a82d9..f80d4efd76 100644
--- a/qobject/qnum.c
+++ b/qobject/qnum.c
@@ -15,6 +15,15 @@
 #include "qemu/osdep.h"
 #include "qapi/qmp/qnum.h"
 
+QNum *qnum_from_value(QNumValue value)
+{
+QNum *qn = g_new(QNum, 1);
+
+qobject_init(QOBJECT(qn), QTYPE_QNUM);
+qn->value = value;
+return qn;
+}
+
 /**
  * qnum_from_int(): Create a new QNum from an int64_t
  * @value: int64_t value
@@ -23,13 +32,7 @@
  */
 QNum *qnum_from_int(int64_t value)
 {
-QNum *qn = g_new(QNum, 1);
-
-qobject_init(QOBJECT(qn), QTYPE_QNUM);
-qn->kind = QNUM_I64;
-qn->u.i64 = value;
-
-return qn;
+return qnum_from_value((QNumValue) QNUM_VAL_INT(value));
 }
 
 /**
@@ -40,13 +43,7 @@ QNum *qnum_from_int(int64_t value)
  */
 QNum *qnum_from_uint(uint64_t value)
 {
-QNum *qn = g_new(QNum, 1);
-
-qobject_init(QOBJECT(qn), QTYPE_QNUM);
-qn->kind = QNUM_U64;
-qn->u.u64 = value;
-
-return qn;
+return qnum_from_value((QNumValue) QNUM_VAL_UINT(value));
 }
 
 /**
@@ -57,13 +54,7 @@ QNum *qnum_from_uint(uint64_t value)
  */
 QNum *qnum_from_double(double value)
 {
-QNum *qn = g_new(QNum, 1);
-
-qobject_init(QOBJECT(qn), QTYPE_QNUM);
-qn->kind = QNUM_DOUBLE;
-qn->u.dbl = value;
-
-return qn;
+return qnum_from_value((QNumValue) QNUM_VAL_DOUBLE(value));
 }
 
 /**
@@ -75,15 +66,17 @@ QNum *qnum_from_double(double value)
  */
 bool qnum_get_try_int(const QNum *qn, int64_t *val)
 {
-switch (qn->kind) {
+const QNumValue *qv = >value;
+
+switch (qv->kind) {
 case QNUM_I64:
-*val = qn->u.i64;
+*val = qv->u.i64;
 return true;
 case QNUM_U64:
-if (qn->u.u64 > INT64_MAX) {
+if (qv->u.u64 > INT64_MAX) {
 return false;
 }
-*val = qn->u.u64;
+*val = qv->u.u64;
 return true;
 case QNUM_DOUBLE:
 return false;
@@ -116,15 +109,17 @@ int64_t qnum_get_int(const QNum *qn)
  */
 bool qnum_get_try_uint(const QNum *qn, uint64_t *val)
 {
-switch (qn->kind) {
+const QNumValue *qv = >value;
+
+switch (qv->kind) {
 case QNUM_I64:
-if (qn->u.i64 < 0) {
+if (qv->u.i64 < 0) {
 return false;
 }
-*val = qn->u.i64;
+*val = qv->u.i64;
 return true;
 case QNUM_U64:
-*val = qn->u.u64;
+*val = qv->u.u64;
 return true;
 case QNUM_DOUBLE:
 return false;
@@ -156,13 +151,15 @@ uint64_t qnum_get_uint(const QNum *qn)
  */
 double qnum_get_double(const QNum *qn)
 {
-switch (qn->kind) {
+const QNumValue *qv = >value;
+
+switch (qv->kind) {
 case QNUM_I64:
-return qn->u.i64;
+return qv->u.i64;
 case QNUM_U64:
-return qn->u.u64;
+return qv->u.u64;
 case QNUM_DOUBLE:
-return qn->u.dbl;
+return qv->u.dbl;
 }
 
 assert(0);
@@ -171,14 +168,15 @@ double qnum_get_double(const QNum *qn)
 
 char *qnum_to_string(QNum *qn)
 {
+const QNumValue *qv = >value;
 char *buffer;
 int 

[PATCH 0/8] qom: Use qlit to represent property defaults

[Eduardo Habkost]

Based-on: 20201104160021.2342108-1-ehabk...@redhat.com
Git branch: https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-qlit-defaults

This extend qlit.h to support all QNum types (signed int,
unsigned int, and double), and use QLitObject to represent field
property defaults.

It allows us to get rid of most type-specific .set_default_value
functions for QOM property types.

Eduardo Habkost (8):
  qobject: Include API docs in docs/devel/qobject.html
  qnum: Make qnum_get_double() get const pointer
  qnum: QNumValue type for QNum value literals
  qnum: qnum_value_is_equal() function
  qlit: Support all types of QNums
  qlit: qlit_type() function
  qom: Make object_property_set_default() public
  qom: Use qlit to represent property defaults

 docs/devel/index.rst  |   1 +
 docs/devel/qobject.rst|  11 +++
 include/hw/qdev-properties-system.h   |   2 +-
 include/qapi/qmp/qlit.h   |  16 +++-
 include/qapi/qmp/qnum.h   |  47 ++-
 include/qapi/qmp/qobject.h|  48 +++
 include/qom/field-property-internal.h |   4 -
 include/qom/field-property.h  |  26 +++---
 include/qom/object.h  |  11 +++
 include/qom/property-types.h  |  21 ++---
 hw/core/qdev-properties-system.c  |   8 --
 qobject/qlit.c|   4 +-
 qobject/qnum.c| 116 +++---
 qom/field-property.c  |  27 --
 qom/object.c  |   2 +-
 qom/property-types.c  |  36 ++--
 tests/check-qjson.c   |  72 ++--
 17 files changed, 295 insertions(+), 157 deletions(-)
 create mode 100644 docs/devel/qobject.rst

-- 
2.28.0

[Bug 1706296] Re: Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())

[Peter Maydell]

With the original repro command line, the guest now crashes "cleanly",
ie without triggering a QEMU assert. If you give the guest a CPU type it
recognizes, eg '-cpu pentium' (as noted in comment 7) then it boots OK,
at least to the point of user control in the installer. So I think this
is fixed.


** Changed in: qemu
   Status: Incomplete => 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/1706296

Title:
  Booting NT 4 disk causes
  /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion
  failed: (!qemu_mutex_iothread_locked())

Status in QEMU:
  Fix Released

Bug description:
  Grab the NT 4 disk from
  https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_227-075
  -385_CD-KEY_419-1343253_1996

  Try to boot it as follows:

  qemu-system-x86_64 -hda disk.img -cdrom 
Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996.iso 
-m 2048 -boot d -machine pc,accel=tcg
  WARNING: Image format was not specified for 'disk.img' and probing guessed 
raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.
  **
  ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion 
failed: (!qemu_mutex_iothread_locked())
  Aborted (core dumped)

  The stack trace in the failing thread is:

  Thread 4 (Thread 0x7fffb0418700 (LWP 21979)):
  #0  0x7fffdd89b64b in raise () at /lib64/libc.so.6
  #1  0x7fffdd89d450 in abort () at /lib64/libc.so.6
  #2  0x7fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0
  #3  0x7fffdff8c7ea in g_assertion_message_expr ()
  at /lib64/libglib-2.0.so.0
  #4  0x557a7d00 in qemu_mutex_lock_iothread ()
  at /home/rjones/d/qemu/cpus.c:1580
  #5  0x557cb429 in io_writex (env=env@entry=0x56751400, 
iotlbentry=0x5675b678, 
  iotlbentry@entry=0x5ae40c918, val=val@entry=8, 
addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, 
size=size@entry=4)
  at /home/rjones/d/qemu/accel/tcg/cputlb.c:795
  #6  0x557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, 
val=8, index=255, mmu_idx=21845, env=0x56751400)
  at /home/rjones/d/qemu/softmmu_template.h:265
  #7  0x557ce0f7 in helper_le_stl_mmu (env=env@entry=0x56751400, 
addr=addr@entry=2148532220, val=val@entry=8, oi=, 
retaddr=93825011136120, retaddr@entry=0) at 
/home/rjones/d/qemu/softmmu_template.h:300
  #8  0x5587c0a4 in cpu_stl_kernel_ra (env=0x56751400, 
ptr=2148532220, v=8, retaddr=0) at 
/home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182
  #9  0x55882610 in do_interrupt_protected (is_hw=, 
next_eip=, error_code=2, is_int=, 
intno=, env=0x56751400) at 
/home/rjones/d/qemu/target/i386/seg_helper.c:758
  #10 0x55882610 in do_interrupt_all (cpu=cpu@entry=0x56749170, 
intno=, is_int=, error_code=2, 
next_eip=, is_hw=is_hw@entry=0) at 
/home/rjones/d/qemu/target/i386/seg_helper.c:1252
  #11 0x558839d3 in x86_cpu_do_interrupt (cs=0x56749170)
  at /home/rjones/d/qemu/target/i386/seg_helper.c:1298
  #12 0x557d2ccb in cpu_handle_exception (ret=, 
cpu=0x566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465
  #13 0x557d2ccb in cpu_exec (cpu=cpu@entry=0x56749170)
  at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670
  #14 0x557a855a in tcg_cpu_exec (cpu=0x56749170)
  at /home/rjones/d/qemu/cpus.c:1270
  #15 0x557a855a in qemu_tcg_rr_cpu_thread_fn (arg=)
  at /home/rjones/d/qemu/cpus.c:1365
  #16 0x7fffddc3d36d in start_thread () at /lib64/libpthread.so.0
  #17 0x7fffdd975b9f in clone () at /lib64/libc.so.6

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

Re: [PULL for-5.2 0/1] qemu-ga patch queue for hard-freeze

[Peter Maydell]

On Mon, 9 Nov 2020 at 20:18, Michael Roth  wrote:
>
> The following changes since commit 3493c36f0371777c62d1d72b205b0eb6117e2156:
>
>   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201106' into 
> staging (2020-11-06 13:43:28 +)
>
> are available in the Git repository at:
>
>   git://github.com/mdroth/qemu.git tags/qga-pull-2020-11-09-tag
>
> for you to fetch changes up to b1b9ab1c04d560f86d8da3dfca4d8b21de75fee6:
>
>   qga: fix missing closedir() in qmp_guest_get_disks() (2020-11-09 14:07:14 
> -0600)
>
> 
> qemu-ga patch queue for hard-freeze
>
> * fix leaked DIR* descriptor in guest-get-disks spotted by coverity
>
> 

Applied, thanks.

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

-- PMM

Re: [PATCH v2 6/6] qemu-option: warn for short-form boolean options

[Markus Armbruster]

Paolo Bonzini  writes:

> Options such as "server" or "nowait", that are commonly found in -chardev,
> are sugar for "server=on" and "wait=off".  This is quite surprising and
> also does not have any notion of typing attached.  It is even possible to
> do "-device e1000,noid" and get a device with "id=off".
>
> Deprecate it and print a warning when it is encountered.  In general,
> this short form for boolean options only seems to be in wide use for
> -chardev and -spice.
>
> The extra boolean argument is not my favorite.  In 6.0 I plan to remove
> qemu_opts_set_defaults by switching -M to keyval, and therefore quite
> a bit of QemuOpts code will go away.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  docs/system/deprecated.rst |  6 ++
>  tests/test-qemu-opts.c |  2 +-
>  util/qemu-option.c | 29 ++---
>  3 files changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 8c1dc7645d..f45938a5ff 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -146,6 +146,12 @@ Drives with interface types other than ``if=none`` are 
> for onboard
>  devices.  It is possible to use drives the board doesn't pick up with
>  -device.  This usage is now deprecated.  Use ``if=none`` instead.
>  
> +Short-form boolean options (since 5.2)
> +''
> +
> +Boolean options such as ``share=on``/``share=off`` can be written
> +in short form as ``share`` and ``noshare``.  This is deprecated
> +and will cause a warning.
>  
>  QEMU Machine Protocol (QMP) commands
>  
> diff --git a/tests/test-qemu-opts.c b/tests/test-qemu-opts.c
> index 322b32871b..e12fb51032 100644
> --- a/tests/test-qemu-opts.c
> +++ b/tests/test-qemu-opts.c
> @@ -519,7 +519,7 @@ static void test_opts_parse(void)
>  error_free_or_abort();
>  g_assert(!opts);
>  
> -/* Implied value */
> +/* Implied value (qemu_opts_parse does not warn) */
>  opts = qemu_opts_parse(_list_03, "an,noaus,noaus=",
> false, _abort);
>  g_assert_cmpuint(opts_count(opts), ==, 3);
> diff --git a/util/qemu-option.c b/util/qemu-option.c
> index 0ddf1f7b45..23238f00ea 100644
> --- a/util/qemu-option.c
> +++ b/util/qemu-option.c
> @@ -756,10 +756,12 @@ void qemu_opts_print(QemuOpts *opts, const char 
> *separator)
>  
>  static const char *get_opt_name_value(const char *params,
>const char *firstname,
> +  bool warn_on_flag,
>bool *help_wanted,
>char **name, char **value)
>  {
>  const char *p;
> +const char *prefix = "";
>  size_t len;
>  bool is_help = false;
>  
> @@ -776,10 +778,15 @@ static const char *get_opt_name_value(const char 
> *params,
>  if (strncmp(*name, "no", 2) == 0) {
>  memmove(*name, *name + 2, strlen(*name + 2) + 1);
>  *value = g_strdup("off");
> +prefix = "no";
>  } else {
>  *value = g_strdup("on");
>  is_help = is_help_option(*name);
>  }
> +if (!is_help && warn_on_flag) {
> +warn_report("short-form boolean option '%s%s' deprecated", 
> prefix, *name);
> +error_printf("Please use %s=%s instead\n", *name, *value);
> +}

If @warn_on_flag, we warn except for "help" and "?".  The exception
applies regardless of @help_wanted.

>  }
>  } else {
>  /* found "foo=bar,more" */
> @@ -801,14 +808,14 @@ static const char *get_opt_name_value(const char 
> *params,
>  
>  static bool opts_do_parse(QemuOpts *opts, const char *params,
>const char *firstname, bool prepend,
> -  bool *help_wanted, Error **errp)
> +  bool warn_on_flag, bool *help_wanted, Error **errp)
>  {
>  char *option, *value;
>  const char *p;
>  QemuOpt *opt;
>  
>  for (p = params; *p;) {
> -p = get_opt_name_value(p, firstname, help_wanted, , );
> +p = get_opt_name_value(p, firstname, warn_on_flag, help_wanted, 
> , );

Long line.  Break it before the three output arguments.

>  if (help_wanted && *help_wanted) {
>  return false;
>  }
> @@ -837,7 +844,7 @@ static char *opts_parse_id(const char *params)
>  char *name, *value;
>  
>  for (p = params; *p;) {
> -p = get_opt_name_value(p, NULL, NULL, , );
> +p = get_opt_name_value(p, NULL, false, NULL, , );

No change (we pass false to warn_on_flag).

>  if (!strcmp(name, "id")) {
>  g_free(name);
>  return value;
> @@ -856,7 +863,7 @@ bool has_help_option(const char *params)
>  bool ret;
>  
>  for (p = params; *p;) {
> -p = get_opt_name_value(p, NULL, , , );
> + 

Re: [PATCH-for-6.0 v4 05/17] gitlab-ci: Split CONFIGURE_ARGS one argument per line for build-disabled

[Wainer dos Santos Moschetta]

On 11/8/20 6:45 PM, Philippe Mathieu-Daudé wrote:

We will keep adding/removing options to our 'configure' script,
so for easier maintainability it makes sense to have CONFIGURE_ARGS
declared as one option per line. This way we can review diff easily
(or rebase/cherry-pick).

No logical change.

Signed-off-by: Philippe Mathieu-Daudé 
---
Cc: Daniel P . Berrange 
---
  .gitlab-ci.yml | 80 +++---
  1 file changed, 63 insertions(+), 17 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3b15ae5c302..9f090cca5e3 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -203,23 +203,69 @@ build-disabled:
<<: *native_build_job_definition
variables:
  IMAGE: fedora
-CONFIGURE_ARGS: --disable-attr --disable-avx2 --disable-bochs
-  --disable-brlapi --disable-bzip2 --disable-cap-ng --disable-capstone
-  --disable-cloop --disable-coroutine-pool --disable-curl --disable-curses
-  --disable-dmg --disable-docs --disable-glusterfs --disable-gnutls
-  --disable-gtk --disable-guest-agent --disable-iconv --disable-kvm
-  --disable-libiscsi --disable-libpmem --disable-libssh --disable-libusb
-  --disable-libxml2 --disable-linux-aio --disable-live-block-migration
-  --disable-lzo --disable-malloc-trim --disable-mpath --disable-nettle
-  --disable-numa --disable-parallels --disable-pie --disable-qcow1
-  --disable-qed --disable-qom-cast-debug --disable-rbd --disable-rdma
-  --disable-replication --disable-sdl --disable-seccomp --disable-sheepdog
-  --disable-slirp --disable-smartcard --disable-snappy --disable-spice
-  --disable-strip --disable-tpm --disable-usb-redir --disable-vdi
-  --disable-vhost-crypto --disable-vhost-net --disable-vhost-scsi
-  --disable-vhost-user --disable-vhost-vdpa --disable-vhost-vsock
-  --disable-virglrenderer --disable-vnc --disable-vte --disable-vvfat
-  --disable-xen --disable-zstd
+CONFIGURE_ARGS:


I suggest to use '>-' like 'CONFIGURE_ARGS: >-'. It's up to you.

Reviewed-by: Wainer dos Santos Moschetta 


+  --disable-attr
+  --disable-avx2
+  --disable-bochs
+  --disable-brlapi
+  --disable-bzip2
+  --disable-cap-ng
+  --disable-capstone
+  --disable-cloop
+  --disable-coroutine-pool
+  --disable-curl
+  --disable-curses
+  --disable-dmg
+  --disable-docs
+  --disable-glusterfs
+  --disable-gnutls
+  --disable-gtk
+  --disable-guest-agent
+  --disable-iconv
+  --disable-kvm
+  --disable-libiscsi
+  --disable-libpmem
+  --disable-libssh
+  --disable-libusb
+  --disable-libxml2
+  --disable-linux-aio
+  --disable-live-block-migration
+  --disable-lzo
+  --disable-malloc-trim
+  --disable-mpath
+  --disable-nettle
+  --disable-numa
+  --disable-parallels
+  --disable-pie
+  --disable-qcow1
+  --disable-qed
+  --disable-qom-cast-debug
+  --disable-rbd
+  --disable-rdma
+  --disable-replication
+  --disable-sdl
+  --disable-seccomp
+  --disable-sheepdog
+  --disable-slirp
+  --disable-smartcard
+  --disable-snappy
+  --disable-spice
+  --disable-strip
+  --disable-tpm
+  --disable-usb-redir
+  --disable-vdi
+  --disable-vhost-crypto
+  --disable-vhost-net
+  --disable-vhost-scsi
+  --disable-vhost-user
+  --disable-vhost-vdpa
+  --disable-vhost-vsock
+  --disable-virglrenderer
+  --disable-vnc
+  --disable-vte
+  --disable-vvfat
+  --disable-xen
+  --disable-zstd
  TARGETS: arm-softmmu i386-softmmu ppc64-softmmu mips64-softmmu
s390x-softmmu i386-linux-user
  MAKE_CHECK_ARGS: check-qtest SPEED=slow

[PULL for-5.2 0/1] qemu-ga patch queue for hard-freeze

[Michael Roth]

The following changes since commit 3493c36f0371777c62d1d72b205b0eb6117e2156:

  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201106' into 
staging (2020-11-06 13:43:28 +)

are available in the Git repository at:

  git://github.com/mdroth/qemu.git tags/qga-pull-2020-11-09-tag

for you to fetch changes up to b1b9ab1c04d560f86d8da3dfca4d8b21de75fee6:

  qga: fix missing closedir() in qmp_guest_get_disks() (2020-11-09 14:07:14 
-0600)


qemu-ga patch queue for hard-freeze

* fix leaked DIR* descriptor in guest-get-disks spotted by coverity


Michael Roth (1):
  qga: fix missing closedir() in qmp_guest_get_disks()

 qga/commands-posix.c | 3 +++
 1 file changed, 3 insertions(+)

Re: [RFC PATCH for-QEMU-5.2] vfio: Make migration support experimental

[Alex Williamson]

On Mon, 9 Nov 2020 19:44:17 +
"Dr. David Alan Gilbert"  wrote:

> * Alex Williamson (alex.william...@redhat.com) wrote:
> > Per the proposed documentation for vfio device migration:
> > 
> >   Dirty pages are tracked when device is in stop-and-copy phase
> >   because if pages are marked dirty during pre-copy phase and
> >   content is transfered from source to destination, there is no
> >   way to know newly dirtied pages from the point they were copied
> >   earlier until device stops. To avoid repeated copy of same
> >   content, pinned pages are marked dirty only during
> >   stop-and-copy phase.
> > 
> > Essentially, since we don't have hardware dirty page tracking for
> > assigned devices at this point, we consider any page that is pinned
> > by an mdev vendor driver or pinned and mapped through the IOMMU to
> > be perpetually dirty.  In the worst case, this may result in all of
> > guest memory being considered dirty during every iteration of live
> > migration.  The current vfio implementation of migration has chosen
> > to mask device dirtied pages until the final stages of migration in
> > order to avoid this worst case scenario.
> > 
> > Allowing the device to implement a policy decision to prioritize
> > reduced migration data like this jeopardizes QEMU's overall ability
> > to implement any degree of service level guarantees during migration.
> > For example, any estimates towards achieving acceptable downtime
> > margins cannot be trusted when such a device is present.  The vfio
> > device should participate in dirty page tracking to the best of its
> > ability throughout migration, even if that means the dirty footprint
> > of the device impedes migration progress, allowing both QEMU and
> > higher level management tools to decide whether to continue the
> > migration or abort due to failure to achieve the desired behavior.  
> 
> I don't feel particularly badly about the decision to squash it in
> during the stop-and-copy phase; for devices where the pinned memory
> is large, I don't think doing it during the main phase makes much sense;
> especially if you then have to deal with tracking changes in pinning.


AFAIK the kernel support for tracking changes in page pinning already
exists, this is largely the vfio device in QEMU that decides when to
start exposing the device dirty footprint to QEMU.  I'm a bit surprised
by this answer though, we don't really know what the device memory
footprint is.  It might be large, it might be nothing, but by not
participating in dirty page tracking until the VM is stopped, we can't
know what the footprint is and how it will affect downtime.  Is it
really the place of a QEMU device driver to impose this sort of policy?


> Having said that, I agree with marking it as experimental, because
> I'm dubious how useful it will be for the same reason, I worry
> about whether the downtime will be so large to make it pointless.


TBH I think that's the wrong reason to mark it experimental.  There's
clearly demand for vfio device migration and even if the practical use
cases are initially small, they will expand over time and hardware will
get better.  My objection is that the current behavior masks the
hardware and device limitations, leading to unrealistic expectations.
If the user expects minimal downtime, configures convergence to account
for that, QEMU thinks it can achieve it, and then the device marks
everything dirty, that's not supportable.  OTOH if the vfio device
participates in dirty tracking through pre-copy, then the practical use
cases will find themselves as migrations will either be aborted because
downtime tolerances cannot be achieved or downtimes will be configured
to match reality.  Thanks,

Alex

> Reviewed-by: Dr. David Alan Gilbert 
> 
> > Link: https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg00807.html
> > Cc: Kirti Wankhede 
> > Cc: Neo Jia 
> > Cc: Dr. David Alan Gilbert 
> > Cc: Juan Quintela 
> > Cc: Philippe Mathieu-Daudé 
> > Cc: Cornelia Huck 
> > Signed-off-by: Alex Williamson 
> > ---
> > 
> > Given that our discussion in the link above seems to be going in
> > circles, I'm afraid it seems necessary to both have a contigency
> > plan and to raise the visibility of the current behavior to
> > determine whether others agree that this is a sufficiently
> > troubling behavior to consider migration support experimental
> > at this stage.  Please voice your opinion or contribute patches
> > to resolve this before QEMU 5.2.  Thanks,
> > 
> > Alex
> > 
> >  hw/vfio/migration.c   |2 +-
> >  hw/vfio/pci.c |2 ++
> >  include/hw/vfio/vfio-common.h |1 +
> >  3 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> > index 3ce285ea395d..cd44d465a50b 100644
> > --- a/hw/vfio/migration.c
> > +++ b/hw/vfio/migration.c
> > @@ -882,7 +882,7 @@ int vfio_migration_probe(VFIODevice *vbasedev, Error 
> > **errp)
> >  Error *local_err = NULL;
> >  

Re: [PATCH v2 00/44] Make qdev static property API usable by any QOM type

[Eduardo Habkost]

On Mon, Nov 09, 2020 at 08:27:21PM +0100, Paolo Bonzini wrote:
> On 09/11/20 19:55, Eduardo Habkost wrote:
> > On Mon, Nov 09, 2020 at 06:33:04PM +0100, Paolo Bonzini wrote:
> > > On 09/11/20 18:16, Eduardo Habkost wrote:
> > > > I mean extending the API to let custom setters and getters appear
> > > > on the Property array, not using the existing API.
> > > 
> > > That seems like conflicting goals.  The field property API is based on
> > > getters and setters hidden in PropertyInfo.  The "other" property API is
> > > based on getters and setters in plain sight in the declaration of the
> > > property.
> > 
> > There's nothing that prevents a
> >void object_class_add_properties(oc, Property *props);
> > function from supporting both.
> 
> Sorry but I don't believe this until I see it.  The two APIs are just too
> different.  And at some point the complexity of DEFINE_PROP becomes:
> 
> 1) harder to document
> 
> 2) just as hard to parse and build a QAPI schema from
> 
> And in the final desired result where QAPI generators are what generates the
> list of properties, it's pointless to shoehorn both kinds of properties in
> the same array if different things can just generate calls to different
> functions.
> 
> > > > Parsing an array containing a handful of macros (a tiny subset of
> > > > C) isn't even comparable to parsing and executing C code where
> > > > object*_property_add*() calls can be buried deep in many levels
> > > > of C function calls (which may or may not be conditional).
> > > 
> > > Finding the array would also require finding calls buried deep in C code,
> > > wouldn't they?
> > 
> > Yes, but I don't expect this to happen if the API doesn't
> > encourage that.
> 
> Out of 700 calls to object_class_property_add*, there are maybe 5 that are
> dynamic.  So on one hand I understand why you want an API that makes those
> things harder, but on the other hand I don't see such a big risk of misuse,
> and it won't even matter at all if we later end up with properties described
> in a QAPI schema.
> 
> > > > (Also, I don't think we should allow handwritten Property literals.)
> > > 
> > > How would you do custom setters and getters then---without separate
> > > PropertyInfos, without Property literals, and without an exploding number 
> > > of
> > > macros?
> > 
> > Prop with no struct field, and custom setter/getter:
> > 
> >DEFINE_PROP("myproperty", prop_type_uint32,
> >.custom_getter = my_getter,
> >.custom_setter = my_setter)
> 
> It would have to use all the Visitor crap and would be even harder to use
> than object_class_property_add_str.  Thanks but no thanks. :)

Point taken, I dislike the visitor API too.

> 
> > > > we can't be sure the [set of QOM properties]
> > > > doesn't depend on configure flags or run time
> > > > checks inside class_init.
> > > 
> > > We can use grep or Coccinelle or manual code review to identify 
> > > problematic
> > > cases.
> > 
> > We can, but I believe it is better and simpler to have an API
> > that enforces (or at least encourages) this.
> 
> I don't see how
> 
> if (...) {
> object_class_add_field_properties(oc, props);
> }
> 
> is discouraged any more than
> 
> if (...) {
> object_class_add_field_property(oc, "prop1",
> PROP_STRING(...));
> object_class_add_field_property(oc, "prop2",
> PROP_STRING(...));
> object_class_add_field_property(oc, "prop3",
> PROP_STRING(...));
> object_class_add_field_property(oc, "prop4",
> PROP_STRING(...));
> }
> 
> (If anything, the former is more natural and less ugly than the latter).

On the former, "adding a new property" means adding an entry to a
const array.  On the latter, it means adding a new function call.

On the former, a conditional property would require defining a
new array.  A non-constant property name or type would require
making the array non-const and modifying it at runtime.

On the latter, adding a if statement on the front of that
function call or a non-constant expression as argument to the
function is trivial.

> 
> > I'd like us to convert instance-level properties to an API that
> > is easy to use and where the same problems won't happen again.
> 
> I agree.  I just don't think that arrays are enough to make sure the same
> problems won't happen again.
> 
> > > > You are also ignoring the complexity of the code path that leads
> > > > to the object*_property_add*() calls, which is the main problem
> > > > on most cases.
> > > 
> > > I would like an example of the complexity of those code paths.  I don't 
> > > see
> > > much complexity, as long as the object exists at all, and I don't see how 
> > > it
> > > would be simpler to find the code paths that lead to
> > > object_class_add_field_properties.
> > 
> > Possibly the most complex case 

[PULL for-5.2 1/1] qga: fix missing closedir() in qmp_guest_get_disks()

[Michael Roth]

We opendir("/sys/block") at the beginning of the function, but we never
close it prior to returning.

Fixes: Coverity CID 1436130
Fixes: fed3956429d5 ("qga: add implementation of guest-get-disks for Linux")
Reported-by: Peter Maydell 
Cc: Marc-André Lureau 
Cc: Tomáš Golembiovský 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Michael Roth 
---
 qga/commands-posix.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 3711080d07..12c1ba5ef7 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -1443,6 +1443,9 @@ GuestDiskInfoList *qmp_guest_get_disks(Error **errp)
 get_disk_deps(disk_dir, disk);
 ret = get_disk_partitions(ret, de->d_name, disk_dir, dev_name);
 }
+
+closedir(dp);
+
 return ret;
 }
 
-- 
2.25.1

[Bug 1734474] Re: Maemo does not boot on emulated N800

[MVoloshin]

It's available here: https://4pda.ru/forum/index.php?showtopic=870847

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

Title:
  Maemo does not boot on emulated N800

Status in QEMU:
  New

Bug description:
  I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock 
maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2"
  On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and 
newer (including latest versions) I see only white screen and no signs of life. 
Was this caused by regression or any syntax change?

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

Re: [PULL v2 00/15] Block patches for 5.2.0-rc1

[Peter Maydell]

On Mon, 9 Nov 2020 at 17:50, Max Reitz  wrote:
>
> The following changes since commit 2a190a7256a3e0563b29ffd67e0164097b4a6dac:
>
>   Merge remote-tracking branch 
> 'remotes/philmd-gitlab/tags/renesas-fixes-20201109' into staging (2020-11-09 
> 11:20:25 +)
>
> are available in the Git repository at:
>
>   https://github.com/XanClic/qemu.git tags/pull-block-2020-11-09-v2
>
> for you to fetch changes up to d669ed6ab028497d634e1f236c74a98725f9e45f:
>
>   block: make bdrv_drop_intermediate() less wrong (2020-11-09 18:43:31 +0100)
>
> 
> Block patches for 5.2.0-rc1:
> - Some nvme fixes (addressing problems spotted by Coverity)
> - Fix nfs compiling on mingw (and enable it in Cirrus)
> - Fix an error path in bdrv_co_invalidate_cache() (permission update
>   was initiated, but not aborted)
> - Fix (on-error) roll back in bdrv_drop_intermediate(): Instead of
>   inlining bdrv_replace_node() (wrongly), call that function
> - Fix for iotest 240
> - Fix error handling in bdrv_getlength()
> - Be more explicit about how QCowL2Meta objects are handled
> - Cleanups
>
> 
> v2:
> - Added missing Message-Id and Signed-off-by to patch 12


Applied, thanks.

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

-- PMM

[Bug 1706296] Re: Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())

[Peter Maydell]

commit 8b81253332b5a3f claims in its subject line that it "fixes
#1706296", and it implements Paolo's option (2) from comment #4. So I'd
go with "already fixed". The bug has a simple reproducer in the report
though, so it's also easy to test...

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

Title:
  Booting NT 4 disk causes
  /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion
  failed: (!qemu_mutex_iothread_locked())

Status in QEMU:
  Incomplete

Bug description:
  Grab the NT 4 disk from
  https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_227-075
  -385_CD-KEY_419-1343253_1996

  Try to boot it as follows:

  qemu-system-x86_64 -hda disk.img -cdrom 
Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996.iso 
-m 2048 -boot d -machine pc,accel=tcg
  WARNING: Image format was not specified for 'disk.img' and probing guessed 
raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.
  **
  ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion 
failed: (!qemu_mutex_iothread_locked())
  Aborted (core dumped)

  The stack trace in the failing thread is:

  Thread 4 (Thread 0x7fffb0418700 (LWP 21979)):
  #0  0x7fffdd89b64b in raise () at /lib64/libc.so.6
  #1  0x7fffdd89d450 in abort () at /lib64/libc.so.6
  #2  0x7fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0
  #3  0x7fffdff8c7ea in g_assertion_message_expr ()
  at /lib64/libglib-2.0.so.0
  #4  0x557a7d00 in qemu_mutex_lock_iothread ()
  at /home/rjones/d/qemu/cpus.c:1580
  #5  0x557cb429 in io_writex (env=env@entry=0x56751400, 
iotlbentry=0x5675b678, 
  iotlbentry@entry=0x5ae40c918, val=val@entry=8, 
addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, 
size=size@entry=4)
  at /home/rjones/d/qemu/accel/tcg/cputlb.c:795
  #6  0x557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, 
val=8, index=255, mmu_idx=21845, env=0x56751400)
  at /home/rjones/d/qemu/softmmu_template.h:265
  #7  0x557ce0f7 in helper_le_stl_mmu (env=env@entry=0x56751400, 
addr=addr@entry=2148532220, val=val@entry=8, oi=, 
retaddr=93825011136120, retaddr@entry=0) at 
/home/rjones/d/qemu/softmmu_template.h:300
  #8  0x5587c0a4 in cpu_stl_kernel_ra (env=0x56751400, 
ptr=2148532220, v=8, retaddr=0) at 
/home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182
  #9  0x55882610 in do_interrupt_protected (is_hw=, 
next_eip=, error_code=2, is_int=, 
intno=, env=0x56751400) at 
/home/rjones/d/qemu/target/i386/seg_helper.c:758
  #10 0x55882610 in do_interrupt_all (cpu=cpu@entry=0x56749170, 
intno=, is_int=, error_code=2, 
next_eip=, is_hw=is_hw@entry=0) at 
/home/rjones/d/qemu/target/i386/seg_helper.c:1252
  #11 0x558839d3 in x86_cpu_do_interrupt (cs=0x56749170)
  at /home/rjones/d/qemu/target/i386/seg_helper.c:1298
  #12 0x557d2ccb in cpu_handle_exception (ret=, 
cpu=0x566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465
  #13 0x557d2ccb in cpu_exec (cpu=cpu@entry=0x56749170)
  at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670
  #14 0x557a855a in tcg_cpu_exec (cpu=0x56749170)
  at /home/rjones/d/qemu/cpus.c:1270
  #15 0x557a855a in qemu_tcg_rr_cpu_thread_fn (arg=)
  at /home/rjones/d/qemu/cpus.c:1365
  #16 0x7fffddc3d36d in start_thread () at /lib64/libpthread.so.0
  #17 0x7fffdd975b9f in clone () at /lib64/libc.so.6

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