Re: [PATCH 5/6] co-shared-resource: protect with a mutex

[Vladimir Sementsov-Ogievskiy via]

15.05.2021 00:53, Emanuele Giuseppe Esposito wrote:



we want to get from shres here, after possible call to block_copy_task_shrink(), 
as task->bytes may be reduced.


Ah right, I missed that. So I guess if we want the caller to protect 
co-shared-resource, get_from_shres stays where it is, and put_ instead can 
still go into task_end (with a boolean enabling it).


honestly, I don't follow how it helps thread-safety


 From my understanding, the whole point here is to have no lock in 
co-shared-resource but let the caller take care of it (block-copy).

The above was just an idea on how to do it.


But how moving co_put_to_shres() make it thread-safe? Nothing in block-copy is 
thread-safe yet..


Sorry this is my bad, I did not explain it properly. If you look closely at the diff I 
sent, there are locks in a similar way of my block-copy initial patch. So I am 
essentially assuming that block-copy has already locks, and moving co_put_to_shres in 
block_copy_task_end has the purpose of moving shres "in a function that has a 
critical section".



Hm. Understand now. If you go this way, I'd better add a critical section and 
keep shres operations where they are now. We don't have shres operation in task 
creation, so should not have in task finalization. Shres operations are kept in 
seperate. It probably not bad to refactor it to make shres operations as a part 
of task manipulation functions, but it would require more accurate refactoring, 
simpler is to keep it as is.


--
Best regards,
Vladimir

[RFC PATCH v3] ppc/spapr: Add support for H_SCM_PERFORMANCE_STATS hcall

[Vaibhav Jain]

Add support for H_SCM_PERFORMANCE_STATS described at [1] for
spapr nvdimms. This enables guest to fetch performance stats[2] like
expected life of an nvdimm ('MemLife ') etc and display them to the
user. Linux kernel support for fetching these performance stats and
exposing them to the user-space was done via [3].

The hcall semantics mandate that each nvdimm performance stats is
uniquely identied by a 8-byte ascii string encoded as an unsigned
integer (e.g 'MemLife ' == 0x4D656D4C69666520) and its value be a
8-byte unsigned integer. These performance-stats are exchanged with
the guest in via a guest allocated buffer called
'requestAndResultBuffer' or rr-buffer for short. This buffer contains
a header descibed by 'struct papr_scm_perf_stats' followed by an array
of performance-stats described by 'struct papr_scm_perf_stat'. The
hypervisor is expected to validate the rr-buffer header and then based
on the request copy the needed performance-stats to the array of
'struct papr_scm_perf_stat' following the header.

The patch proposes a new function h_scm_performance_stats() that
services the H_SCM_PERFORMANCE_STATS hcall. After verifying the
validity of the rr-buffer header via scm_perf_check_rr_buffer() it
proceeds to fill the rr-buffer with requested performance-stats. The
value of individual stats is retrived from individual accessor
function for the stat which are indexed in the array
'nvdimm_perf_stats'.

References:
[1] "Hypercall Op-codes (hcalls)"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/powerpc/papr_hcalls.rst#n269
[2] Sysfs attribute documentation for papr_scm
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-papr-pmem#n36
[3] "powerpc/papr_scm: Fetch nvdimm performance stats from PHYP"
https://lore.kernel.org/r/20200731064153.182203-2-vaib...@linux.ibm.com

Signed-off-by: Vaibhav Jain 
---
Changelog

Since RFC-v2:
* s/SCM_STATS_MAX_OUTPUT_BUFFER/SCM_STATS_MIN_OUTPUT_BUFFER/ thats the
  minimum size buffer needed to return all supported performance
  stats. Value for this is derived from size of array 'nvdimm_perf_stats'
* Added SCM_STATS_MAX_OUTPUT_BUFFER to indicate maximum supported
  rr-buffer size from a guest. Value for this is derived from hard
  limit of SCM_STATS_MAX_STATS.
* Updated scm_perf_check_rr_buffer() to add a check for max size of
  rr-buffer. [David]
* Updated scm_perf_check_rr_buffer() to removed a reduntant check for
  min size of rr-buffer [David]
* Updated h_scm_performance_stats() to have a single allocation for
  rr-buffer and copy it back to guest memory in a single shot. [David]

Since RFC-v1:
* Removed empty lines from code [ David ]
* Updated struct papr_scm_perf_stat to use uint64_t for
  statistic_id.
* Added a hard limit on max number of stats requested to 255 [ David ]
* Updated scm_perf_check_rr_buffer() to check for rr-buffer header
  size [ David ]
* Removed a redundant check from nvdimm_stat_getval() [ David ]
* Removed a redundant call to address_space_access_valid() in
  scm_perf_check_rr_buffer() [ David ]
* Instead of allocating a minimum size local buffer, allocate a max
  possible size local rr-buffer. [ David ]
* Updated nvdimm_stat_getval() to set 'val' to '0' on error. [ David ]
* Updated h_scm_performance_stats() to use a canned-response method
  for simplifying num_stats==0 case [ David ].
---
 hw/ppc/spapr_nvdimm.c  | 222 +
 include/hw/ppc/spapr.h |  19 +++-
 2 files changed, 240 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index 252204e25f..287326b9c0 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -35,6 +35,19 @@
 /* SCM device is unable to persist memory contents */
 #define PAPR_PMEM_UNARMED PPC_BIT(0)
 
+/* Minimum output buffer size needed to return all nvdimm_perf_stats */
+#define SCM_STATS_MIN_OUTPUT_BUFFER  (sizeof(struct papr_scm_perf_stats) + \
+  sizeof(struct papr_scm_perf_stat) * \
+  ARRAY_SIZE(nvdimm_perf_stats))
+
+/* Maximum number of stats that we can return back in a single stat request */
+#define SCM_STATS_MAX_STATS 255
+
+/* Maximum possible output buffer to fulfill a perf-stats request */
+#define SCM_STATS_MAX_OUTPUT_BUFFER  (sizeof(struct papr_scm_perf_stats) + \
+  sizeof(struct papr_scm_perf_stat) * \
+  SCM_STATS_MAX_STATS)
+
 bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm,
uint64_t size, Error **errp)
 {
@@ -502,6 +515,214 @@ static target_ulong h_scm_health(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+static int perf_stat_noop(SpaprDrc *drc, uint64_t unused, uint64_t *val)
+{
+*val = 0;
+return H_SUCCESS;
+}
+
+static int perf_stat_memlife(SpaprDrc *drc, uint64_t unused, uint64_t *val)

[PATCH] hw/display/qxl: Set pci rom address aligned with page size

[Bibo Mao]

From: maobibo 

pci memory bar size should be aligned with page size, else it will
not be effective memslot when running in kvm mode.

This patch set qxl pci rom size aligned with page size of host
machine.

Signed-off-by: Bibo Mao 
---
 hw/display/qxl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 2ba7563..c84f45e 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -317,11 +317,11 @@ static uint32_t qxl_crc32(const uint8_t *p, unsigned len)
 
 static ram_addr_t qxl_rom_size(void)
 {
-#define QXL_REQUIRED_SZ (sizeof(QXLRom) + sizeof(QXLModes) + sizeof(qxl_modes))
-#define QXL_ROM_SZ 8192
+uint32_t rom_size;
 
-QEMU_BUILD_BUG_ON(QXL_REQUIRED_SZ > QXL_ROM_SZ);
-return QXL_ROM_SZ;
+rom_size = sizeof(QXLRom) + sizeof(QXLModes) + sizeof(qxl_modes);
+rom_size = QEMU_ALIGN_UP(rom_size, qemu_real_host_page_size);
+return rom_size;
 }
 
 static void init_qxl_rom(PCIQXLDevice *d)
-- 
1.8.3.1

[Bug 1909823] Re: RDPMC check on PCE is backwards

[Bruce Merry]

It looks like this was fixed in c45b426.

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

Title:
  RDPMC check on PCE is backwards

Status in QEMU:
  Fix Released

Bug description:
  At [this
  
line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225)
  the check on CR4_PCE_MASK is backwards: it's raising an exception if
  the flag is set (and CPL != 0) rather than if the flag is clear.

  It's low priority at the moment because the instruction isn't
  implemented, so you get an illegal opcode exception when expecting a
  GPF, or vice versa, but it's a time bomb for if it is ever
  implemented.

  The Intel docs also indicate that CR0.PE influences the protection; I
  don't know if that's already reflected in env->hflags & HF_CPL_MASK.

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

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

[Philippe Mathieu-Daudé]

On 5/14/21 9:26 PM, John Snow wrote:
> On 5/14/21 3:23 PM, Thomas Huth wrote:
>> On 23/01/2021 11.03, P J P wrote:
>>> From: Prasad J Pandit 
>>>
>>> While processing ioport command in 'fdctrl_write_dor', device
>>> controller may select a drive which is not initialised with a
>>> block device. This may result in a NULL pointer dereference.
>>> Add checks to avoid it.
>>>
>>> Fixes: CVE-2021-20196
>>> Reported-by: Gaoning Pan 
>>> Buglink: https://bugs.launchpad.net/qemu/+bug/1912780
>>> Signed-off-by: Prasad J Pandit 
>>> ---
>>>   hw/block/fdc.c | 11 +--
>>>   1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
>>> index 3636874432..13a9470d19 100644
>>> --- a/hw/block/fdc.c
>>> +++ b/hw/block/fdc.c
>>> @@ -1429,7 +1429,9 @@ static void fdctrl_write_dor(FDCtrl *fdctrl,
>>> uint32_t value)
>>>   }
>>>   }
>>>   /* Selected drive */
>>> -    fdctrl->cur_drv = value & FD_DOR_SELMASK;
>>> +    if (fdctrl->drives[value & FD_DOR_SELMASK].blk) {
>>> +    fdctrl->cur_drv = value & FD_DOR_SELMASK;
>>> +    }
>>>   fdctrl->dor = value;
>>>   }
>>> @@ -1894,6 +1896,10 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
>>>   uint32_t pos;
>>>   cur_drv = get_cur_drv(fdctrl);
>>> +    if (!cur_drv->blk) {
>>> +    FLOPPY_DPRINTF("No drive connected\n");
>>> +    return 0;
>>> +    }
>>>   fdctrl->dsr &= ~FD_DSR_PWRDOWN;
>>>   if (!(fdctrl->msr & FD_MSR_RQM) || !(fdctrl->msr & FD_MSR_DIO)) {
>>>   FLOPPY_DPRINTF("error: controller not ready for reading\n");
>>> @@ -2420,7 +2426,8 @@ static void fdctrl_write_data(FDCtrl *fdctrl,
>>> uint32_t value)
>>>   if (pos == FD_SECTOR_LEN - 1 ||
>>>   fdctrl->data_pos == fdctrl->data_len) {
>>>   cur_drv = get_cur_drv(fdctrl);
>>> -    if (blk_pwrite(cur_drv->blk, fd_offset(cur_drv),
>>> fdctrl->fifo,
>>> +    if (cur_drv->blk == NULL
>>> +    || blk_pwrite(cur_drv->blk, fd_offset(cur_drv),
>>> fdctrl->fifo,
>>>  BDRV_SECTOR_SIZE, 0) < 0) {
>>>   FLOPPY_DPRINTF("error writing sector %d\n",
>>>  fd_sector(cur_drv));
>>>
>>
>> Ping again!
>>
>> Could anybody review / pick this up?

This patch misses the qtest companion with the reproducer
provided by Alexander.

> Yep. Not forgotten, despite appearances. Clearing my Python review
> backlog, then onto FDC/IDE.

Yeah \o/

> 
> In the meantime, anything anyone else happens to feel comfortable
> staging won't upset me any. I don't insist they go through my tree right
> now.

Re: [PATCH v6 23/26] tcg/tci: Split out tci_qemu_ld, tci_qemu_st

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> Expand the single-use macros into the new functions.
> Use cpu_ldsb_mmuidx_ra and cpu_ldsw_le_mmuidx_ra so
> that the trace event receives the correct sign flag.
> 
> Signed-off-by: Richard Henderson 
> ---
>  tcg/tci.c | 215 +++---
>  1 file changed, 75 insertions(+), 140 deletions(-)

Nice simplification.

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v6 06/26] tcg: Store the TCGHelperInfo in the TCGOp for call

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> This will give us both flags and typemask for use later.
> 
> We also fix a dumping bug, wherein calls generated for plugins
> fail tcg_find_helper and print (null) instead of either a name
> or the raw function pointer.
> 
> Signed-off-by: Richard Henderson 
> ---
>  tcg/internal.h | 14 +-
>  tcg/tcg.c  | 49 +
>  2 files changed, 34 insertions(+), 29 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v6 10/26] tcg/tci: Move call-return regs to end of tcg_target_reg_alloc_order

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> As the only call-clobbered regs for TCI, these should
> receive the least priority.
> 
> Signed-off-by: Richard Henderson 
> ---
>  tcg/tci/tcg-target.c.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v6 05/26] accel/tcg: Add tcg call flags to plugins helpers

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> As noted by qemu-plugins.h, plugins can neither read nor write
> guest registers.
> 
> Signed-off-by: Richard Henderson 
> ---
>  accel/tcg/plugin-helpers.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/accel/tcg/plugin-helpers.h b/accel/tcg/plugin-helpers.h
> index 853bd21677..9829abe4a9 100644
> --- a/accel/tcg/plugin-helpers.h
> +++ b/accel/tcg/plugin-helpers.h
> @@ -1,4 +1,4 @@
>  #ifdef CONFIG_PLUGIN
> -DEF_HELPER_2(plugin_vcpu_udata_cb, void, i32, ptr)
> -DEF_HELPER_4(plugin_vcpu_mem_cb, void, i32, i32, i64, ptr)
> +DEF_HELPER_FLAGS_2(plugin_vcpu_udata_cb, TCG_CALL_NO_RWG, void, i32, ptr)
> +DEF_HELPER_FLAGS_4(plugin_vcpu_mem_cb, TCG_CALL_NO_RWG, void, i32, i32, i64, 
> ptr)
>  #endif
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v6 01/26] tcg: Combine dh_is_64bit and dh_is_signed to dh_typecode

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> We will shortly be interested in distinguishing pointers
> from integers in the helper's declaration, as well as a
> true void return.  We currently have two parallel 1 bit
> fields; merge them and expand to a 3 bit field.
> 
> Our current maximum is 7 helper arguments, plus the return
> makes 8 * 3 = 24 bits used within the uint32_t typemask.
> 
> Signed-off-by: Richard Henderson 
> ---
>  include/exec/helper-head.h   | 37 +--
>  include/exec/helper-tcg.h| 34 -
>  target/hppa/helper.h |  3 --
>  target/i386/ops_sse_header.h |  3 --
>  target/m68k/helper.h |  1 -
>  target/ppc/helper.h  |  3 --
>  tcg/tcg.c| 71 +---
>  7 files changed, 67 insertions(+), 85 deletions(-)

Nice. I've been looking for a definition name for the heavily
used magic '3', but using such definitions doesn't really
help in the code review, so we are better without it.

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v6 24/26] tests/tcg: Increase timeout for TCI

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> The longest test at the moment seems to be a (slower)
> aarch64 host, for which test-mmap takes 64 seconds.
> 
> Reviewed-by: Thomas Huth 
> Signed-off-by: Richard Henderson 
> ---
>  configure | 3 +++
>  tests/tcg/Makefile.target | 6 --
>  2 files changed, 7 insertions(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 

[Bug 1921092] Re: gdbstub debug of multi-cluster machines is undocumented and confusing

[Thomas Huth]

Ok, thanks, so I'm closing this ticket now.

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

Title:
  gdbstub debug of multi-cluster machines is undocumented and confusing

Status in QEMU:
  Fix Released

Bug description:
  Working with Zephyr RTOS, running a multi core sample on mps2_an521 works 
fine. Both cpus start.
  Trying to debug with options -s -S the second core fails to boot.

  Posted with explanation also at: https://github.com/zephyrproject-
  rtos/zephyr/issues/33635

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

Re: [PATCH v6 17/26] tcg/tci: Implement movcond

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> When this opcode is not available in the backend, tcg middle-end
> will expand this as a series of 5 opcodes.  So implementing this
> saves bytecode space.
> 
> Signed-off-by: Richard Henderson 
> ---
>  tcg/tci/tcg-target.h |  4 ++--
>  tcg/tci.c| 16 +++-
>  tcg/tci/tcg-target.c.inc | 10 +++---
>  3 files changed, 24 insertions(+), 6 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [RFC 1/1] Implement AVR watchdog timer

[Philippe Mathieu-Daudé]

+Pavel/Alex

On 5/3/21 10:08 PM, Michael Rolnik wrote:
> Hi all,
> 
> I was about to make icount work. but, there is something I still don't
> understand. I have this code 
> 
> timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, avr_wdt_interrupt, s);
> 
> and then
> 
> void avr_wdt_interrupt(/* some arguments */) {
> #define MS2NS(n)        ((n) * 100ull)
>     timer_mod_ns(timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + MS2NS(15));
> }
> 
> when running with --icount shift=0, *avr_wdt_interrupt* is called about
> every 1K instructions, however it should have been called 15M
> instructions as shift=0 makes every instruction to be executed in 1
> virtual ns.
> 
> What am I doing wrong?
> 
> Thank you,
> Michael Rolnik
> 
> 
> On Mon, May 3, 2021 at 4:36 PM Michael Rolnik  > wrote:
> 
> Hi Fred.
> 
> 1. thanks
> 2. It seems I have forgotten to set those flags.
> 3. 15ms is easy to test 8s will take 533 times longer, so in my case
> 3200 instructions which is totally incorrect. I don't understand why
> as I program the timer in virtual nanoseconds and not host time.
> 4. I hope Richard could help with icount.
> 
> best regards,
> Michael Rolnik
> 
> On Mon, May 3, 2021 at 4:15 PM Fred Konrad  > wrote:
> 
> 
> 
> Le 5/2/21 à 10:10 PM, Michael Rolnik a écrit :
> > Signed-off-by: Michael Rolnik  >
> > ---
> >   hw/avr/Kconfig                |   1 +
> >   hw/avr/atmega.c               |  15 ++-
> >   hw/avr/atmega.h               |   2 +
> >   hw/watchdog/Kconfig           |   3 +
> >   hw/watchdog/avr_wdt.c         | 190
> ++
> >   hw/watchdog/meson.build       |   2 +
> >   hw/watchdog/trace-events      |   5 +
> >   include/hw/watchdog/avr_wdt.h |  47 +
> >   target/avr/cpu.c              |   3 +
> >   target/avr/cpu.h              |   1 +
> >   target/avr/helper.c           |   7 +-
> >   11 files changed, 271 insertions(+), 5 deletions(-)
> >   create mode 100644 hw/watchdog/avr_wdt.c
> >   create mode 100644 include/hw/watchdog/avr_wdt.h
> >
> > diff --git a/hw/avr/Kconfig b/hw/avr/Kconfig
> > index d31298c3cc..9939e4902f 100644
> > --- a/hw/avr/Kconfig
> > +++ b/hw/avr/Kconfig
> > @@ -3,6 +3,7 @@ config AVR_ATMEGA_MCU
> >       select AVR_TIMER16
> >       select AVR_USART
> >       select AVR_POWER
> > +    select AVR_WDT
> >   
> >   config ARDUINO
> >       select AVR_ATMEGA_MCU
> > diff --git a/hw/avr/atmega.c b/hw/avr/atmega.c
> > index 44c6afebbb..31ceb1c21c 100644
> > --- a/hw/avr/atmega.c
> > +++ b/hw/avr/atmega.c
> > @@ -28,6 +28,7 @@ enum AtmegaPeripheral {
> >       GPIOG, GPIOH, GPIOI, GPIOJ, GPIOK, GPIOL,
> >       USART0, USART1, USART2, USART3,
> >       TIMER0, TIMER1, TIMER2, TIMER3, TIMER4, TIMER5,
> > +    WDT,
> >       PERIFMAX
> >   };
> >   
> > @@ -75,6 +76,7 @@ static const peripheral_cfg
> dev168_328[PERIFMAX] = {
> >       [GPIOD]         = {  0x29 },
> >       [GPIOC]         = {  0x26 },
> >       [GPIOB]         = {  0x23 },
> > +    [WDT]           = {  0x60 },
> >   }, dev1280_2560[PERIFMAX] = {
> >       [USART3]        = { 0x130, POWER1, 2 },
> >       [TIMER5]        = { 0x120, POWER1, 5, 0x73, 0x3a, true },
> > @@ -99,6 +101,7 @@ static const peripheral_cfg
> dev168_328[PERIFMAX] = {
> >       [GPIOC]         = {  0x26 },
> >       [GPIOB]         = {  0x23 },
> >       [GPIOA]         = {  0x20 },
> > +    [WDT]           = {  0x60 },
> >   };
> >   
> >   enum AtmegaIrq {
> > @@ -118,6 +121,7 @@ enum AtmegaIrq {
> >           TIMER4_COMPC_IRQ, TIMER4_OVF_IRQ,
> >       TIMER5_CAPT_IRQ, TIMER5_COMPA_IRQ, TIMER5_COMPB_IRQ,
> >           TIMER5_COMPC_IRQ, TIMER5_OVF_IRQ,
> > +    WATCHDOG_TIMER_IRQ,
> >       IRQ_COUNT
> >   };
> >   
> > @@ -133,6 +137,7 @@ enum AtmegaIrq {
> >   #define TIMER_OVF_IRQ(n)    (n * TIMER_IRQ_COUNT +
> TIMER0_OVF_IRQ)
> >   
> >   static const uint8_t irq168_328[IRQ_COUNT] = {
> > +    [WATCHDOG_TIMER_IRQ]    = 7,
> >       [TIMER2_COMPA_IRQ]      = 8,
> >       [TIMER2_COMPB_IRQ]      = 9,
> >       [TIMER2_OVF_IRQ]        = 10,
> > @@ -147,6 +152,7 @@ static const uint8_t irq168_328[IRQ_COUNT] = {
> >       [USART0_DRE_IRQ]        = 20,
> >       [USART0_TXC_IRQ]        = 21,
> >   }, irq1280_2560[IRQ_COUNT] = {
> > +    [WATC

[Bug 1879955] Re: target/i386/seg_helper.c: 16-bit TSS struct format wrong?

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1879955

Title:
  target/i386/seg_helper.c: 16-bit TSS struct format wrong?

Status in QEMU:
  Incomplete

Bug description:
  In target/i386/seg_helper.c:switch_tss_ra() we have the following code
  to load registers from a 16-bit TSS struct:

  /* 16 bit */
  new_cr3 = 0;
  new_eip = cpu_lduw_kernel_ra(env, tss_base + 0x0e, retaddr);
  new_eflags = cpu_lduw_kernel_ra(env, tss_base + 0x10, retaddr);
  for (i = 0; i < 8; i++) {
  new_regs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x12 + i * 2),
   retaddr) | 0x;
  }
  for (i = 0; i < 4; i++) {
  new_segs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x22 + i * 4),
   retaddr);
  }
  new_ldt = cpu_lduw_kernel_ra(env, tss_base + 0x2a, retaddr);

  This doesn't match up with the structure described here:
  https://www.sandpile.org/x86/tss.htm -- which has only 2-byte slots
  for the segment registers. It also makes the 3rd segreg use the same
  offset as the LDTR, which is very suspicious. I suspect that this
  should use "(0x22 + i * 2)".

  The code later in the same function that stores the segment registers
  to the struct has the same bug.

  Found by code inspection; I don't have a test case to check this. As a
  non-x86-expert I'm just going to file a bug report in case somebody
  else feels like confirming the issue and sending a patch.

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

[Bug 1924603] Re: Incorrect feature negotiation for vhost-vdpa netdevice

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1924603

Title:
  Incorrect feature negotiation for vhost-vdpa netdevice

Status in QEMU:
  Incomplete

Bug description:
  QEMU cmdline:
  =
  ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -m 2G -hda  
/gautam/centos75_1.qcow2 -name gautam,process=gautam -enable-kvm -netdev 
vhost-vdpa,id=mynet0,vhostdev=/dev/vhost-vdpa-0 -device 
virtio-net-pci,netdev=mynet0,mac=02:AA:BB:DD:00:20,disable-modern=off,page-per-vq=on
 -cpu host --nographic

  Host OS:
  
  Linux kernel 5.11 running on x86 host

  Guest OS:
  ==
  CentOS 7.5

  Root cause analysis:
  =

  For vhost-vdpa netdevice, the feature negotiation results in sending
  the superset of features received from device in call to get_features
  vdpa ops callback.

  During the feature-negotiation phase, the acknowledged feature bits
  are initialized with backend_features  and then checked for supported
  feature bits in vhost_ack_features():

  void vhost_net_ack_features(struct vhost_net *net, uint64_t features)
  {
net->dev.acked_features = net->dev.backend_features;
vhost_ack_features(&net->dev, vhost_net_get_feature_bits(net), features);
  }

   
  The vhost_ack_features() function just builds up on the dev.acked_features 
and never trims it down:

  void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits, 
uint64_t features)
  { const int *bit = feature_bits;

while (*bit != VHOST_INVALID_FEATURE_BIT) {
 uint64_t bit_mask = (1ULL << *bit);  

  if (features & bit_mask)
   hdev->acked_features |= bit_mask;

  bit++;
 }
  }

  Because of this hdev->acked_features is always minimally equal to the
  value of device features and this is the value that is passed to the
  device in set_features callback:

  static int vhost_dev_set_features(struct vhost_dev *dev, bool enable_log)
  {
 uint64_t *features = dev->acked_features;
 .
 r = dev->vhost_ops->*vhost_set_features*(dev, features);
  }

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

[PULL 00/16] Trivial branch for 6.1 patches

[Laurent Vivier]

The following changes since commit 3e9f48bcdabe57f8f90cf19f01bbbf3c86937267:

  Merge remote-tracking branch 
'remotes/alistair/tags/pull-riscv-to-apply-20210511' into staging (2021-05-12 
17:31:52 +0100)

are available in the Git repository at:

  git://github.com/vivier/qemu.git tags/trivial-branch-for-6.1-pull-request

for you to fetch changes up to 29f9c636894c462fa54fad08049e51877905e93b:

  target/avr: Ignore unimplemented WDR opcode (2021-05-13 19:18:42 +0200)


Pull request trivial-branch 20210515



Frederic Konrad (1):
  hw/avr/atmega.c: use the avr51 cpu for atmega1280

Greg Kurz (1):
  virtiofsd: Fix check of chown()'s return value

Jagannathan Raman (1):
  multi-process: Avoid logical AND of mutually exclusive tests

Michael Tokarev (2):
  qapi: spelling fix (addtional)
  hw/gpio/aspeed: spelling fix (addtional)

Philippe Mathieu-Daudé (10):
  backends/tpm: Replace qemu_mutex_lock calls with QEMU_LOCK_GUARD
  hw/virtio: Pass virtio_feature_get_config_size() a const argument
  virtio-blk: Constify VirtIOFeature feature_sizes[]
  virtio-net: Constify VirtIOFeature feature_sizes[]
  hw/timer/etraxfs_timer: Convert to 3-phase reset (Resettable
interface)
  hw/rtc/mc146818rtc: Convert to 3-phase reset (Resettable interface)
  hw/mem/meson: Fix linking sparse-mem device with fuzzer
  hw/pci-host: Do not build gpex-acpi.c if GPEX is not selected
  target/sh4: Return error if CPUClass::get_phys_page_debug() fails
  target/avr: Ignore unimplemented WDR opcode

Stefano Garzarella (1):
  cutils: fix memory leak in get_relocated_path()

 backends/tpm/tpm_emulator.c   | 34 +---
 hw/avr/atmega.c   |  2 +-
 hw/block/virtio-blk.c |  2 +-
 hw/gpio/aspeed_gpio.c |  2 +-
 hw/mem/meson.build|  3 ++-
 hw/net/virtio-net.c   |  2 +-
 hw/pci-host/meson.build   |  2 +-
 hw/remote/mpqemu-link.c   |  2 +-
 hw/rtc/mc146818rtc.c  | 42 ++-
 hw/timer/etraxfs_timer.c  | 14 +---
 hw/virtio/virtio.c|  2 +-
 include/hw/virtio/virtio.h|  2 +-
 qapi/qom.json |  4 ++--
 target/avr/helper.c   |  6 +
 target/sh4/helper.c   |  7 --
 tools/virtiofsd/fuse_virtio.c |  4 ++--
 util/cutils.c |  2 +-
 17 files changed, 69 insertions(+), 63 deletions(-)

-- 
2.31.1

[PULL 02/16] hw/virtio: Pass virtio_feature_get_config_size() a const argument

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

The VirtIOFeature structure isn't modified, mark it const.

Signed-off-by: Philippe Mathieu-Daudé 
Acked-by: Jason Wang 
Reviewed-by: Richard Henderson 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Stefano Garzarella 
Message-Id: <20210511104157.2880306-2-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/virtio/virtio.c | 2 +-
 include/hw/virtio/virtio.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 9e13cb9e3adf..e02544b2df76 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2981,7 +2981,7 @@ int virtio_set_features(VirtIODevice *vdev, uint64_t val)
 return ret;
 }
 
-size_t virtio_feature_get_config_size(VirtIOFeature *feature_sizes,
+size_t virtio_feature_get_config_size(const VirtIOFeature *feature_sizes,
   uint64_t host_features)
 {
 size_t config_size = 0;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index b7ece7a6a891..8bab9cfb7507 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -43,7 +43,7 @@ typedef struct VirtIOFeature {
 size_t end;
 } VirtIOFeature;
 
-size_t virtio_feature_get_config_size(VirtIOFeature *features,
+size_t virtio_feature_get_config_size(const VirtIOFeature *features,
   uint64_t host_features);
 
 typedef struct VirtQueue VirtQueue;
-- 
2.31.1

[PULL 01/16] backends/tpm: Replace qemu_mutex_lock calls with QEMU_LOCK_GUARD

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Simplify the tpm_emulator_ctrlcmd() handler by replacing a pair of
qemu_mutex_lock/qemu_mutex_unlock calls by the WITH_QEMU_LOCK_GUARD
macro.

Reviewed-by: Stefan Berger 
Reviewed-by: Christophe de Dinechin 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20210512070713.3286188-1-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 backends/tpm/tpm_emulator.c | 34 +++---
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/backends/tpm/tpm_emulator.c b/backends/tpm/tpm_emulator.c
index a012adc19341..e5f1063ab6c3 100644
--- a/backends/tpm/tpm_emulator.c
+++ b/backends/tpm/tpm_emulator.c
@@ -30,6 +30,7 @@
 #include "qemu/error-report.h"
 #include "qemu/module.h"
 #include "qemu/sockets.h"
+#include "qemu/lockable.h"
 #include "io/channel-socket.h"
 #include "sysemu/tpm_backend.h"
 #include "sysemu/tpm_util.h"
@@ -124,31 +125,26 @@ static int tpm_emulator_ctrlcmd(TPMEmulator *tpm, 
unsigned long cmd, void *msg,
 uint32_t cmd_no = cpu_to_be32(cmd);
 ssize_t n = sizeof(uint32_t) + msg_len_in;
 uint8_t *buf = NULL;
-int ret = -1;
 
-qemu_mutex_lock(&tpm->mutex);
+WITH_QEMU_LOCK_GUARD(&tpm->mutex) {
+buf = g_alloca(n);
+memcpy(buf, &cmd_no, sizeof(cmd_no));
+memcpy(buf + sizeof(cmd_no), msg, msg_len_in);
 
-buf = g_alloca(n);
-memcpy(buf, &cmd_no, sizeof(cmd_no));
-memcpy(buf + sizeof(cmd_no), msg, msg_len_in);
-
-n = qemu_chr_fe_write_all(dev, buf, n);
-if (n <= 0) {
-goto end;
-}
-
-if (msg_len_out != 0) {
-n = qemu_chr_fe_read_all(dev, msg, msg_len_out);
+n = qemu_chr_fe_write_all(dev, buf, n);
 if (n <= 0) {
-goto end;
+return -1;
 }
-}
 
-ret = 0;
+if (msg_len_out != 0) {
+n = qemu_chr_fe_read_all(dev, msg, msg_len_out);
+if (n <= 0) {
+return -1;
+}
+}
+}
 
-end:
-qemu_mutex_unlock(&tpm->mutex);
-return ret;
+return 0;
 }
 
 static int tpm_emulator_unix_tx_bufs(TPMEmulator *tpm_emu,
-- 
2.31.1

[PULL 10/16] cutils: fix memory leak in get_relocated_path()

[Laurent Vivier]

From: Stefano Garzarella 

get_relocated_path() allocates a GString object and returns the
character data (C string) to the caller without freeing the memory
allocated for that object as reported by valgrind:

  24 bytes in 1 blocks are definitely lost in loss record 2,805 of 6,532
 at 0x4839809: malloc (vg_replace_malloc.c:307)
 by 0x55AABB8: g_malloc (in /usr/lib64/libglib-2.0.so.0.6600.8)
 by 0x55C2481: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.6600.8)
 by 0x55C4827: g_string_sized_new (in /usr/lib64/libglib-2.0.so.0.6600.8)
 by 0x55C4CEA: g_string_new (in /usr/lib64/libglib-2.0.so.0.6600.8)
 by 0x906314: get_relocated_path (cutils.c:1036)
 by 0x6E1F77: qemu_read_default_config_file (vl.c:2122)
 by 0x6E1F77: qemu_init (vl.c:2687)
 by 0x3E3AF8: main (main.c:49)

Let's use g_string_free(gstring, false) to free only the GString object
and transfer the ownership of the character data to the caller.

Fixes: f4f5ed2cbd ("cutils: introduce get_relocated_path")
Signed-off-by: Stefano Garzarella 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
Message-Id: <20210412170255.231406-1-sgarz...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 util/cutils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/util/cutils.c b/util/cutils.c
index ee908486da44..c9b91e7535a8 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -1055,5 +1055,5 @@ char *get_relocated_path(const char *dir)
 assert(G_IS_DIR_SEPARATOR(dir[-1]));
 g_string_append(result, dir - 1);
 }
-return result->str;
+return g_string_free(result, false);
 }
-- 
2.31.1

[PULL 03/16] virtio-blk: Constify VirtIOFeature feature_sizes[]

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Acked-by: Jason Wang 
Reviewed-by: Richard Henderson 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Stefano Garzarella 
Message-Id: <20210511104157.2880306-3-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/block/virtio-blk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index d28979efb8d7..f139cd7cc9cc 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -40,7 +40,7 @@
  * Starting from the discard feature, we can use this array to properly
  * set the config size depending on the features enabled.
  */
-static VirtIOFeature feature_sizes[] = {
+static const VirtIOFeature feature_sizes[] = {
 {.flags = 1ULL << VIRTIO_BLK_F_DISCARD,
  .end = endof(struct virtio_blk_config, discard_sector_alignment)},
 {.flags = 1ULL << VIRTIO_BLK_F_WRITE_ZEROES,
-- 
2.31.1

[PULL 06/16] qapi: spelling fix (addtional)

[Laurent Vivier]

From: Michael Tokarev 

Fixes: 3d0d3c30ae3a259bff176f85a3efa2d0816695af
Signed-off-by: Michael Tokarev 
Reviewed-by: Kevin Wolf 
Message-Id: <20210508093315.393274-1-...@msgid.tls.msk.ru>
Signed-off-by: Laurent Vivier 
---
 qapi/qom.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/qapi/qom.json b/qapi/qom.json
index cd0e76d56459..40d70c434a09 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -251,8 +251,8 @@
 #
 # @max_queue_size: the maximum number of packets to keep in the queue for
 #  comparing with incoming packets from @secondary_in.  If the
-#  queue is full and addtional packets are received, the
-#  addtional packets are dropped. (default: 1024)
+#  queue is full and additional packets are received, the
+#  additional packets are dropped. (default: 1024)
 #
 # @vnet_hdr_support: if true, vnet header support is enabled (default: false)
 #
-- 
2.31.1

[PULL 05/16] virtiofsd: Fix check of chown()'s return value

[Laurent Vivier]

From: Greg Kurz 

Otherwise you always get this warning when using --socket-group=users

 vhost socket failed to set group to users (100)

While here, print out the error if chown() fails.

Fixes: f6698f2b03b0 ("tools/virtiofsd: add support for --socket-group")
Signed-off-by: Greg Kurz 
Reviewed-by: Dr. David Alan Gilbert 
Message-Id: <162040394890.714971.15502455176528384778.st...@bahia.lan>
Signed-off-by: Laurent Vivier 
---
 tools/virtiofsd/fuse_virtio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 1170f375a57a..9efdbd8ffd0a 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -1024,9 +1024,9 @@ static int fv_create_listen_socket(struct fuse_session 
*se)
 if (se->vu_socket_group) {
 struct group *g = getgrnam(se->vu_socket_group);
 if (g) {
-if (!chown(se->vu_socket_path, -1, g->gr_gid)) {
+if (chown(se->vu_socket_path, -1, g->gr_gid) == -1) {
 fuse_log(FUSE_LOG_WARNING,
- "vhost socket failed to set group to %s (%d)\n",
+ "vhost socket failed to set group to %s (%d): %m\n",
  se->vu_socket_group, g->gr_gid);
 }
 }
-- 
2.31.1

[PULL 07/16] hw/gpio/aspeed: spelling fix (addtional)

[Laurent Vivier]

From: Michael Tokarev 

Fixes: 36d737ee82b2972167e97901c5271ba3f904ba71
Signed-off-by: Michael Tokarev 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210508093615.411920-1-...@msgid.tls.msk.ru>
Signed-off-by: Laurent Vivier 
---
 hw/gpio/aspeed_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index 985a259e05b7..34d8acb0e37a 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -170,7 +170,7 @@
 /* AST2600 only - 1.8V gpios */
 /*
  * The AST2600 has same 3.6V gpios as the AST2400 (memory offsets 0x0-0x198)
- * and addtional 1.8V gpios (memory offsets 0x800-0x9D4).
+ * and additional 1.8V gpios (memory offsets 0x800-0x9D4).
  */
 #define GPIO_1_8V_REG_OFFSET  0x800
 #define GPIO_1_8V_ABCD_DATA_VALUE ((0x800 - GPIO_1_8V_REG_OFFSET) >> 2)
-- 
2.31.1

[PULL 11/16] hw/mem/meson: Fix linking sparse-mem device with fuzzer

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

sparse-mem.c is added to the 'mem_ss' source set, which itself
is conditionally added to softmmu_ss if CONFIG_MEM_DEVICE is
selected.
But if CONFIG_MEM_DEVICE isn't selected, we get a link failure
even if CONFIG_FUZZ is selected:

  /usr/bin/ld: tests_qtest_fuzz_generic_fuzz.c.o: in function 
`generic_pre_fuzz':
  tests/qtest/fuzz/generic_fuzz.c:826: undefined reference to `sparse_mem_init'
  clang-10: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fix by adding sparse-mem.c directly to the softmmu_ss set.

Fixes: 230376d285b ("memory: add a sparse memory device for fuzzing")
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Alexander Bulekov 
Message-Id: <20210406133944.4193691-1-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/mem/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/mem/meson.build b/hw/mem/meson.build
index ef79e046787c..3c8fdef9f9e9 100644
--- a/hw/mem/meson.build
+++ b/hw/mem/meson.build
@@ -1,8 +1,9 @@
 mem_ss = ss.source_set()
 mem_ss.add(files('memory-device.c'))
-mem_ss.add(when: 'CONFIG_FUZZ', if_true: files('sparse-mem.c'))
 mem_ss.add(when: 'CONFIG_DIMM', if_true: files('pc-dimm.c'))
 mem_ss.add(when: 'CONFIG_NPCM7XX', if_true: files('npcm7xx_mc.c'))
 mem_ss.add(when: 'CONFIG_NVDIMM', if_true: files('nvdimm.c'))
 
 softmmu_ss.add_all(when: 'CONFIG_MEM_DEVICE', if_true: mem_ss)
+
+softmmu_ss.add(when: 'CONFIG_FUZZ', if_true: files('sparse-mem.c'))
-- 
2.31.1

[PULL 04/16] virtio-net: Constify VirtIOFeature feature_sizes[]

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Acked-by: Jason Wang 
Reviewed-by: Richard Henderson 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Stefano Garzarella 
Message-Id: <20210511104157.2880306-4-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/net/virtio-net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 66b9ff451185..6b7e8dd04ef3 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -89,7 +89,7 @@
  VIRTIO_NET_RSS_HASH_TYPE_TCP_EX | \
  VIRTIO_NET_RSS_HASH_TYPE_UDP_EX)
 
-static VirtIOFeature feature_sizes[] = {
+static const VirtIOFeature feature_sizes[] = {
 {.flags = 1ULL << VIRTIO_NET_F_MAC,
  .end = endof(struct virtio_net_config, mac)},
 {.flags = 1ULL << VIRTIO_NET_F_STATUS,
-- 
2.31.1

[PULL 14/16] target/sh4: Return error if CPUClass::get_phys_page_debug() fails

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

If the get_physical_address() call fails, the SH4 get_phys_page_debug()
handler returns an uninitialized address. Instead return -1, which
correspond to "no page found" (see cpu_get_phys_page_debug() doc
string).

This fixes a warning emitted when building with CFLAGS=-O3
(using GCC 10.2.1 20201125):

  target/sh4/helper.c: In function ‘superh_cpu_get_phys_page_debug’:
  target/sh4/helper.c:446:12: warning: ‘physical’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
446 | return physical;
|^~~~

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 
Message-Id: <20210505161046.1397608-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 target/sh4/helper.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/sh4/helper.c b/target/sh4/helper.c
index bd8e034f174d..2d622081e85a 100644
--- a/target/sh4/helper.c
+++ b/target/sh4/helper.c
@@ -441,9 +441,12 @@ hwaddr superh_cpu_get_phys_page_debug(CPUState *cs, vaddr 
addr)
 target_ulong physical;
 int prot;
 
-get_physical_address(&cpu->env, &physical, &prot, addr, MMU_DATA_LOAD);
+if (get_physical_address(&cpu->env, &physical, &prot, addr, MMU_DATA_LOAD)
+== MMU_OK) {
+return physical;
+}
 
-return physical;
+return -1;
 }
 
 void cpu_load_tlb(CPUSH4State * env)
-- 
2.31.1

[PULL 13/16] multi-process: Avoid logical AND of mutually exclusive tests

[Laurent Vivier]

From: Jagannathan Raman 

Fixes an if statement that performs a logical AND of mutually exclusive
tests

Buglink: https://bugs.launchpad.net/qemu/+bug/1926995
Reviewed-by: Thomas Huth 
Signed-off-by: Jagannathan Raman 
Reviewed-by: Thomas Huth 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <1620402803-9237-1-git-send-email-jag.ra...@oracle.com>
Signed-off-by: Laurent Vivier 
---
 hw/remote/mpqemu-link.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/remote/mpqemu-link.c b/hw/remote/mpqemu-link.c
index 9ce31526e8f2..e67a5de72ca7 100644
--- a/hw/remote/mpqemu-link.c
+++ b/hw/remote/mpqemu-link.c
@@ -218,7 +218,7 @@ uint64_t mpqemu_msg_send_and_await_reply(MPQemuMsg *msg, 
PCIProxyDev *pdev,
 
 bool mpqemu_msg_valid(MPQemuMsg *msg)
 {
-if (msg->cmd >= MPQEMU_CMD_MAX && msg->cmd < 0) {
+if (msg->cmd >= MPQEMU_CMD_MAX || msg->cmd < 0) {
 return false;
 }
 
-- 
2.31.1

[PULL 08/16] hw/timer/etraxfs_timer: Convert to 3-phase reset (Resettable interface)

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

TYPE_ETRAX_FS_TIMER is a sysbus device, so its DeviceClass::reset()
handler is called automatically when its qbus parent is reset
(we don't need to register it manually).

Convert the generic reset to a enter/hold resettable ones, and
remove the qemu_register_reset() call.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Edgar E. Iglesias 
Message-Id: <20210502163931.552675-2-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/timer/etraxfs_timer.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/hw/timer/etraxfs_timer.c b/hw/timer/etraxfs_timer.c
index 5379006086fb..4ba662190de3 100644
--- a/hw/timer/etraxfs_timer.c
+++ b/hw/timer/etraxfs_timer.c
@@ -309,9 +309,9 @@ static const MemoryRegionOps timer_ops = {
 }
 };
 
-static void etraxfs_timer_reset(void *opaque)
+static void etraxfs_timer_reset_enter(Object *obj, ResetType type)
 {
-ETRAXTimerState *t = opaque;
+ETRAXTimerState *t = ETRAX_TIMER(obj);
 
 ptimer_transaction_begin(t->ptimer_t0);
 ptimer_stop(t->ptimer_t0);
@@ -325,6 +325,12 @@ static void etraxfs_timer_reset(void *opaque)
 t->rw_wd_ctrl = 0;
 t->r_intr = 0;
 t->rw_intr_mask = 0;
+}
+
+static void etraxfs_timer_reset_hold(Object *obj)
+{
+ETRAXTimerState *t = ETRAX_TIMER(obj);
+
 qemu_irq_lower(t->irq);
 }
 
@@ -343,14 +349,16 @@ static void etraxfs_timer_realize(DeviceState *dev, Error 
**errp)
 memory_region_init_io(&t->mmio, OBJECT(t), &timer_ops, t,
   "etraxfs-timer", 0x5c);
 sysbus_init_mmio(sbd, &t->mmio);
-qemu_register_reset(etraxfs_timer_reset, t);
 }
 
 static void etraxfs_timer_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
+ResettableClass *rc = RESETTABLE_CLASS(klass);
 
 dc->realize = etraxfs_timer_realize;
+rc->phases.enter = etraxfs_timer_reset_enter;
+rc->phases.hold = etraxfs_timer_reset_hold;
 }
 
 static const TypeInfo etraxfs_timer_info = {
-- 
2.31.1

[PULL 09/16] hw/rtc/mc146818rtc: Convert to 3-phase reset (Resettable interface)

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

TYPE_MC146818_RTC is an ISA device, so its DeviceClass::reset()
handler is called automatically when its qbus parent is reset
(we don't need to register it manually).

We have 2 reset() methods: a generic one and the qdev one.
Merge them into a reset_enter handler (keeping the IRQ lowering
to a reset_hold one), and remove the qemu_register_reset() call.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Edgar E. Iglesias 
Message-Id: <20210502163931.552675-3-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/rtc/mc146818rtc.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
index 3d2d3854e716..4fbafddb226d 100644
--- a/hw/rtc/mc146818rtc.c
+++ b/hw/rtc/mc146818rtc.c
@@ -871,22 +871,6 @@ static void rtc_notify_suspend(Notifier *notifier, void 
*data)
 rtc_set_memory(ISA_DEVICE(s), 0xF, 0xFE);
 }
 
-static void rtc_reset(void *opaque)
-{
-RTCState *s = opaque;
-
-s->cmos_data[RTC_REG_B] &= ~(REG_B_PIE | REG_B_AIE | REG_B_SQWE);
-s->cmos_data[RTC_REG_C] &= ~(REG_C_UF | REG_C_IRQF | REG_C_PF | REG_C_AF);
-check_update_timer(s);
-
-qemu_irq_lower(s->irq);
-
-if (s->lost_tick_policy == LOST_TICK_POLICY_SLEW) {
-s->irq_coalesced = 0;
-s->irq_reinject_on_ack_count = 0;
-}
-}
-
 static const MemoryRegionOps cmos_ops = {
 .read = cmos_ioport_read,
 .write = cmos_ioport_write,
@@ -961,7 +945,6 @@ static void rtc_realizefn(DeviceState *dev, Error **errp)
 memory_region_add_coalescing(&s->coalesced_io, 0, 1);
 
 qdev_set_legacy_instance_id(dev, RTC_ISA_BASE, 3);
-qemu_register_reset(rtc_reset, s);
 
 object_property_add_tm(OBJECT(s), "date", rtc_get_date);
 
@@ -997,15 +980,32 @@ static Property mc146818rtc_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
-static void rtc_resetdev(DeviceState *d)
+static void rtc_reset_enter(Object *obj, ResetType type)
 {
-RTCState *s = MC146818_RTC(d);
+RTCState *s = MC146818_RTC(obj);
 
 /* Reason: VM do suspend self will set 0xfe
  * Reset any values other than 0xfe(Guest suspend case) */
 if (s->cmos_data[0x0f] != 0xfe) {
 s->cmos_data[0x0f] = 0x00;
 }
+
+s->cmos_data[RTC_REG_B] &= ~(REG_B_PIE | REG_B_AIE | REG_B_SQWE);
+s->cmos_data[RTC_REG_C] &= ~(REG_C_UF | REG_C_IRQF | REG_C_PF | REG_C_AF);
+check_update_timer(s);
+
+
+if (s->lost_tick_policy == LOST_TICK_POLICY_SLEW) {
+s->irq_coalesced = 0;
+s->irq_reinject_on_ack_count = 0;
+}
+}
+
+static void rtc_reset_hold(Object *obj)
+{
+RTCState *s = MC146818_RTC(obj);
+
+qemu_irq_lower(s->irq);
 }
 
 static void rtc_build_aml(ISADevice *isadev, Aml *scope)
@@ -1032,11 +1032,13 @@ static void rtc_build_aml(ISADevice *isadev, Aml *scope)
 static void rtc_class_initfn(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
+ResettableClass *rc = RESETTABLE_CLASS(klass);
 ISADeviceClass *isa = ISA_DEVICE_CLASS(klass);
 
 dc->realize = rtc_realizefn;
-dc->reset = rtc_resetdev;
 dc->vmsd = &vmstate_rtc;
+rc->phases.enter = rtc_reset_enter;
+rc->phases.hold = rtc_reset_hold;
 isa->build_aml = rtc_build_aml;
 device_class_set_props(dc, mc146818rtc_properties);
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
-- 
2.31.1

[PULL 12/16] hw/pci-host: Do not build gpex-acpi.c if GPEX is not selected

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Since its introduction in commit 5b85eabe68f ("acpi: add
acpi_dsdt_add_gpex") we build gpex-acpi.c if ACPI is selected,
even if the GPEX_HOST device isn't build. Add the missing
Kconfig dependency.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Alistair Francis 
Reviewed-by: Gerd Hoffmann 
Message-Id: <20210425182124.3735214-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/pci-host/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci-host/meson.build b/hw/pci-host/meson.build
index 34b3538bebf6..1698d3a1920a 100644
--- a/hw/pci-host/meson.build
+++ b/hw/pci-host/meson.build
@@ -3,7 +3,7 @@ pci_ss.add(when: 'CONFIG_PAM', if_true: files('pam.c'))
 pci_ss.add(when: 'CONFIG_PCI_BONITO', if_true: files('bonito.c'))
 pci_ss.add(when: 'CONFIG_PCI_EXPRESS_DESIGNWARE', if_true: 
files('designware.c'))
 pci_ss.add(when: 'CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', if_true: files('gpex.c'))
-pci_ss.add(when: 'CONFIG_ACPI', if_true: files('gpex-acpi.c'))
+pci_ss.add(when: ['CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', 'CONFIG_ACPI'], 
if_true: files('gpex-acpi.c'))
 pci_ss.add(when: 'CONFIG_PCI_EXPRESS_Q35', if_true: files('q35.c'))
 pci_ss.add(when: 'CONFIG_PCI_EXPRESS_XILINX', if_true: files('xilinx-pcie.c'))
 pci_ss.add(when: 'CONFIG_PCI_I440FX', if_true: files('i440fx.c'))
-- 
2.31.1

[PULL 16/16] target/avr: Ignore unimplemented WDR opcode

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Running the WDR opcode triggers a segfault:

  $ cat > foo.S << EOF
  > __start:
  > wdr
  > EOF
  $ avr-gcc -nostdlib -nostartfiles -mmcu=avr6 foo.S -o foo.elf
  $ qemu-system-avr -serial mon:stdio -nographic -no-reboot \
-M mega -bios foo.elf -d in_asm --singlestep
  IN:
  0x:  WDR
  Segmentation fault (core dumped)

  (gdb) bt
 #0  0xadd0b23a in gdb_get_cpu_pid (cpu=0xaf5a4af0) at 
../gdbstub.c:718
 #1  0xadd0b2dd in gdb_get_cpu_process (cpu=0xaf5a4af0) at 
../gdbstub.c:743
 #2  0xadd0e477 in gdb_set_stop_cpu (cpu=0xaf5a4af0) at 
../gdbstub.c:2742
 #3  0xadc99b96 in cpu_handle_guest_debug (cpu=0xaf5a4af0) at 
../softmmu/cpus.c:306
 #4  0xadcc66ab in rr_cpu_thread_fn (arg=0xaf5a4af0) at 
../accel/tcg/tcg-accel-ops-rr.c:224
 #5  0xadefaf12 in qemu_thread_start (args=0xaf5d9870) at 
../util/qemu-thread-posix.c:521
 #6  0x7f692d940ea5 in start_thread () from /lib64/libpthread.so.0
 #7  0x7f692d6699fd in clone () from /lib64/libc.so.6

Since the watchdog peripheral is not implemented, simply
log the opcode as unimplemented and keep going.

Reported-by: Fred Konrad 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: KONRAD Frederic 
Message-Id: <20210502190900.604292-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 target/avr/helper.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/target/avr/helper.c b/target/avr/helper.c
index 35e101959404..981c29da4535 100644
--- a/target/avr/helper.c
+++ b/target/avr/helper.c
@@ -188,11 +188,7 @@ void helper_break(CPUAVRState *env)
 
 void helper_wdr(CPUAVRState *env)
 {
-CPUState *cs = env_cpu(env);
-
-/* WD is not implemented yet, placeholder */
-cs->exception_index = EXCP_DEBUG;
-cpu_loop_exit(cs);
+qemu_log_mask(LOG_UNIMP, "WDG reset (not implemented)\n");
 }
 
 /*
-- 
2.31.1

[PULL 15/16] hw/avr/atmega.c: use the avr51 cpu for atmega1280

[Laurent Vivier]

From: Frederic Konrad 

According to the as documentation:
 (https://sourceware.org/binutils/docs-2.36/as/AVR-Options.html)

"Instruction set avr51 is for the enhanced AVR core with exactly 128K
 program memory space (MCU types: atmega128, atmega128a, atmega1280,
 atmega1281, atmega1284, atmega1284p, atmega128rfa1, atmega128rfr2,
 atmega1284rfr2, at90can128, at90usb1286, at90usb1287, m3000)."

But when compiling a program for atmega1280 or avr51 and trying to execute
it:

$ cat > test.S << EOF
> loop:
> rjmp loop
> EOF
$ avr-gcc -nostdlib -nostartfiles -mmcu=atmega1280 test.S -o test.elf
$ qemu-system-avr -serial mon:stdio -nographic -no-reboot -M mega \
  -bios test.elf
qemu-system-avr: Current machine: Arduino Mega (ATmega1280) with 'avr6' CPU
qemu-system-avr: ELF image 'test.elf' is for 'avr51' CPU

So this fixes the atmega1280 class to use an avr51 CPU.

Signed-off-by: Frederic Konrad 
Reviewed-by: Joaquin de Andres 
Message-Id: <1619637319-22299-1-git-send-email-frederic.kon...@adacore.com>
Signed-off-by: Laurent Vivier 
---
 hw/avr/atmega.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/avr/atmega.c b/hw/avr/atmega.c
index 80b8a41cb5a5..0608e2d475ee 100644
--- a/hw/avr/atmega.c
+++ b/hw/avr/atmega.c
@@ -401,7 +401,7 @@ static void atmega1280_class_init(ObjectClass *oc, void 
*data)
 {
 AtmegaMcuClass *amc = ATMEGA_MCU_CLASS(oc);
 
-amc->cpu_type = AVR_CPU_TYPE_NAME("avr6");
+amc->cpu_type = AVR_CPU_TYPE_NAME("avr51");
 amc->flash_size = 128 * KiB;
 amc->eeprom_size = 4 * KiB;
 amc->sram_size = 8 * KiB;
-- 
2.31.1

[Bug 1923648] Re: macOS App Nap feature gradually freezes QEMU process

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1923648

Title:
  macOS App Nap feature gradually freezes QEMU process

Status in QEMU:
  Incomplete

Bug description:
  macOS version: 10.15.2
  QEMU versions: 5.2.0 (from MacPorts)
 5.2.92 (v6.0.0-rc2-23-g9692c7b037)

  If the QEMU window is not visible (hidden, minimized or another
  application is in full screen mode), the QEMU process gradually
  freezes: it still runs, but the VM does not respond to external
  requests such as Telnet or SSH until the QEMU window is visible on the
  desktop.

  This behavior is due to the work of the macOS App Nap function:
  
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap.html#//apple_ref/doc/uid/TP40013929-CH2-SW1

  It doesn't matter how the process is started -- as a background job or
  as a foreground shell process in case QEMU has a desktop window.

  My VM does not have a display output, only a serial line, most likely
  if the VM was using OpenGL, or playing sound (or any other App Nap
  triggers), then the problem would never have been detected.

  In my case only one starting way without this problem:
  sudo qemu-system-x86_64 -nodefaults \
  -cpu host -accel hvf -smp 1 -m 384 \
  -device virtio-blk-pci,drive=flash0 \
  -drive 
file=/vios-adventerprisek9-m.vmdk.SPA.156-1.T.vmdk,if=none,format=vmdk,id=flash0
 \
  -device e1000,netdev=local -netdev 
tap,id=local,ifname=tap0,script=no,downscript=no \
  -serial stdio -display none

  The typical way from the internet to disable App Nap doesn't work:
  defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

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

[Bug 1922430] Re: 3d accel does not take care of 1280x960 setting

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1922430

Title:
  3d accel does not take care of 1280x960 setting

Status in QEMU:
  Incomplete

Bug description:
  openSuse 15.2
  kde plasma 5.21.3, frameworks 5.80.0
  libvirt 7.0.0
  qemu 5.2.0
  virgl renderer 0.8.2

  here is my invocation

  qemu-kvm -enable-kvm \
  -m 2048 -smp 2 -cpu host \
  -device virtio-vga,virgl=on -display gtk,gl=on \
  -device usb-ehci \
  -device usb-kbd \
  -device usb-mouse \
  -device usb-tablet \
  -device ich9-intel-hda \
  -device hda-duplex,audiodev=snd0 \
  -audiodev pa,id=snd0 \
  -device usb-host,vendorid=0x046d,productid=0x08e5 \
  -boot menu=on \
  -nic bridge \
  ~/QEMU_VM/android_x86_7.1-r5.img \

  in the kernel command there is "vga=1280x960"

  with "-device qxl" no problem. I get immediately a  window of size
  1280x960.

  with "-device virtio-vga,virgl=on -display gtk,gl=on"

  i get a tiny window.

  i must uncheck "zoom to fit" to get a window of size 1280x960.

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

[Bug 1923583] Re: colo: pvm flush failed after svm killed

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1923583

Title:
  colo: pvm flush failed after svm killed

Status in QEMU:
  Incomplete

Bug description:
  Hi,
 Primary vm flush failed after killing svm, which leads primary vm guest 
filesystem unavailable.

  qemu versoin: 5.2.0
  host/guest os: CentOS Linux release 7.6.1810 (Core)

  Reproduce steps:
  1. create colo vm following 
https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt
  2. kill secondary vm (don't remove nbd child from quorum on primary vm)and 
wait for a minute. the interval depends on guest os.
  result: primary vm file system shutdown because of flush cache error.

  After serveral tests, I found that qemu-5.0.0 worked well, and it's
  the commit
  
https://git.qemu.org/?p=qemu.git;a=commit;h=883833e29cb800b4d92b5d4736252f4004885191(block:
  Flush all children in generic code) leads this change, and both
  virtio-blk and ide turned out to be bad.

  I think it's nbd(replication) flush failed leads bdrv_co_flush(quorum_bs) 
failed, here is the call stack.
  #0  bdrv_co_flush (bs=0x56242b3cc0b0=nbd_bs) at ../block/io.c:2856
  #1  0x562428b0f399 in bdrv_co_flush (bs=0x56242b3c7e00=replication_bs) at 
../block/io.c:2920
  #2  0x562428b0f399 in bdrv_co_flush (bs=0x56242a4ad800=quorum_bs) at 
../block/io.c:2920
  #3  0x562428b70d56 in blk_do_flush (blk=0x56242a4ad4a0) at 
../block/block-backend.c:1672
  #4  0x562428b70d87 in blk_aio_flush_entry (opaque=0x7fd0980073f0) at 
../block/block-backend.c:1680
  #5  0x562428c5f9a7 in coroutine_trampoline (i0=-1409269904, i1=32721) at 
../util/coroutine-ucontext.c:173

  While i am not sure whether i use colo inproperly? Can we assume that
  nbd child of quorum immediately removed right after svm crashed? Or
  it's really a bug? Does the following patch fix? Help is needed!
  Thanks a lot！

  diff --git a/block/quorum.c b/block/quorum.c
  index cfc1436..f2c0805 100644
  --- a/block/quorum.c
  +++ b/block/quorum.c
  @@ -1279,7 +1279,7 @@ static BlockDriver bdrv_quorum = {
   .bdrv_dirname   = quorum_dirname,
   .bdrv_co_block_status   = quorum_co_block_status,
   
  -.bdrv_co_flush_to_disk  = quorum_co_flush,
  +.bdrv_co_flush  = quorum_co_flush,
   
   .bdrv_getlength = quorum_getlength,

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

[Bug 1922773] Re: RISCV32 illegal instruction exception

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1922773

Title:
  RISCV32 illegal instruction exception

Status in QEMU:
  Incomplete

Bug description:
  I'm running a machine learning model on qemu riscv32 and I ran into
  illegal instruction exception for some reason. I wasn't sure if this
  is a bug and if so whether it is related to zephyr or qemu, however
  I'll try to provide as much as information to get a better
  understanding.

  Here is the assembly code that I'm running:

  0x8000bd74 <+0>:  lw  a4,0(a0)
 0x8000bd76 <+2>:   lw  a5,8(a0)
 0x8000bd78 <+4>:   lw  a0,0(a4)
 0x8000bd7a <+6>:   lw  a1,0(a5)
 0x8000bd7c <+8>:   li  a3,0
 0x8000bd7e <+10>:  j   0x8000bda4 
 0x8000bd80 <+12>:  addia5,a3,-2
 0x8000bd84 <+16>:  li  a2,27
 0x8000bd86 <+18>:  bgeua2,a5,0x8000bdae 

  => 0x8000bd8a <+22>:  fmv.w.x fa5,zero
 0x8000bd8e <+26>:  sllia5,a3,0x5
 0x8000bd92 <+30>:  add a5,a5,a4
 0x8000bd94 <+32>:  sllia5,a5,0x2
 0x8000bd96 <+34>:  add a5,a5,a1
 0x8000bd98 <+36>:  fsw fa5,0(a5)
 0x8000bd9a <+38>:  addia4,a4,1
 0x8000bd9c <+40>:  li  a5,31
 0x8000bd9e <+42>:  bge a5,a4,0x8000bd80 

 0x8000bda2 <+46>:  addia3,a3,1
 0x8000bda4 <+48>:  li  a5,31
 0x8000bda6 <+50>:  blt a5,a3,0x8000bde0 

 0x8000bdaa <+54>:  li  a4,0
 0x8000bdac <+56>:  j   0x8000bd9c 
 0x8000bdae <+58>:  li  a5,1
 0x8000bdb0 <+60>:  bge a5,a4,0x8000bdd4 

 0x8000bdb4 <+64>:  li  a5,29
 0x8000bdb6 <+66>:  blt a5,a4,0x8000bdda 

 0x8000bdba <+70>:  li  a5,28
 0x8000bdbc <+72>:  mul a5,a3,a5
 0x8000bdc0 <+76>:  add a5,a5,a4
 0x8000bdc2 <+78>:  lui a2,0x4
 0x8000bdc6 <+82>:  addia2,a2,-58 # 0x3fc6
 0x8000bdca <+86>:  add a5,a5,a2
 0x8000bdcc <+88>:  sllia5,a5,0x2
 0x8000bdce <+90>:  add a5,a5,a0
 0x8000bdd0 <+92>:  flw fa5,0(a5)
 0x8000bdd2 <+94>:  j   0x8000bd8e 
 0x8000bdd4 <+96>:  fmv.w.x fa5,zero
 0x8000bdd8 <+100>: j   0x8000bd8e 
 0x8000bdda <+102>: fmv.w.x fa5,zero
 0x8000bdde <+106>: j   0x8000bd8e 
 0x8000bde0 <+108>: li  a0,0
 0x8000bde2 <+110>: ret

  My code breaks on line 0x8000bd8a and then the mcause register is
  loaded with value 0x02 which translates to illegal instruction. Please
  let me know if you need more information about this.

  I also posted this on ZephyrProject in case it is related to the
  Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026

  I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same
  code on qemu riscv64 and didn't have the same problem. Here is the
  assembly code that is generated for the same operation:

  => 0x8000b446 <+0>:   ld  a4,0(a0)
 0x8000b448 <+2>:   ld  a5,8(a0)
 0x8000b44a <+4>:   ld  a0,0(a4)
 0x8000b44c <+6>:   ld  a1,0(a5)
 0x8000b44e <+8>:   li  a3,0
 0x8000b450 <+10>:  j   0x8000b476 

 0x8000b452 <+12>:  addiw   a5,a3,-2
 0x8000b456 <+16>:  li  a2,27
 0x8000b458 <+18>:  bgeua2,a5,0x8000b480 

 0x8000b45c <+22>:  li  a2,0
 0x8000b460 <+26>:  slliw   a5,a3,0x5
 0x8000b464 <+30>:  addwa5,a5,a4
 0x8000b466 <+32>:  sllia5,a5,0x2
 0x8000b468 <+34>:  add a5,a5,a1
 0x8000b46a <+36>:  sw  a2,0(a5)
   

[Bug 1922391] Re: qemu-system-ppc assertion "!mr->container" failed

[Thomas Huth]

Philippe's fix has been merged here:
https://gitlab.com/qemu-project/qemu/-/commit/03b3542ac93cb196bf6a6

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

Title:
  qemu-system-ppc assertion "!mr->container" failed

Status in QEMU:
  Fix Released

Bug description:
  Hi,

  I'm trying to run the NetBSD/macppc 8.2 installer (which is 32-bit ppc) in 
qemu-system-ppc version 5.2.0, and I'm hitting this assertion failure
  quite a bit into the "unpacking sets" part of the installation procedure,
  unpacking from the install iso image.

  Qemu is run on a NetBSD/amd64 9.1 host system.

  The asert message from qemu is

  assertion "!mr->container" failed: file "../softmmu/memory.c", line
  1739, function "memory_region_finalize"

  The stack backtrace from the core file (when built with debug symbols)
  is

  Core was generated by `qemu-system-ppc'.
  Program terminated with signal SIGABRT, Aborted.
  #0  0x7a8f2596791a in _lwp_kill () from /usr/lib/libc.so.12
  [Current thread is 1 (process 1)]
  (gdb) where
  #0  0x7a8f2596791a in _lwp_kill () from /usr/lib/libc.so.12
  #1  0x7a8f259671ca in abort () from /usr/lib/libc.so.12
  #2  0x7a8f258a8507 in __assert13 () from /usr/lib/libc.so.12
  #3  0x3e79d8a0 in memory_region_finalize (obj=)
  at ../softmmu/memory.c:1739
  #4  0x3e87aacc in object_deinit (type=0x7a8f2c280780, 
  obj=) at ../qom/object.c:671
  #5  object_finalize (data=0x7a8f2b62baa0) at ../qom/object.c:685
  #6  object_unref (objptr=0x7a8f2b62baa0) at ../qom/object.c:1183
  #7  0x3e87aa96 in object_property_del_all (obj=0x7a8f2b629000)
  at ../qom/object.c:623
  #8  object_finalize (data=0x7a8f2b629000) at ../qom/object.c:684
  #9  object_unref (objptr=0x7a8f2b629000) at ../qom/object.c:1183
  #10 0x3e79ab6b in memory_region_unref (mr=)
  at ../softmmu/memory.c:1787
  #11 0x3e7d8eb4 in address_space_unmap (
  as=as@entry=0x3f4731a0 , buffer=, 
  len=, is_write=, access_len=)
  at ../softmmu/physmem.c:3222
  #12 0x3e66389a in dma_memory_unmap (access_len=, 
  dir=, len=, buffer=, 
  as=)
  at /usr/pkgsrc/emulators/qemu/work/qemu-5.2.0/include/sysemu/dma.h:145
  #13 pmac_ide_atapi_transfer_cb (opaque=0x7a8f2ab4aef0, ret=)
  at ../hw/ide/macio.c:122
  #14 0x3e5b22a0 in dma_complete (ret=0, dbs=0x7a8f2bb4d380)
  at ../softmmu/dma-helpers.c:120
  #15 dma_blk_cb (opaque=0x7a8f2bb4d380, ret=0) at ../softmmu/dma-helpers.c:138
  #16 0x3e864ef7 in blk_aio_complete (acb=0x7a8f2af2be90)
  at ../block/block-backend.c:1412
  #17 0x3e9a9be1 in coroutine_trampoline (i0=, 
  i1=) at ../util/coroutine-ucontext.c:173
  #18 0x7a8f25864150 in ?? () from /usr/lib/libc.so.12
  Backtrace stopped: Cannot access memory at address 0x7a8e137ec000
  (gdb) 

  
  I start qemu with this small script:

  ---
  #!/bin/sh

  MEM=3g
  qemu-system-ppc \
  -M mac99,via=pmu \
  -m $MEM  \
  -nographic \
  -drive id=hda,format=raw,file=disk.img \
  -L pc-bios \
  -netdev user,id=net0,hostfwd=tcp::2223-:22,ipv6=off \
  -net nic,model=rtl8139,netdev=net0 \
  -boot d \
  -cdrom NetBSD-8.2-macppc.iso
  ---

  and boot the install kernel with "boot cd:ofwboot.xcf".  If someone wants
  to replicate this I can provide more detailed instructions to repeat the
  procedure I used to start the install.

  Any hints about what more to look for?

  Regards,

  - Håvard

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

[PATCH] accel/tcg: Align data dumped at end of TB

[Philippe Mathieu-Daudé]

To better visualize the data dumped at the end of a TB,
left-align it (padding it with 0).

Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/tcg/translate-all.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index ae7e873713a..387f3dc2303 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -2042,8 +2042,9 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
 int i;
 qemu_log("  data: [size=%d]\n", data_size);
 for (i = 0; i < data_size / sizeof(tcg_target_ulong); i++) {
-qemu_log("0x%08" PRIxPTR ":  .quad  0x%" TCG_PRIlx "\n",
- (uintptr_t)&rx_data_gen_ptr[i], rx_data_gen_ptr[i]);
+qemu_log("0x%08" PRIxPTR ":  .quad  0x%0*" TCG_PRIlx "\n",
+ (uintptr_t)&rx_data_gen_ptr[i],
+ 2 * sizeof(tcg_target_ulong), rx_data_gen_ptr[i]);
 }
 }
 qemu_log("\n");
-- 
2.26.3

[Bug 1922325] Re: s390x-virtio-gpu-ccw module unnecessary?

[Thomas Huth]

How did you run the configure script? The virtio-gpu-ccw device is part
of the qemu-system-s390x emulator, so unless you disabled that build,
the module will of course be there.

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

Title:
  s390x-virtio-gpu-ccw module unnecessary?

Status in QEMU:
  Incomplete

Bug description:
  Hi

  Test building latest 6.0.0 release candidate on x86_64 host. A new
  module has appeared:

  /usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so

  Unless I'm missing something obvious, it would appear to be only
  useful on s390x platform.

  Why would I need this? For me it doesn't seem to do much:

  $ nm -D /usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so
   w __cxa_finalize
   w __gmon_start__
   w _ITM_deregisterTMCloneTable
   w _ITM_registerTMCloneTable
  10f0 T qemu_module_dummy
  1100 T qemu_stamp_0d4aa0592256528f9885a56f182883665e60f8ec

  Bug or ... ?

  Thanks

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

[Bug 1920934] Re: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1920934

Title:
  Heap-use-after-free in io_writex / cputlb.c results in Linux kernel
  crashes

Status in QEMU:
  Incomplete

Bug description:
  qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0

  We've encountered that booting the Linux kernel in TCG mode, results
  in a racy heap-use-after-free. The bug can be detected by ASan [A],
  but in the majority of runs results in a crashing kernel [B].

  To reproduce, the following command line was used:

  $> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel
  arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1
  panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done

  The crashes in the kernel [B] appear to receive an interrupt in a code
  location where the instructions are periodically patched (via the
  jump_label infrastructure).

  [A]:
  = 


 
  ==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 


  READ of size 8 at 0x6190007fef50 thread T4


 
  [4.616506][T1] pci :00:02.0: reg 0x18: [mem 
0xfebf-0xfebf0fff]  

   
  [4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe 
pref]   

 
  [4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02   


 
  [4.701540][T1] pci :00:03.0: reg 0x10: [mem 
0xfebc-0xfebd]  

   
  [4.711076][T1] pci :00:03.0: reg 0x14: [io  0xc000-0xc03f]


 
  [4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb 
pref]   

 
  [4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)


 
  #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputl

[Bug 1920752] Re: USB SoundCard Passthrough not working on arm64

[Thomas Huth]

Closing as requested in comment #6

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

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

Title:
  USB SoundCard Passthrough not working on arm64

Status in QEMU:
  Invalid

Bug description:
  Hello,

  I am virtualizing a armhf guest on a aarch64 host and was to use my
  Sound Blaster USB Soundcard as passthrough.

  armhf Guest is: Debian Buster 
  aarch64 host is a jetson nano. KVM is enabled.

  Latest qemu is built from sources.
  The command I use for running is as follows:

  ../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu 
host,aarch64=off -enable-kvm  \
  -kernel vmlinuz-4.19.0-14-armmp-lpae  -initrd initrd.img-4.19.0-14-armmp-lpae 
-append 'root=/dev/vda2' \
  -device nec-usb-xhci -device usb-kbd  -device usb-mouse -device 
usb-host,hostbus=1,hostport=2.3  -serial stdio  \
  -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \
  -drive if=none,file=hda2.qcow2,format=qcow2,id=hd   -device 
virtio-blk-device,drive=hd   \
  -netdev user,id=mynet   -device virtio-net-device,netdev=mynet \
  -bios edk2-arm-code.fd -no-reboot

  
  Where are my lsusb -t shows:

  rreddy78@jetson-nano:~/Downloads$ lsusb -t
  /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M
  |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
  /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M
  |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
  |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M
  |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 
1.5M
  |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 
12M
  |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M

  Within the VM I can see the usb as follows

  rreddy78@debian:~$ lsusb -t
  /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
  /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
  |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M
  |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M

  
  Its looks like some passthrough as but it seems like only for

   _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid,
  12M

  I am not sure if passthrough  even works because this post I saw

  https://community.arm.com/developer/ip-products/system/f/embedded-
  forum/48031/usb-pass-through-in-qemu-command-line-for-arm-
  machines/168764#168764

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

[Bug 1914117] Re: Short files returned via FTP on Qemu with various architectures and OSes

[Thomas Huth]

Could we close this ticket now if there is a workaround in libslirp now?

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

Title:
  Short files returned via FTP on Qemu with various architectures and
  OSes

Status in QEMU:
  Incomplete

Bug description:
  
  Qemu 5.2 on Mac OS X Big Sur.

  I originally thought that it might be caused by the home-brew version of 
Qemu, but this evening I have removed the brew edition and compiled from 
scratch (using Ninja & Xcode compiler). 
  Still getting the same problem,.

  On the following architectures: 
  arm64, amd64 and sometimes i386 running NetBSD host OS; 
  i386 running OpenBSD host OS:

  I have seen a consistent problem with FTP returning short files. The
  file will be a couple of bytes too short. I do not believe this is a
  problem with the OS. Downloading the perl source code from CPAN does
  not work properly, nor does downloading bind from isc. I've tried this
  on different architectures as above.

  (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My
  gut feel is there is something not right on the Mac OS version of Qemu
  or a bug in 5.2 - obviously in the network layer somewhere. If you
  have anything you want me to try, please let me know - happy to help
  get a resolution.)

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

Re: [PULL 21/38] tcg/tci: Implement the disassembler properly

[Philippe Mathieu-Daudé]

Hi Richard,

On 3/17/21 4:34 PM, Richard Henderson wrote:
> Actually print arguments as opposed to simply the opcodes
> and, uselessly, the argument counts.  Reuse all of the helpers
> developed as part of the interpreter.
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> Signed-off-by: Richard Henderson 
> ---
>  meson.build   |   2 +-
>  include/tcg/tcg-opc.h |   2 -
>  disas/tci.c   |  61 -
>  tcg/tci.c | 283 ++
>  4 files changed, 284 insertions(+), 64 deletions(-)
>  delete mode 100644 disas/tci.c

> +/* Disassemble TCI bytecode. */
> +int print_insn_tci(bfd_vma addr, disassemble_info *info)
> +{

> +switch (op) {
> +case INDEX_op_br:
> +case INDEX_op_call:
> +case INDEX_op_exit_tb:
> +case INDEX_op_goto_tb:
> +tci_args_l(&tb_ptr, &ptr);
> +info->fprintf_func(info->stream, "%-12s  %p", op_name, ptr);
> +break;

I just realized ptr can be NULL:

  "tcg/tci: Implement goto_ptr"

  The check in tcg_prologue_init is disabled because TCI does
  want to use NULL to indicate exit, as opposed to branching to
  a real epilogue.

What about adding str_ptr (similar to str_c/str_r) to pretty print
the NULL case?

[Bug 1917184] Re: qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/314


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #314
   https://gitlab.com/qemu-project/qemu/-/issues/314

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

Title:
  qemu-user vm86() segfaults handling interrupt with ss:sp in same page
  as cs:ip

Status in QEMU:
  Expired

Bug description:
  When using qemu-i386 to run a program that uses vm86(), if the vm86
  code calls an interrupt while cs:ip and ss:sp both point within the
  same page, do_int tries to write to the page while it is not writable,
  causing a segfault.

  qemu version 5.2.0, x86-64 host.

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

[Bug 1916343] Re: -daemonize not working on macOS

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/313


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #313
   https://gitlab.com/qemu-project/qemu/-/issues/313

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

Title:
  -daemonize not working on macOS

Status in QEMU:
  Expired

Bug description:
  Basically e.g, if I try with below command on macOS:

  qemu-system-x86_64 \
 -m 4G \
 -vga virtio \
 -display default,show-cursor=on \
 -usb \
 -device usb-tablet \
 -machine type=q35,accel=hvf \
 -smp 2 \
 -drive file=ubuntu.qcow2,if=virtio -cpu max \
 -net nic -net 
user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 \
 -daemonize

  With this command, the QEMU processes hang there forever. I guess
  there is a bug when forking a child and kill the parent? Because when
  this issue occurs, there are actually 2 QEMU processes running

  ```
501 14952 14951   0  7:08PM ?? 0:00.00 (qemu-system-x86_)
501 14953 1   0  7:08PM ?? 0:00.03 qemu-system-x86_64 -m 4G 
-vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine 
type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic 
-net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize
501 14951 14626   0  7:08PM ttys0000:00.03 qemu-system-x86_64 -m 4G 
-vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine 
type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic 
-net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize
  ```

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

[Bug 1912934] Re: QEMU emulation of fmadds instruction on powerpc64le is buggy

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/312


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #312
   https://gitlab.com/qemu-project/qemu/-/issues/312

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

Title:
  QEMU emulation of fmadds instruction on powerpc64le is buggy

Status in QEMU:
  Expired

Bug description:
  The attached program test-fmadds.c tests the fmadds instruction on
  powerpc64le.

  Result on real hardware (POWER8E processor):
  $ ./a.out ; echo $?
  0

  Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04:
  $ ./a.out ; echo $?
  32

  Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04:
  $ ./a.out ; echo $?
  32

  Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that
  QEMU is NOT using the fmaf() or fma() function from the host system's
  libc; this function is working fine in glibc of the host system (see
  https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ).

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

[Bug 1705118] Re: qemu user mode: rt signals not implemented for sparc guests

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/311


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #311
   https://gitlab.com/qemu-project/qemu/-/issues/311

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

Title:
  qemu user mode: rt signals not implemented for sparc guests

Status in QEMU:
  Expired

Bug description:
  The documentation
   says that
  qemu in user mode supports POSIX signal handling.

  Catching SIGSEGV according to POSIX, however, does not work on
ppc, ppc64, ppc64le, s390x, sparc64.
  It does work, however, on
aarch64, alpha, arm, hppa, m68k, mips, mips64, sh4.

  How to reproduce:
  The attached program runs fine (exits with code 0) on
- real hardware Linux/PowerPC64 (in 32-bit and 64-bit mode),
- real hardware Linux/PowerPC64LE,
- qemu-system-s390x emulated Linux/s390x,
- real hardware Linux/SPARC64.
  $ gcc -O -Wall testsigsegv.c; ./a.out; echo $?
  0

  For ppc:
  $ powerpc-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc testsigsegv-ppc
  $ echo $?
  3

  For ppc64:
  $ powerpc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-ppc64
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc64 testsigsegv-ppc64
  $ echo $?
  3

  For ppc64le:
  $ powerpc64le-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-ppc64le
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc64le testsigsegv-ppc64le
  $ echo $?
  3

  For s390x:
  $ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-s390x
  $ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x
  $ echo $?
  3
  $ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c 
-DAVOID_LINUX_S390X_COMPAT -o testsigsegv-s390x-a
  $ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x-a
  $ echo $?
  0
  So, the test fails here because the Linux/s390x kernel omits the least
  significant 12 bits of the fault address in the 'si_addr' field. But
  qemu-s390x is not compatible with the Linux/s390x behaviour: it puts
  the complete fault address in the 'si_addr' field.

  For sparc64:
  $ sparc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-sparc64
  $ ~/inst-qemu/2.9.0/bin/qemu-sparc64 testsigsegv-sparc64
  Segmentation fault (core dumped)

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

Re: [PATCH v6 00/26] TCI fixes and cleanups

[Philippe Mathieu-Daudé]

On 5/3/21 1:57 AM, Richard Henderson wrote:
> Richard Henderson (26):
>   tcg: Combine dh_is_64bit and dh_is_signed to dh_typecode
>   tcg: Add tcg_call_flags
>   accel/tcg/plugin-gen: Drop inline markers
>   plugins: Drop tcg_flags from struct qemu_plugin_dyn_cb
>   accel/tcg: Add tcg call flags to plugins helpers
>   tcg: Store the TCGHelperInfo in the TCGOp for call
>   tcg: Add tcg_call_func
>   tcg: Build ffi data structures for helpers
>   tcg/tci: Improve tcg_target_call_clobber_regs
>   tcg/tci: Move call-return regs to end of tcg_target_reg_alloc_order
>   tcg/tci: Use ffi for calls
>   tcg/tci: Reserve r13 for a temporary
>   tcg/tci: Emit setcond before brcond
>   tcg/tci: Remove tci_write_reg
>   tcg/tci: Change encoding to uint32_t units
>   tcg/tci: Implement goto_ptr
>   tcg/tci: Implement movcond
>   tcg/tci: Implement andc, orc, eqv, nand, nor
>   tcg/tci: Implement extract, sextract
>   tcg/tci: Implement clz, ctz, ctpop
>   tcg/tci: Implement mulu2, muls2
>   tcg/tci: Implement add2, sub2
>   tcg/tci: Split out tci_qemu_ld, tci_qemu_st

Patches 1 to 23:
Tested-by: Philippe Mathieu-Daudé 
(using parisc host).

[Bug 1922430] Re: 3d accel does not take care of 1280x960 setting

[promeneur]

done

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

Title:
  3d accel does not take care of 1280x960 setting

Status in QEMU:
  Invalid

Bug description:
  openSuse 15.2
  kde plasma 5.21.3, frameworks 5.80.0
  libvirt 7.0.0
  qemu 5.2.0
  virgl renderer 0.8.2

  here is my invocation

  qemu-kvm -enable-kvm \
  -m 2048 -smp 2 -cpu host \
  -device virtio-vga,virgl=on -display gtk,gl=on \
  -device usb-ehci \
  -device usb-kbd \
  -device usb-mouse \
  -device usb-tablet \
  -device ich9-intel-hda \
  -device hda-duplex,audiodev=snd0 \
  -audiodev pa,id=snd0 \
  -device usb-host,vendorid=0x046d,productid=0x08e5 \
  -boot menu=on \
  -nic bridge \
  ~/QEMU_VM/android_x86_7.1-r5.img \

  in the kernel command there is "vga=1280x960"

  with "-device qxl" no problem. I get immediately a  window of size
  1280x960.

  with "-device virtio-vga,virgl=on -display gtk,gl=on"

  i get a tiny window.

  i must uncheck "zoom to fit" to get a window of size 1280x960.

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

[Bug 1922430] Re: 3d accel does not take care of 1280x960 setting

[Thomas Huth]

Ticket has been moved here (thanks!):
https://gitlab.com/qemu-project/qemu/-/issues/315
... so I'm closing this on Launchpad now.

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #315
   https://gitlab.com/qemu-project/qemu/-/issues/315

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

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

Title:
  3d accel does not take care of 1280x960 setting

Status in QEMU:
  Invalid

Bug description:
  openSuse 15.2
  kde plasma 5.21.3, frameworks 5.80.0
  libvirt 7.0.0
  qemu 5.2.0
  virgl renderer 0.8.2

  here is my invocation

  qemu-kvm -enable-kvm \
  -m 2048 -smp 2 -cpu host \
  -device virtio-vga,virgl=on -display gtk,gl=on \
  -device usb-ehci \
  -device usb-kbd \
  -device usb-mouse \
  -device usb-tablet \
  -device ich9-intel-hda \
  -device hda-duplex,audiodev=snd0 \
  -audiodev pa,id=snd0 \
  -device usb-host,vendorid=0x046d,productid=0x08e5 \
  -boot menu=on \
  -nic bridge \
  ~/QEMU_VM/android_x86_7.1-r5.img \

  in the kernel command there is "vga=1280x960"

  with "-device qxl" no problem. I get immediately a  window of size
  1280x960.

  with "-device virtio-vga,virgl=on -display gtk,gl=on"

  i get a tiny window.

  i must uncheck "zoom to fit" to get a window of size 1280x960.

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

[Bug 1926952] Re: SPICE support broken with 6.0

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926952

Title:
  SPICE support broken with 6.0

Status in QEMU:
  Incomplete

Bug description:
  Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE
  for usb redirection Qemu won't start:

  qemu-system-x86_64: The console requires display DMABUF support.

  However just patching ui/console.c:

  if (flags & GRAPHIC_FLAGS_DMABUF &&
  !displaychangelistener_has_dmabuf(dcl)) {
  error_setg(errp, "The console requires display DMABUF support.");
  return false;
  }

  to always return true for dmabuf part works just fine:

  if (flags & GRAPHIC_FLAGS_DMABUF &&
  !displaychangelistener_has_dmabuf(dcl)) {
  error_setg(errp, "The console requires display DMABUF support.");
  return true;
  }

  This behavior wasn't in qemu 5.x version.

  To reproduce this bug need to use:

  /usr/bin/qemu-system-x86_64 \
  -machine q35 \
  -enable-kvm \
  -no-user-config \
  -nodefaults \
  -no-hpet \
  -display gtk,gl=on \
  -device 
pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 
\
  -device 
vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci:00/:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2
 \
  -spice port=5900,addr=127.0.0.1,disable-ticketing=on

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

[Bug 1926521] Re: QEMU-user ignores MADV_DONTNEED

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926521

Title:
  QEMU-user ignores MADV_DONTNEED

Status in QEMU:
  Incomplete

Bug description:
  There is comment int the code "This is a hint, so ignoring and returning 
success is ok"
  
https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941

  But it seems incorrect with the current state of Linux

  "man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html
  says the following:
  >>  These advice values do not influence the semantics
  >>   of the application (except in the case of MADV_DONTNEED)

  >> After a successful MADV_DONTNEED operation, the semantics
  >> of memory access in the specified region are changed:
  >> subsequent accesses of pages in the range will succeed,
  >> but will result in either repopulating the memory contents
  >> from the up-to-date contents of the underlying mapped file
  >> (for shared file mappings, shared anonymous mappings, and
  >> shmem-based techniques such as System V shared memory
  >> segments) or zero-fill-on-demand pages for anonymous
  >> private mappings.

  Some applications use this behavior clear memory and it
  would be nice to be able to run them on QEMU without
  workarounds.

  Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host.

  
  ```
  #include "assert.h"
  #include "stdio.h"
  #include 
  #include 

  int main() {
char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
assert(P);
*P = 'A';
while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) {
}
assert(*P == 0);

printf("OK\n");
  }

  /*
  gcc /tmp/madvice.c -o /tmp/madvice

  qemu-x86_64 /tmp/madvice
  madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted

  /tmp/madvice
  OK

  
  */

  ```

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

[Bug 1926497] Re: dp83932 stops working after a short while

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926497

Title:
  dp83932 stops working after a short while

Status in QEMU:
  Incomplete

Bug description:
  Following the instructions here
  https://wiki.qemu.org/Documentation/Platforms/m68k I was able to
  successfully install debian. However, running apt-get update stalls
  after the first 1-2MB.

  root@debian:~# apt-get update
  Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB]
  Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease
  Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 
kB]
  18% [2 Packages 2,155 kB/8,735 kB 25%]

  After running apt-get update. I don't seem to be able to send any
  packets anymore. ping host lookups fail and a subsequent apt-get
  update makes no progress.

  I'm launching qemu with:

qemu-system-m68k -boot c \
   -M q800 -serial none -serial mon:stdio -m 1000M \
   -net nic,model=dp83932 -net user \
   -append "root=/dev/sda2 rw console=ttyS0 console=tty" \
   -kernel vmlinux-4.16.0-1-m68k \
   -initrd initrd.img-4.16.0-1-m68k \
   -drive file=m68k-deb10.qcow2,format=qcow2 \
   -nographic

  I see this with qemu v6.0.0-rc5

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

[Bug 1926782] Re: configure script --extra-cflags not passed to config-meson.cross

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926782

Title:
  configure script --extra-cflags not passed to config-meson.cross

Status in QEMU:
  Incomplete

Bug description:
  Since qemu 5.2, when building, the configure would not finish, but
  would return this error instead:

 qemu ../meson.build:852:2: ERROR: C header 'sasl/sasl.h' not found

  This is for a cross build, and I invoke qemu with the --extra-cflags
  and --extra-ldflags containing all the proper paths to the headers,
  libraries etc. It worked properly with qemu 3.1 to 5.1.

  After looking into the configure script, it seems that meson is passed
  the CFLAGS environment variable instead of QEMU_CFLAGS, and only the
  latter contains the --extra-cflags argument:

  echo "c_args = [${CFLAGS:+$(meson_quote $CFLAGS)}]" >> $cross

  Using the CFLAGS and LDFLAGS environment variable instead of --extra-
  cflags and --extra-ldflags fixes the issue.

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

[Bug 1926596] Re: qemu-monitor-event command gets stuck randomly

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Summary changed:

- qemu-monitor-event command stukcs randomly
+ qemu-monitor-event command gets stuck randomly

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

Title:
  qemu-monitor-event command gets stuck randomly

Status in QEMU:
  Incomplete

Bug description:
  We are using kvm virtualization on our servers, We use 
"qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them 
we use "qemu-monitor-event" command 
  For eg:-
  /usr/bin/virsh qemu-monitor-event VPSNAME --event 
"BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex

  the above command stucks randomly (backup completes but still it is
  waiting) and because of which other vms backup are stucked until we
  kill that process.

  Can you suggest how can we debug this further to find the actual
  issue.

  
  /usr/bin/virsh version

  Compiled against library: libvirt 4.5.0
  Using library: libvirt 4.5.0
  Using API: QEMU 4.5.0
  Running hypervisor: QEMU 2.0.0

  cat /etc/os-release
  NAME="CentOS Linux"
  VERSION="7 (Core)"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="7"
  PRETTY_NAME="CentOS Linux 7 (Core)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:7"
  HOME_URL="https://www.centos.org/";
  BUG_REPORT_URL="https://bugs.centos.org/";

  CENTOS_MANTISBT_PROJECT="CentOS-7"
  CENTOS_MANTISBT_PROJECT_VERSION="7"
  REDHAT_SUPPORT_PRODUCT="centos"
  REDHAT_SUPPORT_PRODUCT_VERSION="7"

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

[Bug 1926246] Re: chrome based apps can not be run under qemu user mode

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926246

Title:
  chrome based apps can not be run under qemu user mode

Status in QEMU:
  Incomplete

Bug description:
  chrome uses /proc/self/exe to fork render process.
  Here a simple code to reproduce the issue. It's output parent then child but 
failed with qemu: unknown option 'type=renderer'.

  Maybe we can modify exec syscall to replace /proc/self/exe to the real
  path.

  //gcc -o self self.c 
  #include 
  #include 
  #include 
  int main(int argc, char** argv) {
if(argc==1){
  printf ("parent\n");
if ( fork() == 0 )
  {
  return execl("/proc/self/exe","/proc/self/exe", 
"--type=renderer",NULL);
  }
} else {
  printf ("child\n");
}
return 0;
  }

  similar reports:
  https://github.com/AppImage/AppImageKit/issues/965  
  https://github.com/golang/go/issues/42080  

  Workardound:
  compile chrome or your chrome based app with a patch to 
content/common/child_process_host_impl.cc:GetChildPath, get the realpath of 
/proc/self/exe:  

  diff --git a/content/common/child_process_host_impl.cc 
b/content/common/child_process_host_impl.cc
  index bc78aba80ac8..9fab74d3bae8 100644
  --- a/content/common/child_process_host_impl.cc
  +++ b/content/common/child_process_host_impl.cc
  @@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) {
   #if defined(OS_LINUX)
 // Use /proc/self/exe rather than our known binary path so updates
 // can't swap out the binary from underneath us.
  -  if (child_path.empty() && flags & CHILD_ALLOW_SELF)
  -child_path = base::FilePath(base::kProcSelfExe);
  +  if (child_path.empty() && flags & CHILD_ALLOW_SELF) {
  +if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) {
  +  NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << ".";
  +  child_path = base::FilePath(base::kProcSelfExe);
  +}
  +  }
   #endif

 // On most platforms, the child executable is the same as the
  current

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

[Bug 1924912] Re: VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1924912

Title:
  VirtIO drivers don't work on Windows: "GLib: Too many handles to wait
  for!" crash

Status in QEMU:
  Incomplete

Bug description:
  I ran SerenityOS  out of WSL2
  with native Windows QEMU. The system runs fine on the Linux QEMU (with
  Windows X-Server). However, with Windows QEMU I get a hard crash after
  the following output:

  ```
  [#0 colonel(0:0)]: Scheduler[0]: idle loop running
  [init_stage2(2:2)]: PCI [:00:00:00] PCI::ID [8086:1237]
  [init_stage2(2:2)]: PCI [:00:01:00] PCI::ID [8086:7000]
  [init_stage2(2:2)]: PCI [:00:01:01] PCI::ID [8086:7010]
  [init_stage2(2:2)]: PCI [:00:01:02] PCI::ID [8086:7020]
  [init_stage2(2:2)]: PCI [:00:01:03] PCI::ID [8086:7113]
  [init_stage2(2:2)]: PCI [:00:02:00] PCI::ID [1234:]
  [init_stage2(2:2)]: PCI [:00:03:00] PCI::ID [8086:2922]
  [init_stage2(2:2)]: PCI [:00:04:00] PCI::ID [1af4:1003]
  [init_stage2(2:2)]: PCI [:00:05:00] PCI::ID [1af4:1005]
  [init_stage2(2:2)]: PCI [:00:06:00] PCI::ID [8086:100e]
  [#0 init_stage2(2:2)]: BXVGA: framebuffer @ P0xf800
  [#0 init_stage2(2:2)]: BXVGADevice resolution set to 1024x768 (pitch=4096)
  [init_stage2(2:2)]: UHCI: Controller found PCI::ID [8086:7020] @ PCI 
[:00:01:02]
  [init_stage2(2:2)]: UHCI: I/O base IO c080
  [init_stage2(2:2)]: UHCI: Interrupt line: 11
  [#0 init_stage2(2:2)]: UHCI: Allocated framelist at physical address 
P0x00e4
  [#0 init_stage2(2:2)]: UHCI: Framelist is at virtual address V0xc115d000
  [#0 init_stage2(2:2)]: UHCI: QH(0xc115f000) @ 14946304: link_ptr=14946338, 
element_link_ptr=1
  [#0 init_stage2(2:2)]: UHCI: QH(0xc115f020) @ 14946336: link_ptr=14946370, 
element_link_ptr=1
  [#0 init_stage2(2:2)]: UHCI: QH(0xc115f040) @ 14946368: link_ptr=14946402, 
element_link_ptr=1
  [#0 init_stage2(2:2)]: UHCI: QH(0xc115f060) @ 14946400: link_ptr=14946434, 
element_link_ptr=1
  [#0 init_stage2(2:2)]: UHCI: QH(0xc115f080) @ 14946432: link_ptr=14958593, 
element_link_ptr=1
  [#0 init_stage2(2:2)]: UHCI: Reset completed
  [#0 init_stage2(2:2)]: UHCI: Started
  [#0 init_stage2(2:2)]: DMIExpose: SMBIOS 32bit Entry point @ P0x000f5870
  [#0 init_stage2(2:2)]: DMIExpose: Data table @ P0x000f5890
  [#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [:00:04:00]
  [#0 init_stage2(2:2)]: Trying to unregister unused handler (?)
  [#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported!
  [#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0
  qemu-system-i386.exe: warning: GLib: Too many handles to wait for!
  ```

  The lines starting with [ are SerenityOS output; QEMU warns "GLib: Too
  many handles to wait for!" and crashes right after (can't even Ctrl-C
  in the WSL command line, force-close in Windows necessary). A window
  is still spawned but as the OS already switched out of text mode, just
  a black screen is visible as QEMU crashes.

  I first thought this to be an issue with SerenityOS and reported it
  over there: . The
  kernel devs pointed out that this seems to be a VirtIO driver/device
  issue on the Windows build of QEMU, because the Serenity kernel tries
  to initialize VirtIO devices which apparently crashes QEMU. There will
  be mitigations from the SerenityOS side (by allowing to disable VirtIO
  on boot) but it would of course be great if QEMU handled this
  properly.

  Version info: Both QEMU 6.0.0-rc3 and 5.2.0 exhibit this issue.
  

[Bug 1926231] Re: SCSI passthrough of SATA cdrom -> errors & performance issues

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926231

Title:
  SCSI passthrough of SATA cdrom -> errors & performance issues

Status in QEMU:
  Incomplete

Bug description:
  qemu 5.0, compiled from git

  I am passing through a SATA cdrom via SCSI passthrough, with this
  libvirt XML:

  

  
  



  

  It seems to mostly work, I have written discs with it, except I am
  getting errors that cause reads to take about 5x as long as they
  should, under certain circumstances.  It appears to be based on the
  guest's read block size.

  I found that if on the guest I run, say `dd if=$some_large_file
  bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much
  is being read by a factor of about 2.  Also many kernel messages like
  this happen on the guest:

  [  190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=0s
  [  190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command 
[current] 
  [  190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated
  [  190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 
00 80 00
  [  190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 
0x0:(READ) flags 0x80700 phys_seg 5 prio class 0

  If I change to bs=131072 the errors stop and performance is normal.

  (262144 happens to be the block size ultimately used by md5sum, which
  is how I got here)

  I also ran strace on the qemu process while it was happening, and
  noticed SG_IO calls like this:

  21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  [etc]

  I suspect qemu is the culprit because I have tried a 4.19 guest kernel
  as well as a 5.9 one, with the same result.

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

[Bug 1926202] Re: qemu-user can't run some ppc binaries

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926202

Title:
  qemu-user can't run some ppc binaries

Status in QEMU:
  Incomplete

Bug description:
  qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc
  binaries.  It seems to have something to do with glibc for some Centos
  versions.  The problem is easiest to see with statically-linked
  binaries.

  The attached Dockerfile shows how to produce a ppc binary that will
  crash qemu-user.  Here is how to reproduce the problem:

  $ uname -m
  x86_64

  $ docker run --rm --privileged multiarch/qemu-user-static --reset -p
  yes

  $ docker build -t qemu-bug:centos -f Dockerfile.centos .

  $ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp
  /helloworld-centos.static.ppc .

  $ qemu-ppc-static --version
  qemu-ppc version 5.2.95 (v6.0.0-rc5)
  Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

  $ qemu-ppc-static ./helloworld-centos.static.ppc
  emu: uncaught target signal 4 (Illegal instruction) - core dumped
  [1]16678 illegal hardware instruction (core dumped)  qemu-ppc-static 
./helloworld-centos.static.ppc

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

[Bug 1925109] Re: usbredirparser: bulk transfer length exceeds limits

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1925109

Title:
  usbredirparser: bulk transfer length exceeds limits

Status in QEMU:
  Incomplete

Bug description:
  2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  host:
  Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld 
(GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +
  guest:
  win10 20H2
  usb device:
  Bus 002 Device 007: ID 0781:55ab SanDisk Corp.  SanDisk 3.2Gen1
  size 250G

  
https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32

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

[Bug 1925094] Re: DISCARD support for Crypto Block Devices

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1925094

Title:
  DISCARD support for Crypto Block Devices

Status in QEMU:
  Incomplete

Bug description:
  It appears that running `fstrim` or similar is useless when the VM is
  on a LUKS-encrypted device using QEMU's native LUKS support.

  Looking at the source, it seems that block/crypto.c lacks an
  implementation for bdrv_co_pdiscard, which probably needs to delegate
  to a per-crypto type discard helper.

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

[Bug 1924987] Re: Storage | Two decimal digits precision

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

** Tags added: storage

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

Title:
  Storage | Two decimal digits precision

Status in QEMU:
  Incomplete

Bug description:
  Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64

  Hello. A two decimal digits precision is most appropriated on systems
  whose storage capacities have to be saved. That is one of the reason
  why such precision is supported in the context of creation of virtual
  machines in several Unix/Linux virtualization platforms; virt-manager
  is one of them. That last exhibits virtual disks size values with such
  precision – 128.00 GiB – nevertheless it lacks yet a mention
  illustrating physical disks size values.

  Storage values exhibited in qemu-img and virt-manager are already
  according to a clear format; thus, values are not attached to their
  measure units (#value# #units#).

  $ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n 
'2,4p'
  file format: qcow2
  virtual size: 128 GiB (137438953472 bytes)
  disk size: 147 MiB

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

[Bug 1926174] Re: Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1926174

Title:
  Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM

Status in QEMU:
  Incomplete

Bug description:
  This weekend I tried to get a CloudReady (Chrome OS) VM running on
  qemu 5.2. This seems to wok quite well, performance seems to be great
  in fact. Only problem is mouse input.

  Using SDL display, there is no visible mouse unless I set "show-
  cursor=on". After that the mouse pointer flickers a bit and most of
  the time is displaced so I need to press below a button in order to
  hit it. After switching to fullscreen and back using ctrl-alt-f this
  effect seems to be fixed for a while but the mouse pointer does not
  reach all parts of the emulated screen anymore.

  Using SPICE instead the mouse pointer is drawn, but it is *very*
  laggy. In fact it is only drawn every few seconds so it is unusable
  but placement seems to be correct. Text input is instant, so general
  emulation speed is not an issue here.

  To reproduce, download the free image from
  https://www.neverware.com/freedownload#home-edition-install

  Then run one of the following commands:

  qemu-system-x86_64 -drive driver=raw,file=cloudready-
  free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-
  vga,virgl=on -display sdl,gl=on,show-cursor=on -usb -device usb-mouse
  -device intel-hda -device hda-duplex

  qemu-system-x86_64 -drive driver=raw,file=cloudready-
  free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-
  vga,virgl=on -display spice-app,gl=on -usb -device usb-mouse -device
  intel-hda -device hda-duplex

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

[Bug 1925966] Re: Win10 guest freezes randomly

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1925966

Title:
  Win10 guest freezes randomly

Status in QEMU:
  Incomplete

Bug description:
  In addition to bug #1916775, my Win10 Home guest freezes randomly and
  infrequently. Unlike bug ​#1916775, this is unrecoverable and I see on
  the host (Debian 4.19.171-2) via iotop that all disk IO has stopped.
  My only recourse is a hard reset of the guest.

  My setup uses PCI-pass-through graphics (GTX 1650), host cpu (Ryzen 7
  3800XT). It seems to occur more frequently (every few hours) after
  switching from "kvm=off,vendor=GenuineIntel" to "kvm=on" and maybe
  using 3 monitors rather than 2 on the pass-through graphics card
  further increases frequency. The switch to "kvm=on" was necessary to
  enable nested virtualization, which now works. It occurs whether or
  not I use the qcow disk drive.

  qemu-system-x86_64
    -cpu 
host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy
    -smp 8
    -rtc clock=host,base=localtime
    -machine type=q35,accel=kvm,kernel_irqchip=on
    -enable-kvm
    -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
    -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd
    -m 32G
    -usb
    -device usb-tablet
    -vga none
    -serial none
    -parallel none
    -boot cd
    -nographic
    -device usb-host,vendorid=0x045e,productid=0x00db
    -device usb-host,vendorid=0x1bcf,productid=0x0005
    -drive 
id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2
    -drive 
id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv
    -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on
    -device vfio-pci,host=09:00.1,addr=0x02.0x1
    -device vfio-pci,host=09:00.2,addr=0x02.0x2
    -device vfio-pci,host=09:00.3,addr=0x02.0x3
    -netdev tap,id=netid,ifname=taplan,script=no,downscript=no
    -device e1000,netdev=netid,mac=52:54:00:01:02:03

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

[PATCH v3 00/11] PS/2 controller related fixes

[Volker Rümelin]

This patch series fixes two different PS/2 mouse stream corruptions
and adds a feature that allows some old misbehaving DOS programs to
have a working keyboard. With the last few patches, the PS/2 con-
troller behaves more like a real controller.

v2:
Introduce the function kbd_pending() in a preliminary patch to ease
the review of patch "pckbd: correctly disable PS/2 communication",
as Phillipe suggested.

v3:
Patch "pckbd: correctly disable PS/2 communication" exposed a bug
in SeaBIOS. The updated patch keeps the relevant code. Until
SeaBIOS is fixed, the PS/2 controller command KBD_CCMD_KBD_DISABLE
must disable the keyboard interrupt.

In patch "pckbd: PS/2 keyboard throttle" in function
kbd_throttle_timeout() an unnecessary if statement was removed.
The KBD_STAT_OBF flag is never set when kbd_throttle_timeout()
gets called.

Volker Rümelin (11):
  ps2: fix mouse stream corruption
  ps2: don't raise an interrupt if queue is full
  ps2: don't deassert irq twice if queue is empty
  pckbd: split out interrupt line changing code
  pckbd: don't update OBF flags if KBD_STAT_OBF is set
  pckbd: PS/2 keyboard throttle
  pckbd: add state variable for interrupt source
  pckbd: add controller response queue
  pckbd: add function kbd_pending()
  pckbd: correctly disable PS/2 communication
  pckbd: remove duplicated keyboard and mouse defines

 hw/input/pckbd.c | 289 ++-
 hw/input/ps2.c   |  11 +-
 2 files changed, 221 insertions(+), 79 deletions(-)

--
2.26.2

[PATCH v3 01/11] ps2: fix mouse stream corruption

[Volker Rümelin]

Commit 7abe7eb294 "ps2: Fix mouse stream corruption due to lost data"
added code to avoid mouse stream corruptions but the calculation of
the needed free queue size was wrong. Fix this.

To reproduce, open a text file with the vim 7.3 32 bit for DOS exe-
cutable in a FreeDOS client started with -display sdl and move the
mouse around for a few seconds. You will quickly see erratic mouse
movements and unexpected mouse clicks. CuteMouse (ctmouse.exe) in
FreeDOS doesn't try to re-sync the mouse stream.

Fixes: 7abe7eb294 ("ps2: Fix mouse stream corruption due to lost data")
Signed-off-by: Volker Rümelin 
---
 hw/input/ps2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 72cdb80ae1..d9f79e8260 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -645,7 +645,8 @@ void ps2_keyboard_set_translation(void *opaque, int mode)
 
 static int ps2_mouse_send_packet(PS2MouseState *s)
 {
-const int needed = 3 + (s->mouse_type - 2);
+/* IMPS/2 and IMEX send 4 bytes, PS2 sends 3 bytes */
+const int needed = s->mouse_type ? 4 : 3;
 unsigned int b;
 int dx1, dy1, dz1;
 
-- 
2.26.2

[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1924914

Title:
  Running sway in a QEMU VM results in a GPU hang of the guest (virtio-
  gpu driver)

Status in QEMU:
  Incomplete

Bug description:
  System is Arch Linux (guest and host OS).

  Problem:

  Basically, when using sway on a guest and running certain applications
  via Xwayland (on the guest), the GUI will freeze and won't be usable
  anymore, I can still ssh to the guest and run commands.

  This is the command I use to run my guest:

  qemu-system-x86_64 -enable-kvm -cdrom
  ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga
  virtio -nic user,hostfwd=tcp::10022-:22

  This doesn't happen when I use X with i3-wm.

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

[PATCH v3 04/11] pckbd: split out interrupt line changing code

[Volker Rümelin]

Split out the interrupt line changing code from kbd_update_irq().
This is a preparation for the next patch. There is no functional
change.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index dde85ba6c6..90b33954a8 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -148,15 +148,34 @@ typedef struct KBDState {
 hwaddr mask;
 } KBDState;
 
-/* update irq and KBD_STAT_[MOUSE_]OBF */
 /* XXX: not generating the irqs if KBD_MODE_DISABLE_KBD is set may be
incorrect, but it avoids having to simulate exact delays */
-static void kbd_update_irq(KBDState *s)
+static void kbd_update_irq_lines(KBDState *s)
 {
 int irq_kbd_level, irq_mouse_level;
 
 irq_kbd_level = 0;
 irq_mouse_level = 0;
+
+if (s->status & KBD_STAT_OBF) {
+if (s->status & KBD_STAT_MOUSE_OBF) {
+if (s->mode & KBD_MODE_MOUSE_INT) {
+irq_mouse_level = 1;
+}
+} else {
+if ((s->mode & KBD_MODE_KBD_INT) &&
+!(s->mode & KBD_MODE_DISABLE_KBD)) {
+irq_kbd_level = 1;
+}
+}
+}
+qemu_set_irq(s->irq_kbd, irq_kbd_level);
+qemu_set_irq(s->irq_mouse, irq_mouse_level);
+}
+
+/* update irq and KBD_STAT_[MOUSE_]OBF */
+static void kbd_update_irq(KBDState *s)
+{
 s->status &= ~(KBD_STAT_OBF | KBD_STAT_MOUSE_OBF);
 s->outport &= ~(KBD_OUT_OBF | KBD_OUT_MOUSE_OBF);
 if (s->pending) {
@@ -166,16 +185,9 @@ static void kbd_update_irq(KBDState *s)
 if (s->pending == KBD_PENDING_AUX) {
 s->status |= KBD_STAT_MOUSE_OBF;
 s->outport |= KBD_OUT_MOUSE_OBF;
-if (s->mode & KBD_MODE_MOUSE_INT)
-irq_mouse_level = 1;
-} else {
-if ((s->mode & KBD_MODE_KBD_INT) &&
-!(s->mode & KBD_MODE_DISABLE_KBD))
-irq_kbd_level = 1;
 }
 }
-qemu_set_irq(s->irq_kbd, irq_kbd_level);
-qemu_set_irq(s->irq_mouse, irq_mouse_level);
+kbd_update_irq_lines(s);
 }
 
 static void kbd_update_kbd_irq(void *opaque, int level)
-- 
2.26.2

[PATCH v3 08/11] pckbd: add controller response queue

[Volker Rümelin]

Add a separate queue for PS/2 controller responses. The
responses no longer get queued in the keyboard or mouse queues.
The advantage of this can be seen after the next two patches,
where the guest can disable the PS/2 communication with keyboard
and mouse and still talk to the PS/2 controller.

Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index adce525b88..e9523e164f 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -132,11 +132,14 @@
 
 #define KBD_PENDING_KBD 1
 #define KBD_PENDING_AUX 2
+#define KBD_PENDING_CTRL_KBD0x04
+#define KBD_PENDING_CTRL_AUX0x08
 
 #define KBD_MIGR_TIMER_PENDING  0x1
 
 #define KBD_OBSRC_KBD   0x01
 #define KBD_OBSRC_MOUSE 0x02
+#define KBD_OBSRC_CTRL  0x04
 
 typedef struct KBDState {
 uint8_t write_cmd; /* if non zero, write data to port 60 is expected */
@@ -149,6 +152,7 @@ typedef struct KBDState {
 /* Bitmask of devices with data available.  */
 uint8_t pending;
 uint8_t obdata;
+uint8_t cbdata;
 void *kbd;
 void *mouse;
 QEMUTimer *throttle_timer;
@@ -199,12 +203,18 @@ static void kbd_update_irq(KBDState *s)
 if (s->pending) {
 s->status |= KBD_STAT_OBF;
 s->outport |= KBD_OUT_OBF;
-if (s->pending == KBD_PENDING_AUX) {
+if (s->pending & KBD_PENDING_CTRL_KBD) {
+s->obsrc = KBD_OBSRC_CTRL;
+} else if (s->pending & KBD_PENDING_CTRL_AUX) {
 s->status |= KBD_STAT_MOUSE_OBF;
 s->outport |= KBD_OUT_MOUSE_OBF;
-s->obsrc = KBD_OBSRC_MOUSE;
-} else {
+s->obsrc = KBD_OBSRC_CTRL;
+} else if (s->pending & KBD_PENDING_KBD) {
 s->obsrc = KBD_OBSRC_KBD;
+} else {
+s->status |= KBD_STAT_MOUSE_OBF;
+s->outport |= KBD_OUT_MOUSE_OBF;
+s->obsrc = KBD_OBSRC_MOUSE;
 }
 }
 kbd_update_irq_lines(s);
@@ -273,10 +283,21 @@ static uint64_t kbd_read_status(void *opaque, hwaddr addr,
 
 static void kbd_queue(KBDState *s, int b, int aux)
 {
-if (aux)
-ps2_queue(s->mouse, b);
-else
-ps2_queue(s->kbd, b);
+s->cbdata = b;
+s->pending &= ~KBD_PENDING_CTRL_KBD & ~KBD_PENDING_CTRL_AUX;
+s->pending |= aux ? KBD_PENDING_CTRL_AUX : KBD_PENDING_CTRL_KBD;
+kbd_safe_update_irq(s);
+}
+
+static uint8_t kbd_dequeue(KBDState *s)
+{
+uint8_t b = s->cbdata;
+
+s->pending &= ~KBD_PENDING_CTRL_KBD & ~KBD_PENDING_CTRL_AUX;
+if (s->pending) {
+kbd_update_irq(s);
+}
+return b;
 }
 
 static void outport_write(KBDState *s, uint32_t val)
@@ -386,6 +407,8 @@ static uint64_t kbd_read_data(void *opaque, hwaddr addr,
 s->obdata = ps2_read_data(s->kbd);
 } else if (s->obsrc & KBD_OBSRC_MOUSE) {
 s->obdata = ps2_read_data(s->mouse);
+} else if (s->obsrc & KBD_OBSRC_CTRL) {
+s->obdata = kbd_dequeue(s);
 }
 }
 
@@ -527,6 +550,7 @@ static const VMStateDescription vmstate_kbd = {
 VMSTATE_UINT32_V(migration_flags, KBDState, 4),
 VMSTATE_UINT32_V(obsrc, KBDState, 4),
 VMSTATE_UINT8_V(obdata, KBDState, 4),
+VMSTATE_UINT8_V(cbdata, KBDState, 4),
 VMSTATE_END_OF_LIST()
 },
 .subsections = (const VMStateDescription*[]) {
-- 
2.26.2

[PATCH v3 03/11] ps2: don't deassert irq twice if queue is empty

[Volker Rümelin]

Don't deassert the irq twice if the queue is empty. While the
second deassertion doesn't do any harm, it's unnecessary.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Volker Rümelin 
---
 hw/input/ps2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 55a81a0c51..4aee46a595 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -519,7 +519,9 @@ uint32_t ps2_read_data(PS2State *s)
 /* reading deasserts IRQ */
 s->update_irq(s->update_arg, 0);
 /* reassert IRQs if data left */
-s->update_irq(s->update_arg, q->count != 0);
+if (q->count) {
+s->update_irq(s->update_arg, 1);
+}
 }
 return val;
 }
-- 
2.26.2

[PATCH v3 05/11] pckbd: don't update OBF flags if KBD_STAT_OBF is set

[Volker Rümelin]

Don't update the OBF flags in the status register and the cor-
responding IRQ lines if KBD_STAT_OBF is set. Otherwise this
may change the PS/2 event type. If the guest ISR was already
scheduled, the changed event type will be rather surprising for
the guest.

This fixes a mouse event stream corruption. To reproduce the
problem start a FreeDOS 1.2 guest with -machine pc,accel=kvm
and -display gtk. The KVM in-kernel irqchip has to be enabled.
Now open a text file with edit.exe in the guest and hold down
the cursor right key and at the same time move the mouse around.
You will quickly notice erratic mouse movements and unexpected
mouse clicks.

A trace file shows the mouse event stream corruption. Guest
rip 0xce93 (f000:ce93) is the in al,0x60 instruction in the
seabios mouse ISR, guest rip 0xceca (f000:ceca) is the
in al,0x60 instruction in the seabios keyboard ISR.

qemu-system-x86-5659  [007]    280.971116:
 tracing_mark_write: pckbd_kbd_update_irq kbd=0 aux=1
 # gtk queues a mouse event

qemu-system-x86-5665  [000]    280.971121:
 kvm_exit: reason EXTERNAL_INTERRUPT rip 0x22da info 0 80fd
qemu-system-x86-5665  [000] d..1   280.971122:
 kvm_entry: vcpu 0, rip 0x22da
qemu-system-x86-5665  [000]    280.971123:
 kvm_exit: reason EXTERNAL_INTERRUPT rip 0x22da info 0 80fd
qemu-system-x86-5665  [000] d..1   280.971124:
 kvm_entry: vcpu 0, rip 0x22da
qemu-system-x86-5665  [000]    280.971126:
 kvm_exit: reason IO_INSTRUCTION rip 0x110c8c info 640008 0
qemu-system-x86-5665  [000]    280.971176:
 tracing_mark_write: pckbd_kbd_read_status 0x3d
 # KBD_STAT_OBF and KBD_STAT_MOUSE_OBF set, the mouse ISR will
 # read data from the PS/2 controller.

qemu-system-x86-5665  [000] d..1   280.971180:
 kvm_entry: vcpu 0, rip 0x110c8d
qemu-system-x86-5665  [000]    280.971191:
 kvm_exit: reason EXTERNAL_INTERRUPT rip 0x110c8d info 0 80f6
qemu-system-x86-5665  [000] d..1   280.971191:
 kvm_entry: vcpu 0, rip 0x110c8d
qemu-system-x86-5665  [000]    280.971193:
 kvm_exit: reason IO_INSTRUCTION rip 0xce93 info 600048 0
 # the mouse ISR wants to read data from the PS/2 controller

qemu-system-x86-5659  [007]    280.971231:
 tracing_mark_write: pckbd_kbd_update_irq kbd=1 aux=0
qemu-system-x86-5659  [007]    280.971238:
 tracing_mark_write: pckbd_kbd_update_irq kbd=1 aux=0
 # gtk queues a keyboard event 0xe0 0x4d (key right)

qemu-system-x86-5665  [000]    280.971257:
 tracing_mark_write: pckbd_kbd_update_irq kbd=0 aux=1
qemu-system-x86-5665  [000]    280.971262:
 tracing_mark_write: pckbd_kbd_update_irq kbd=1 aux=0
 # ps2_read_data() deasserts and reasserts the keyboard IRQ

qemu-system-x86-5665  [000]    280.971266:
 tracing_mark_write: pckbd_kbd_read_data 0xe0 kbd
 # -> the mouse ISR receives keyboard data

qemu-system-x86-5665  [000] d..1   280.971268:
 kvm_entry: vcpu 0, rip 0xce95
qemu-system-x86-5665  [000]    280.971269:
 kvm_exit: reason IO_INSTRUCTION rip 0xe828 info a00040 0
qemu-system-x86-5665  [000]    280.971270:
 kvm_ack_irq: irqchip PIC slave pin 12
qemu-system-x86-5665  [000] d..1   280.971270:
 kvm_entry: vcpu 0, rip 0xe82a
qemu-system-x86-5665  [000]    280.971271:
 kvm_exit: reason IO_INSTRUCTION rip 0xe82a info 200040 0
qemu-system-x86-5665  [000]    280.971271:
 kvm_ack_irq: irqchip PIC master pin 2
qemu-system-x86-5665  [000] d..1   280.971271:
 kvm_entry: vcpu 0, rip 0xe82c
qemu-system-x86-5665  [000]    280.971272:
 kvm_exit: reason PENDING_INTERRUPT rip 0x22da info 0 0
qemu-system-x86-5665  [000] d..1   280.971273:
 kvm_entry: vcpu 0, rip 0x22da
qemu-system-x86-5665  [000]    280.971274:
 kvm_exit: reason IO_INSTRUCTION rip 0x110c8c info 640008 0
qemu-system-x86-5665  [000]    280.971275:
 tracing_mark_write: pckbd_kbd_read_status 0x1d
qemu-system-x86-5665  [000] d..1   280.971276:
 kvm_entry: vcpu 0, rip 0x110c8d
qemu-system-x86-5665  [000]    280.971277:
 kvm_exit: reason IO_INSTRUCTION rip 0xceca info 600048 0
 # the keyboard ISR wants to read data from the PS/2 controller

qemu-system-x86-5665  [000]    280.971279:
 tracing_mark_write: pckbd_kbd_update_irq kbd=0 aux=1
qemu-system-x86-5665  [000]    280.971282:
 tracing_mark_write: pckbd_kbd_read_data 0x4d kbd
 # the keyboard ISR receives the second byte of the keyboard event

Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 91 
 1 file changed, 68 insertions(+), 23 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 90b33954a8..8336f4e4b3 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -139,6 +139,7 @@ typedef struct KBDState {
 bool outport_present;
 /* Bitmask of devices with data available.  */
 uint8_t pending;
+uint8_t obdata;
 void *kbd;
 void *mouse;
 
@@ -173,6 +174,13 @@ static void kbd_update_irq_lines(KBDState *s)
 qemu_set_irq(s->irq_mouse, irq_mouse_level);
 }
 
+static void kbd_deassert_irq(KBDState *s)
+{
+s->status &= ~(KBD_STAT_OB

[PATCH v3 06/11] pckbd: PS/2 keyboard throttle

[Volker Rümelin]

Limit the keyboard data rate to the serial link speed. Some old
DOS software relies on being able to read an incoming scan-code
more than once. After reading keyboard data from the i8042
controller, the guest software has 1ms to read the same data
again.

Use -global i8042.kbd-throttle=on to enable this feature.

To see how this patch works, start a FreeDOS 1.2 guest with the
qemu option -global i8042.kbd-throttle=on and open a text file
with the vim 7.3 32 bit for DOS executable. Then use the cursor
keys (not the cursor keys on the numeric keypad) to move through
the text. Without the kbd-throttle option enabled each keystroke
will move the cursor two positions.

Buglink: https://bugs.launchpad.net/bugs/1895363
Buglink: https://bugs.launchpad.net/bugs/1897568
Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 54 
 1 file changed, 54 insertions(+)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 8336f4e4b3..ebf08c7cb8 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -24,12 +24,14 @@
 
 #include "qemu/osdep.h"
 #include "qemu/log.h"
+#include "qemu/timer.h"
 #include "hw/isa/isa.h"
 #include "migration/vmstate.h"
 #include "hw/acpi/aml-build.h"
 #include "hw/input/ps2.h"
 #include "hw/irq.h"
 #include "hw/input/i8042.h"
+#include "hw/qdev-properties.h"
 #include "sysemu/reset.h"
 #include "sysemu/runstate.h"
 
@@ -131,17 +133,21 @@
 #define KBD_PENDING_KBD 1
 #define KBD_PENDING_AUX 2
 
+#define KBD_MIGR_TIMER_PENDING  0x1
+
 typedef struct KBDState {
 uint8_t write_cmd; /* if non zero, write data to port 60 is expected */
 uint8_t status;
 uint8_t mode;
 uint8_t outport;
+uint32_t migration_flags;
 bool outport_present;
 /* Bitmask of devices with data available.  */
 uint8_t pending;
 uint8_t obdata;
 void *kbd;
 void *mouse;
+QEMUTimer *throttle_timer;
 
 qemu_irq irq_kbd;
 qemu_irq irq_mouse;
@@ -206,6 +212,10 @@ static void kbd_safe_update_irq(KBDState *s)
 if (s->status & KBD_STAT_OBF) {
 return;
 }
+/* the throttle timer is pending and will call kbd_update_irq() */
+if (s->throttle_timer && timer_pending(s->throttle_timer)) {
+return;
+}
 if (s->pending) {
 kbd_update_irq(s);
 }
@@ -235,6 +245,15 @@ static void kbd_update_aux_irq(void *opaque, int level)
 kbd_safe_update_irq(s);
 }
 
+static void kbd_throttle_timeout(void *opaque)
+{
+KBDState *s = opaque;
+
+if (s->pending) {
+kbd_update_irq(s);
+}
+}
+
 static uint64_t kbd_read_status(void *opaque, hwaddr addr,
 unsigned size)
 {
@@ -356,6 +375,10 @@ static uint64_t kbd_read_data(void *opaque, hwaddr addr,
 if (status & KBD_STAT_MOUSE_OBF) {
 s->obdata = ps2_read_data(s->mouse);
 } else {
+if (s->throttle_timer) {
+timer_mod(s->throttle_timer,
+  qemu_clock_get_us(QEMU_CLOCK_VIRTUAL) + 1000);
+}
 s->obdata = ps2_read_data(s->kbd);
 }
 }
@@ -417,6 +440,9 @@ static void kbd_reset(void *opaque)
 s->outport_present = false;
 s->pending = 0;
 kbd_deassert_irq(s);
+if (s->throttle_timer) {
+timer_del(s->throttle_timer);
+}
 }
 
 static uint8_t kbd_outport_default(KBDState *s)
@@ -451,6 +477,18 @@ static const VMStateDescription vmstate_kbd_outport = {
 }
 };
 
+static int kbd_pre_save(void *opaque)
+{
+KBDState *s = opaque;
+
+s->migration_flags = 0;
+if (s->throttle_timer && timer_pending(s->throttle_timer)) {
+s->migration_flags |= KBD_MIGR_TIMER_PENDING;
+}
+
+return 0;
+}
+
 static int kbd_post_load(void *opaque, int version_id)
 {
 KBDState *s = opaque;
@@ -458,6 +496,9 @@ static int kbd_post_load(void *opaque, int version_id)
 s->outport = kbd_outport_default(s);
 }
 s->outport_present = false;
+if (s->migration_flags & KBD_MIGR_TIMER_PENDING) {
+kbd_throttle_timeout(s);
+}
 return 0;
 }
 
@@ -465,12 +506,14 @@ static const VMStateDescription vmstate_kbd = {
 .name = "pckbd",
 .version_id = 4,
 .minimum_version_id = 3,
+.pre_save = kbd_pre_save,
 .post_load = kbd_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT8(write_cmd, KBDState),
 VMSTATE_UINT8(status, KBDState),
 VMSTATE_UINT8(mode, KBDState),
 VMSTATE_UINT8(pending, KBDState),
+VMSTATE_UINT32_V(migration_flags, KBDState, 4),
 VMSTATE_UINT8_V(obdata, KBDState, 4),
 VMSTATE_END_OF_LIST()
 },
@@ -534,6 +577,7 @@ struct ISAKBDState {
 ISADevice parent_obj;
 
 KBDState kbd;
+bool kbd_throttle;
 MemoryRegion io[2];
 };
 
@@ -614,6 +658,10 @@ static void i8042_realizefn(DeviceState *dev, Error **errp)
 
 s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
 s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
+if (isa_s->kbd_throttle) {
+  

[PATCH v3 02/11] ps2: don't raise an interrupt if queue is full

[Volker Rümelin]

ps2_queue() behaves differently than the very similar functions
ps2_queue_2() to ps2_queue_4(). The first one calls update_irq()
even if the queue is full, the others don't. Change ps2_queue()
to be consistent with the others.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Volker Rümelin 
---
 hw/input/ps2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index d9f79e8260..55a81a0c51 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -212,6 +212,10 @@ void ps2_raise_irq(PS2State *s)
 
 void ps2_queue(PS2State *s, int b)
 {
+if (PS2_QUEUE_SIZE - s->queue.count < 1) {
+return;
+}
+
 ps2_queue_noirq(s, b);
 s->update_irq(s->update_arg, 1);
 }
-- 
2.26.2

[PATCH v3 11/11] pckbd: remove duplicated keyboard and mouse defines

[Volker Rümelin]

In 2005 the author of commit daa579632d "PS2 mouse and keyboard
separation (Paul Brook)" and 0e43e99c04 "PS2 mouse and keyboard
separation (Paul Brook)" separated the PS/2 controller code and
the PS/2 keyboard and mouse code. It seems he forgot to remove
a few defines. Remove them now.

Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 37 -
 1 file changed, 37 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index cf2f4ee27a..9675849cc1 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -61,21 +61,6 @@
 #define KBD_CCMD_RESET  0xFE/* Pulse bit 0 of the output port P2 = 
CPU reset. */
 #define KBD_CCMD_NO_OP  0xFF/* Pulse no bits of the output port 
P2. */
 
-/* Keyboard Commands */
-#define KBD_CMD_SET_LEDS   0xED/* Set keyboard leds */
-#define KBD_CMD_ECHO   0xEE
-#define KBD_CMD_GET_ID 0xF2/* get keyboard ID */
-#define KBD_CMD_SET_RATE   0xF3/* Set typematic rate */
-#define KBD_CMD_ENABLE 0xF4/* Enable scanning */
-#define KBD_CMD_RESET_DISABLE  0xF5/* reset and disable scanning */
-#define KBD_CMD_RESET_ENABLE   0xF6/* reset and enable scanning */
-#define KBD_CMD_RESET  0xFF/* Reset */
-
-/* Keyboard Replies */
-#define KBD_REPLY_POR  0xAA/* Power on reset */
-#define KBD_REPLY_ACK  0xFA/* Command ACK */
-#define KBD_REPLY_RESEND   0xFE/* Command NACK, send the cmd again */
-
 /* Status Register Bits */
 #define KBD_STAT_OBF   0x01/* Keyboard output buffer full */
 #define KBD_STAT_IBF   0x02/* Keyboard input buffer full */
@@ -108,28 +93,6 @@
  */
 #define KBD_OUT_ONES0xcc
 
-/* Mouse Commands */
-#define AUX_SET_SCALE110xE6/* Set 1:1 scaling */
-#define AUX_SET_SCALE210xE7/* Set 2:1 scaling */
-#define AUX_SET_RES0xE8/* Set resolution */
-#define AUX_GET_SCALE  0xE9/* Get scaling factor */
-#define AUX_SET_STREAM 0xEA/* Set stream mode */
-#define AUX_POLL   0xEB/* Poll */
-#define AUX_RESET_WRAP 0xEC/* Reset wrap mode */
-#define AUX_SET_WRAP   0xEE/* Set wrap mode */
-#define AUX_SET_REMOTE 0xF0/* Set remote mode */
-#define AUX_GET_TYPE   0xF2/* Get type */
-#define AUX_SET_SAMPLE 0xF3/* Set sample rate */
-#define AUX_ENABLE_DEV 0xF4/* Enable aux device */
-#define AUX_DISABLE_DEV0xF5/* Disable aux device */
-#define AUX_SET_DEFAULT0xF6
-#define AUX_RESET  0xFF/* Reset aux device */
-#define AUX_ACK0xFA/* Command byte ACK. */
-
-#define MOUSE_STATUS_REMOTE 0x40
-#define MOUSE_STATUS_ENABLED0x20
-#define MOUSE_STATUS_SCALE210x10
-
 #define KBD_PENDING_KBD_V3  0x01
 #define KBD_PENDING_AUX_V3  0x02
 #define KBD_PENDING_CTRL_KBD0x04
-- 
2.26.2

[PATCH v3 09/11] pckbd: add function kbd_pending()

[Volker Rümelin]

Replace reads of the variable s->pending with a call to a new
function kbd_pending() to ease the review of the next patch.
There is no functional change.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index e9523e164f..199367dcab 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -195,21 +195,28 @@ static void kbd_deassert_irq(KBDState *s)
 kbd_update_irq_lines(s);
 }
 
+static uint8_t kbd_pending(KBDState *s)
+{
+return s->pending;
+}
+
 /* update irq and KBD_STAT_[MOUSE_]OBF */
 static void kbd_update_irq(KBDState *s)
 {
+uint8_t pending = kbd_pending(s);
+
 s->status &= ~(KBD_STAT_OBF | KBD_STAT_MOUSE_OBF);
 s->outport &= ~(KBD_OUT_OBF | KBD_OUT_MOUSE_OBF);
-if (s->pending) {
+if (pending) {
 s->status |= KBD_STAT_OBF;
 s->outport |= KBD_OUT_OBF;
-if (s->pending & KBD_PENDING_CTRL_KBD) {
+if (pending & KBD_PENDING_CTRL_KBD) {
 s->obsrc = KBD_OBSRC_CTRL;
-} else if (s->pending & KBD_PENDING_CTRL_AUX) {
+} else if (pending & KBD_PENDING_CTRL_AUX) {
 s->status |= KBD_STAT_MOUSE_OBF;
 s->outport |= KBD_OUT_MOUSE_OBF;
 s->obsrc = KBD_OBSRC_CTRL;
-} else if (s->pending & KBD_PENDING_KBD) {
+} else if (pending & KBD_PENDING_KBD) {
 s->obsrc = KBD_OBSRC_KBD;
 } else {
 s->status |= KBD_STAT_MOUSE_OBF;
@@ -233,7 +240,7 @@ static void kbd_safe_update_irq(KBDState *s)
 if (s->throttle_timer && timer_pending(s->throttle_timer)) {
 return;
 }
-if (s->pending) {
+if (kbd_pending(s)) {
 kbd_update_irq(s);
 }
 }
@@ -266,7 +273,7 @@ static void kbd_throttle_timeout(void *opaque)
 {
 KBDState *s = opaque;
 
-if (s->pending) {
+if (kbd_pending(s)) {
 kbd_update_irq(s);
 }
 }
@@ -294,7 +301,7 @@ static uint8_t kbd_dequeue(KBDState *s)
 uint8_t b = s->cbdata;
 
 s->pending &= ~KBD_PENDING_CTRL_KBD & ~KBD_PENDING_CTRL_AUX;
-if (s->pending) {
+if (kbd_pending(s)) {
 kbd_update_irq(s);
 }
 return b;
-- 
2.26.2

[PATCH v3 07/11] pckbd: add state variable for interrupt source

[Volker Rümelin]

Currently there is only one flag to distinguish between two
interrupt sources and there are no available flags for more
sources. Add an internal state variable to store the interrupt
source. The next patch will introduce an additional interrupt
source. There is no functional change.

Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index ebf08c7cb8..adce525b88 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -135,12 +135,16 @@
 
 #define KBD_MIGR_TIMER_PENDING  0x1
 
+#define KBD_OBSRC_KBD   0x01
+#define KBD_OBSRC_MOUSE 0x02
+
 typedef struct KBDState {
 uint8_t write_cmd; /* if non zero, write data to port 60 is expected */
 uint8_t status;
 uint8_t mode;
 uint8_t outport;
 uint32_t migration_flags;
+uint32_t obsrc;
 bool outport_present;
 /* Bitmask of devices with data available.  */
 uint8_t pending;
@@ -198,6 +202,9 @@ static void kbd_update_irq(KBDState *s)
 if (s->pending == KBD_PENDING_AUX) {
 s->status |= KBD_STAT_MOUSE_OBF;
 s->outport |= KBD_OUT_MOUSE_OBF;
+s->obsrc = KBD_OBSRC_MOUSE;
+} else {
+s->obsrc = KBD_OBSRC_KBD;
 }
 }
 kbd_update_irq_lines(s);
@@ -368,18 +375,17 @@ static uint64_t kbd_read_data(void *opaque, hwaddr addr,
   unsigned size)
 {
 KBDState *s = opaque;
-uint8_t status = s->status;
 
-if (status & KBD_STAT_OBF) {
+if (s->status & KBD_STAT_OBF) {
 kbd_deassert_irq(s);
-if (status & KBD_STAT_MOUSE_OBF) {
-s->obdata = ps2_read_data(s->mouse);
-} else {
+if (s->obsrc & KBD_OBSRC_KBD) {
 if (s->throttle_timer) {
 timer_mod(s->throttle_timer,
   qemu_clock_get_us(QEMU_CLOCK_VIRTUAL) + 1000);
 }
 s->obdata = ps2_read_data(s->kbd);
+} else if (s->obsrc & KBD_OBSRC_MOUSE) {
+s->obdata = ps2_read_data(s->mouse);
 }
 }
 
@@ -496,6 +502,11 @@ static int kbd_post_load(void *opaque, int version_id)
 s->outport = kbd_outport_default(s);
 }
 s->outport_present = false;
+if (version_id < 4) {
+s->obsrc = s->status & KBD_STAT_OBF ?
+(s->status & KBD_STAT_MOUSE_OBF ? KBD_OBSRC_MOUSE : KBD_OBSRC_KBD) 
:
+0;
+}
 if (s->migration_flags & KBD_MIGR_TIMER_PENDING) {
 kbd_throttle_timeout(s);
 }
@@ -514,6 +525,7 @@ static const VMStateDescription vmstate_kbd = {
 VMSTATE_UINT8(mode, KBDState),
 VMSTATE_UINT8(pending, KBDState),
 VMSTATE_UINT32_V(migration_flags, KBDState, 4),
+VMSTATE_UINT32_V(obsrc, KBDState, 4),
 VMSTATE_UINT8_V(obdata, KBDState, 4),
 VMSTATE_END_OF_LIST()
 },
-- 
2.26.2

[PATCH v3 10/11] pckbd: correctly disable PS/2 communication

[Volker Rümelin]

Currently the PS/2 controller command KBD_CCMD_MOUSE_DISABLE
doesn't disable the PS/2 mouse communication at all, and the
PS/2 controller commands KBD_CCMD_KBD_DISABLE and
KBD_CCMD_KBD_ENABLE only disable and enable the keyboard
interrupt, which is very different from what a real PS/2
controller does. A guest may notice the difference.

Mask out pending data on disabled queues to correctly disable
the PS/2 controller communication.

Signed-off-by: Volker Rümelin 
---
 hw/input/pckbd.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 199367dcab..cf2f4ee27a 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -130,10 +130,12 @@
 #define MOUSE_STATUS_ENABLED0x20
 #define MOUSE_STATUS_SCALE210x10
 
-#define KBD_PENDING_KBD 1
-#define KBD_PENDING_AUX 2
+#define KBD_PENDING_KBD_V3  0x01
+#define KBD_PENDING_AUX_V3  0x02
 #define KBD_PENDING_CTRL_KBD0x04
 #define KBD_PENDING_CTRL_AUX0x08
+#define KBD_PENDING_KBD KBD_MODE_DISABLE_KBD/* 0x10 */
+#define KBD_PENDING_AUX KBD_MODE_DISABLE_MOUSE  /* 0x20 */
 
 #define KBD_MIGR_TIMER_PENDING  0x1
 
@@ -197,7 +199,7 @@ static void kbd_deassert_irq(KBDState *s)
 
 static uint8_t kbd_pending(KBDState *s)
 {
-return s->pending;
+return s->pending & (~s->mode | ~(KBD_PENDING_KBD | KBD_PENDING_AUX));
 }
 
 /* update irq and KBD_STAT_[MOUSE_]OBF */
@@ -354,6 +356,7 @@ static void kbd_write_command(void *opaque, hwaddr addr,
 break;
 case KBD_CCMD_MOUSE_ENABLE:
 s->mode &= ~KBD_MODE_DISABLE_MOUSE;
+kbd_safe_update_irq(s);
 break;
 case KBD_CCMD_TEST_MOUSE:
 kbd_queue(s, 0x00, 0);
@@ -433,6 +436,9 @@ static void kbd_write_data(void *opaque, hwaddr addr,
 switch(s->write_cmd) {
 case 0:
 ps2_write_keyboard(s->kbd, val);
+/* sending data to the keyboard reenables PS/2 communication */
+s->mode &= ~KBD_MODE_DISABLE_KBD;
+kbd_safe_update_irq(s);
 break;
 case KBD_CCMD_WRITE_MODE:
 s->mode = val;
@@ -459,6 +465,9 @@ static void kbd_write_data(void *opaque, hwaddr addr,
 break;
 case KBD_CCMD_WRITE_MOUSE:
 ps2_write_mouse(s->mouse, val);
+/* sending data to the mouse reenables PS/2 communication */
+s->mode &= ~KBD_MODE_DISABLE_MOUSE;
+kbd_safe_update_irq(s);
 break;
 default:
 break;
@@ -536,7 +545,16 @@ static int kbd_post_load(void *opaque, int version_id)
 s->obsrc = s->status & KBD_STAT_OBF ?
 (s->status & KBD_STAT_MOUSE_OBF ? KBD_OBSRC_MOUSE : KBD_OBSRC_KBD) 
:
 0;
+if (s->pending & KBD_PENDING_KBD_V3) {
+s->pending |= KBD_PENDING_KBD;
+}
+if (s->pending & KBD_PENDING_AUX_V3) {
+s->pending |= KBD_PENDING_AUX;
+}
 }
+/* clear all unused flags */
+s->pending &= KBD_PENDING_CTRL_KBD | KBD_PENDING_CTRL_AUX |
+  KBD_PENDING_KBD | KBD_PENDING_AUX;
 if (s->migration_flags & KBD_MIGR_TIMER_PENDING) {
 kbd_throttle_timeout(s);
 }
-- 
2.26.2

Re: [PATCH v3 00/11] PS/2 controller related fixes

[Philippe Mathieu-Daudé]

On 5/15/21 1:31 PM, Volker Rümelin wrote:
> This patch series fixes two different PS/2 mouse stream corruptions
> and adds a feature that allows some old misbehaving DOS programs to
> have a working keyboard. With the last few patches, the PS/2 con-
> troller behaves more like a real controller.
> 
> v2:
> Introduce the function kbd_pending() in a preliminary patch to ease
> the review of patch "pckbd: correctly disable PS/2 communication",
> as Phillipe suggested.
> 
> v3:
> Patch "pckbd: correctly disable PS/2 communication" exposed a bug
> in SeaBIOS. The updated patch keeps the relevant code. Until
> SeaBIOS is fixed, the PS/2 controller command KBD_CCMD_KBD_DISABLE
> must disable the keyboard interrupt.
> 
> In patch "pckbd: PS/2 keyboard throttle" in function
> kbd_throttle_timeout() an unnecessary if statement was removed.
> The KBD_STAT_OBF flag is never set when kbd_throttle_timeout()
> gets called.
> 
> Volker Rümelin (11):
>   ps2: fix mouse stream corruption
>   ps2: don't raise an interrupt if queue is full
>   ps2: don't deassert irq twice if queue is empty
>   pckbd: split out interrupt line changing code
>   pckbd: don't update OBF flags if KBD_STAT_OBF is set
>   pckbd: PS/2 keyboard throttle
>   pckbd: add state variable for interrupt source
>   pckbd: add controller response queue
>   pckbd: add function kbd_pending()
>   pckbd: correctly disable PS/2 communication
>   pckbd: remove duplicated keyboard and mouse defines

Zoltan, you might want to test this series with your Pegasos2
machine. It makes the keyboard detected correctly.

There is still a problem with the mouse interaction with the
host. Pressing Ctrl+Alt+G to ungrab the mouse, my host mouse
is still responding to guest events... (unrelated to this series).

Tested-by: Philippe Mathieu-Daudé 
(PPC Pegasos2 so far)

Re: [Bug 1914117] Re: Short files returned via FTP on Qemu with various architectures and OSes

[Chris Pinnock]

If it’s included in qemu when one downloads the sources I’m happy.

Sent from my iPhone

> On 15 May 2021, at 11:55, Thomas Huth <1914...@bugs.launchpad.net> wrote:
> 
> Could we close this ticket now if there is a workaround in libslirp now?
> 
> ** Changed in: qemu
>   Status: New => Incomplete
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1914117
> 
> Title:
>  Short files returned via FTP on Qemu with various architectures and
>  OSes
> 
> Status in QEMU:
>  Incomplete
> 
> Bug description:
> 
>  Qemu 5.2 on Mac OS X Big Sur.
> 
>  I originally thought that it might be caused by the home-brew version of 
> Qemu, but this evening I have removed the brew edition and compiled from 
> scratch (using Ninja & Xcode compiler). 
>  Still getting the same problem,.
> 
>  On the following architectures: 
>  arm64, amd64 and sometimes i386 running NetBSD host OS; 
>  i386 running OpenBSD host OS:
> 
>  I have seen a consistent problem with FTP returning short files. The
>  file will be a couple of bytes too short. I do not believe this is a
>  problem with the OS. Downloading the perl source code from CPAN does
>  not work properly, nor does downloading bind from isc. I've tried this
>  on different architectures as above.
> 
>  (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My
>  gut feel is there is something not right on the Mac OS version of Qemu
>  or a bug in 5.2 - obviously in the network layer somewhere. If you
>  have anything you want me to try, please let me know - happy to help
>  get a resolution.)
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions

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

Title:
  Short files returned via FTP on Qemu with various architectures and
  OSes

Status in QEMU:
  Incomplete

Bug description:
  
  Qemu 5.2 on Mac OS X Big Sur.

  I originally thought that it might be caused by the home-brew version of 
Qemu, but this evening I have removed the brew edition and compiled from 
scratch (using Ninja & Xcode compiler). 
  Still getting the same problem,.

  On the following architectures: 
  arm64, amd64 and sometimes i386 running NetBSD host OS; 
  i386 running OpenBSD host OS:

  I have seen a consistent problem with FTP returning short files. The
  file will be a couple of bytes too short. I do not believe this is a
  problem with the OS. Downloading the perl source code from CPAN does
  not work properly, nor does downloading bind from isc. I've tried this
  on different architectures as above.

  (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My
  gut feel is there is something not right on the Mac OS version of Qemu
  or a bug in 5.2 - obviously in the network layer somewhere. If you
  have anything you want me to try, please let me know - happy to help
  get a resolution.)

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

CFP Reminder: KVM Forum 2021

[Paolo Bonzini]

KVM Forum 2021 virtual experience
September 15-16, 2021

(All submissions must be received before May 31, 2021 at 23:59 PST)
=

KVM Forum is an annual event that presents a rare opportunity for
developers and users to discuss the state of Linux virtualization
technology and plan for the challenges ahead. This highly technical
conference unites the developers who drive KVM development and the users
who depend on KVM as part of their offerings, or to power their data
centers and clouds.

Sessions include updates on the state of the KVM virtualization stack,
planning for the future, and many opportunities for attendees to
collaborate. Over the years since its inclusion in the mainline kernel,
KVM has become a critical part of the FOSS cloud infrastructure. Come
join us in continuing to improve the KVM ecosystem.

Due to continuing COVID-19 safety concerns, KVM Forum 2021 will be
presented as a virtual experience. You will have the ability to network
with other attendees, attend sessions with live speaker Q&A, interact with
sponsors in real-time, and much more – all virtually, from anywhere.

We encourage you to submit and reach out to us should you have any
questions. The program committee may be contacted as a group via email:
kvm-forum-2021...@redhat.com.


SUGGESTED TOPICS


* Scalability and Optimization
* High Availability and Fault Tolerance
* Hardening and security
* Testing

KVM and the Linux Kernel:
* New Features and Architecture Ports
* Resource Management (CPU, I/O, Memory) and Scheduling
* Device Passthrough: VFIO, mdev, vDPA
* Network Virtualization
* Virtio and vhost

Virtual Machine Monitors and Management
* VMM Implementation: APIs, Live Migration, Performance Tuning, etc.
* Multi-process VMMs: vhost-user, vfio-user, QEMU Storage Daemon, SPDK
* QEMU without KVM: Hypervisor.framework, Windows Hypervisor Platform, etc.
* Managing KVM: Libvirt, KubeVirt, Kata Containers

Emulation
* New Devices, Boards and Architectures
* CPU Emulation and Binary Translation


SUBMITTING YOUR PROPOSAL


Abstracts due: May 31, 2021

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes.

Submit your proposal here:
https://events.linuxfoundation.org/kvm-forum/program/cfp/

Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation
proposal was accepted by August 17, 2021.

Speakers will receive a complimentary pass for the event. In case your
submission has multiple presenters, only the primary speaker for a
proposal will receive a complimentary event pass. For panel discussions,
all panelists will receive a complimentary event pass.


TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on work
that needs to be done, difficulties that haven't yet been solved, and on
decisions that other developers should be aware of. Summarizing recent
developments is okay but it should not be more than a small portion of
the overall talk.


END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request
full biographies if a panel is accepted.


HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2021_BOF

Let people you think who might be interested know about your BOF, and
encourage them to add their names to the wiki page as well. Please add
your ideas to the list before KVM Forum starts.


HOTEL / TRAVEL
--

This year's event will take place at the Conference Center Dublin. For
information on hotels close to the conference, please visit
https://events.linuxfoundation.org/kvm-forum/attend/venue-travel/.
Information on conference hotel blocks will be available later in
Spring 2021.


DATES TO REMEMBER
-

* CFP Closes: Monday, May 31 at 11:59 PM PST
* CFP Notifications: Monday, July 6
* Schedule Announcement: Thursday, Ju

[Bug 1926246] Re: chrome based apps can not be run under qemu user mode

[Wind Li]

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

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

Title:
  chrome based apps can not be run under qemu user mode

Status in QEMU:
  New

Bug description:
  chrome uses /proc/self/exe to fork render process.
  Here a simple code to reproduce the issue. It's output parent then child but 
failed with qemu: unknown option 'type=renderer'.

  Maybe we can modify exec syscall to replace /proc/self/exe to the real
  path.

  //gcc -o self self.c 
  #include 
  #include 
  #include 
  int main(int argc, char** argv) {
if(argc==1){
  printf ("parent\n");
if ( fork() == 0 )
  {
  return execl("/proc/self/exe","/proc/self/exe", 
"--type=renderer",NULL);
  }
} else {
  printf ("child\n");
}
return 0;
  }

  similar reports:
  https://github.com/AppImage/AppImageKit/issues/965  
  https://github.com/golang/go/issues/42080  

  Workardound:
  compile chrome or your chrome based app with a patch to 
content/common/child_process_host_impl.cc:GetChildPath, get the realpath of 
/proc/self/exe:  

  diff --git a/content/common/child_process_host_impl.cc 
b/content/common/child_process_host_impl.cc
  index bc78aba80ac8..9fab74d3bae8 100644
  --- a/content/common/child_process_host_impl.cc
  +++ b/content/common/child_process_host_impl.cc
  @@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) {
   #if defined(OS_LINUX)
 // Use /proc/self/exe rather than our known binary path so updates
 // can't swap out the binary from underneath us.
  -  if (child_path.empty() && flags & CHILD_ALLOW_SELF)
  -child_path = base::FilePath(base::kProcSelfExe);
  +  if (child_path.empty() && flags & CHILD_ALLOW_SELF) {
  +if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) {
  +  NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << ".";
  +  child_path = base::FilePath(base::kProcSelfExe);
  +}
  +  }
   #endif

 // On most platforms, the child executable is the same as the
  current

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

Re: [PULL v3 0/1] Rtd patches

[Philippe Mathieu-Daudé]

On 5/14/21 8:33 PM, Peter Maydell wrote:
> On Fri, 14 May 2021 at 12:13,  wrote:
>>
>> From: Marc-André Lureau 
>>
>> The following changes since commit 2d3fc4e2b069494b1e9e2e4a1e3de24cbc036426:
>>
>>   Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2021-05-12' 
>> into staging (2021-05-13 20:13:24 +0100)
>>
>> are available in the Git repository at:
>>
>>   g...@gitlab.com:marcandre.lureau/qemu.git tags/rtd-pull-request
>>
>> for you to fetch changes up to 73e6aec6522e1edd63f631c52577b49a39bc234f:
>>
>>   sphinx: adopt kernel readthedoc theme (2021-05-14 15:05:03 +0400)
>>
>> 
>> Pull request
>>
>> 
> 
> 
> Applied, thanks.

After rebasing I'm getting:

Program sphinx-build-3 found: YES
docs/meson.build:30: WARNING: /usr/bin/sphinx-build-3:
Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/home/phil/source/qemu/docs/conf.py", line 155, in 
import sphinx_rtd_theme
ModuleNotFoundError: No module named 'sphinx_rtd_theme'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/sphinx/config.py", line 361, in
eval_config_file
execfile_(filename, namespace)
  File "/usr/lib/python3.8/site-packages/sphinx/util/pycompat.py", line
81, in execfile_
exec(code, _globals)
  File "/home/phil/source/qemu/docs/conf.py", line 157, in 
raise ConfigError(
sphinx.errors.ConfigError: The Sphinx 'sphinx_rtd_theme' HTML theme was
not found.

Is python3-sphinx_rtd_theme a required dependency now?

$ lsb_release -d
Description:Fedora release 32 (Thirty Two)

Thanks,

Phil.

[PATCH 0/2] tests/acceptance: Add tests for the Pegasos2 machine

[Philippe Mathieu-Daudé]

Philippe Mathieu-Daudé (2):
  tests/acceptance: Ignore binary data sent on serial console
  tests/acceptance: Add tests for the Pegasos2 machine

 tests/acceptance/avocado_qemu/__init__.py |  7 +-
 tests/acceptance/machine_ppc_pegasos.py   | 98 +++
 2 files changed, 103 insertions(+), 2 deletions(-)
 create mode 100644 tests/acceptance/machine_ppc_pegasos.py

-- 
2.26.3

[PATCH 2/2] tests/acceptance: Add tests for the Pegasos2 machine

[Philippe Mathieu-Daudé]

Add a pair of tests for the Pegasos2 machine following the steps from:
https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html

  $ PEGASOS2_ROM_PATH=/tmp/pegasos2.rom AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
avocado --show=app,console,tesseract \
  run -t machine:pegasos2 tests/acceptance/
   (1/2) 
tests/acceptance/machine_ppc_pegasos.py:PPCPegasos2.test_rom_serial_console:
  console: PegasosII Boot Strap (c) 2002-2003 bplan GmbH
  console: Running on CPU PVR:000C0209
  console: Enable L1 ICache...  
  Done.
  console: Reading W83194 : 
  FAILED.
  console: Setting Front Side Bus to 133MHz...  
  FAILED.
  console: Configuring DDR...   
  Done.
  console: Configuring PCI0...  
  Done.
  console: Configuring PCI1...  
  Done.
  console: Configuring ETH...   
  Done.
  console: Releasing IDE reset ...  
  Done.
  console: Configuring Legacy Devices
  console: Initializing KBD...  
  Done.
  console: Testing 1000 Bytes, Pass:  Failed: 
  console: RAM TEST (fill linear)...
  Done.
  console: 
  console: SmartFirmware:
  console: cpu0: PowerPC,G4 CPUClock 599 Mhz BUSClock 133 Mhz (Version 
0x000C,0x0209)
  console: no/bad nvramrc - performing default startup script
  console: channel 1 unit 0 : atapi | QEMU DVD-ROM 
| 2.5+
  console: ATA device not present or not responding
  console: Welcome to SmartFirmware(tm) for bplan Pegasos2 version 1.1 
(20040405172512)
  PASS (5.23 s)
   (2/2) 
tests/acceptance/machine_ppc_pegasos.py:PPCPegasos2.test_morphos_cdrom_vga:
  ...
  console: Welcome to SmartFirmware(tm) for bplan Pegasos2 version 1.1 
(20040405172512)
  console: SmartFirmware(tm) Copyright 1996-2001 by CodeGen, Inc.
  console: All Rights Reserved.
  console: Pegasos BIOS Extensions Copyright 2001-2003 by bplan GmbH.
  console: All Rights Reserved.
  console: entering main read/eval loop...
  console: ok boot cd boot.img
  console: ISO-9660 filesystem:  System-ID: "MORPHOS"  Volume-ID: "MorphOSBoot"
  console: " flags=0x2 extent=0x20 size=0x1800
  console: Memory used before SYS_Init: 9MB
  console: PCI ATA/ATAPI Driver@2: PIO Mode 4
  console: PCI ATA/ATAPI Driver@2: UDMA Mode 5
  console: ide.device@2: QEMU QEMU DVD-ROM 
  console: ide.device@2:  CDRom , found, bootable
  tesseract: Ambient Screen 4: Saturday, 15 May 2021, 13:36:06 &
  tesseract: keymap
  tesseract: Albanian keyboard with 101/104 keys
  tesseract: ‘American keyboard with Greek input extension, 105 keys
  tesseract: Belarusian keyboard with 105 keys
  tesseract: Belgian keyboard with 105 keys J
  tesseract: British Apple keyboard
  tesseract: British keyboard with 105 keys
  tesseract: Bulgarian keyboard with 104 keys
  tesseract: Canadian keyboard with 105 keys
  tesseract: Colemak layout for keyboards with 101/104 keys
  tesseract: Croatian keyboard with 101/108 keys
  tesseract: Czech keyboard (QWERTY) with 101/104 keys
  tesseract: Czech keyboard (QWERTZ) with 101/104 keys
  tesseract: Danish keyboard with 105 keys
  PASS (28.56 s)
  RESULTS: PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
CANCEL 0
  JOB TIME   : 34.42 s

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/machine_ppc_pegasos.py | 98 +
 1 file changed, 98 insertions(+)
 create mode 100644 tests/acceptance/machine_ppc_pegasos.py

diff --git a/tests/acceptance/machine_ppc_pegasos.py 
b/tests/acceptance/machine_ppc_pegasos.py
new file mode 100644
index 000..d36e920ebde
--- /dev/null
+++ b/tests/acceptance/machine_ppc_pegasos.py
@@ -0,0 +1,98 @@
+# Functional tests for the Pegasos2 machine.
+#
+# Copyright (c) 2021 Philippe Mathieu-Daudé 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or later.
+# See the COPYING file in the top-level directory.
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+import os
+import time
+
+from avocado import skipUnless
+from avocado_qemu import Test
+from avocado_qemu import exec_command_and_wait_for_pattern
+from avocado_qemu import wait_for_console_pattern
+from tesseract_utils import tesseract_available, tesseract_ocr
+
+PIL_AVAILABLE = True
+try:
+from PIL import Image
+except ImportError:
+PIL_AVAILABLE = False
+
+
+@skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted code')
+@skipUnless(os.getenv('PEGASOS2_ROM_PATH'), 'PEGASOS2_ROM_PATH not available')
+class PPCPegasos2(Test):
+timeout = 60
+
+def test_rom_serial_console(self):
+"""
+:avocado: tags=arch:ppc
+:avocado: tags=

[PATCH 1/2] tests/acceptance: Ignore binary data sent on serial console

[Philippe Mathieu-Daudé]

If a guest sends binary data on the serial console, we get:

 File "tests/acceptance/avocado_qemu/__init__.py", line 92,
   in _console_interaction msg = console.readline().strip()
 File "/usr/lib64/python3.8/codecs.py", line 322,
   in decode (result, consumed) = self._buffer_decode(data, self.errors, final)
 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa9 in position 2: 
invalid start byte

Since we use the console with readline(), fix it the easiest
way possible: ignore binary data (all current tests compare
text string anyway).

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/avocado_qemu/__init__.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index 83b1741ec85..b55578e1cca 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -82,14 +82,17 @@ def _console_interaction(test, success_message, 
failure_message,
 assert not keep_sending or send_string
 if vm is None:
 vm = test.vm
-console = vm.console_socket.makefile()
+console = vm.console_socket.makefile(mode='rb', encoding='utf-8')
 console_logger = logging.getLogger('console')
 while True:
 if send_string:
 vm.console_socket.sendall(send_string.encode())
 if not keep_sending:
 send_string = None # send only once
-msg = console.readline().strip()
+try:
+msg = console.readline().decode().strip()
+except UnicodeDecodeError:
+msg = None
 if not msg:
 continue
 console_logger.debug(msg)
-- 
2.26.3

[PATCH v5 4/9] block: bdrv_reopen_parse_backing(): don't check frozen child

[Vladimir Sementsov-Ogievskiy]

bdrv_set_backing_noperm() takes care of it (actual check is in
bdrv_set_file_or_backing_noperm()), so we don't need to check it here.

While being here, improve error message a bit.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c| 14 +-
 tests/qemu-iotests/245 |  8 
 2 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/block.c b/block.c
index 4e18bc3177..bfa497813b 100644
--- a/block.c
+++ b/block.c
@@ -4283,19 +4283,7 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
"an implicit backing file", bs->node_name);
 return -EPERM;
 }
-/*
- * Check if the backing link that we want to replace is frozen.
- * Note that
- * bdrv_filter_or_cow_child(overlay_bs) == overlay_bs->backing,
- * because we know that overlay_bs == bs, and that @bs
- * either is a filter that uses ->backing or a COW format BDS
- * with bs->drv->supports_backing == true.
- */
-if (bdrv_is_backing_chain_frozen(overlay_bs,
- child_bs(overlay_bs->backing), errp))
-{
-return -EPERM;
-}
+
 reopen_state->replace_backing_bs = true;
 reopen_state->old_backing_bs = bs->backing ? bs->backing->bs : NULL;
 ret = bdrv_set_backing_noperm(bs, new_backing_bs, set_backings_tran,
diff --git a/tests/qemu-iotests/245 b/tests/qemu-iotests/245
index fc5297e268..c7d671366a 100755
--- a/tests/qemu-iotests/245
+++ b/tests/qemu-iotests/245
@@ -878,7 +878,7 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 
 # We can't remove hd1 while the stream job is ongoing
 opts['backing'] = None
-self.reopen(opts, {}, "Cannot change 'backing' link from 'hd0' to 
'hd1'")
+self.reopen(opts, {}, "Cannot change frozen 'backing' link from 'hd0' 
to 'hd1'")
 
 self.vm.run_job('stream0', auto_finalize = False, auto_dismiss = True)
 
@@ -910,7 +910,7 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 # We can't remove hd2 while the stream job is ongoing
 opts['backing']['backing'] = None
 self.reopen(opts['backing'], {'read-only': False},
-"Cannot change 'backing' link from 'hd1' to 'hd2'")
+"Cannot change frozen 'backing' link from 'hd1' to 'hd2'")
 
 # We can detach hd1 from hd0 because it doesn't affect the stream job
 opts['backing'] = None
@@ -933,11 +933,11 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 
 # We can't remove hd2 while the commit job is ongoing
 opts['backing']['backing'] = None
-self.reopen(opts, {}, "Cannot change 'backing' link from 'hd1' to 
'hd2'")
+self.reopen(opts, {}, "Cannot change frozen 'backing' link from 'hd1' 
to 'hd2'")
 
 # We can't remove hd1 while the commit job is ongoing
 opts['backing'] = None
-self.reopen(opts, {}, "Cannot change 'backing' link from 'hd0' to 
'hd1'")
+self.reopen(opts, {}, "Cannot change frozen 'backing' link from 'hd0' 
to 'hd1'")
 
 event = self.vm.event_wait(name='BLOCK_JOB_READY')
 self.assert_qmp(event, 'data/device', 'commit0')
-- 
2.29.2

[PATCH v5 7/9] block: BDRVReopenState: drop replace_backing_bs field

[Vladimir Sementsov-Ogievskiy]

It's used only in bdrv_reopen_commit(). "backing" is covered by the
loop through all children except for case when we removed backing child
during reopen.

Make it more obvious and drop extra boolean field: qdict_del will not
fail if there is no such entry.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/block.h |  1 -
 block.c   | 10 --
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/include/block/block.h b/include/block/block.h
index 82185965ff..0796f75b49 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -208,7 +208,6 @@ typedef struct BDRVReopenState {
 int flags;
 BlockdevDetectZeroesOptions detect_zeroes;
 bool backing_missing;
-bool replace_backing_bs;  /* new_backing_bs is ignored if this is false */
 BlockDriverState *old_backing_bs; /* keep pointer for permissions update */
 QDict *options;
 QDict *explicit_options;
diff --git a/block.c b/block.c
index d90b35f8f1..819e133dfa 100644
--- a/block.c
+++ b/block.c
@@ -4271,7 +4271,6 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
 return -EINVAL;
 }
 
-reopen_state->replace_backing_bs = true;
 reopen_state->old_backing_bs = bs->backing ? bs->backing->bs : NULL;
 return bdrv_set_backing_noperm(bs, new_backing_bs, set_backings_tran, 
errp);
 }
@@ -4526,17 +4525,16 @@ static void bdrv_reopen_commit(BDRVReopenState 
*reopen_state)
 bs->read_only = !(reopen_state->flags & BDRV_O_RDWR);
 bs->detect_zeroes  = reopen_state->detect_zeroes;
 
-if (reopen_state->replace_backing_bs) {
-qdict_del(bs->explicit_options, "backing");
-qdict_del(bs->options, "backing");
-}
-
 /* Remove child references from bs->options and bs->explicit_options.
  * Child options were already removed in bdrv_reopen_queue_child() */
 QLIST_FOREACH(child, &bs->children, next) {
 qdict_del(bs->explicit_options, child->name);
 qdict_del(bs->options, child->name);
 }
+/* backing is probably removed, so it's not handled by previous loop */
+qdict_del(bs->explicit_options, "backing");
+qdict_del(bs->options, "backing");
+
 bdrv_refresh_limits(bs, NULL, NULL);
 }
 
-- 
2.29.2

[PATCH v5 1/9] block: introduce bdrv_remove_file_or_backing_child()

[Vladimir Sementsov-Ogievskiy]

To be used for reopen in future commit.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/block.c b/block.c
index 9ad725d205..75565ce4d4 100644
--- a/block.c
+++ b/block.c
@@ -4770,16 +4770,14 @@ static TransactionActionDrv 
bdrv_remove_filter_or_cow_child_drv = {
 .clean = g_free,
 };
 
-/*
- * A function to remove backing-chain child of @bs if exists: cow child for
- * format nodes (always .backing) and filter child for filters (may be .file or
- * .backing)
- */
-static void bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
-Transaction *tran)
+/* A function to remove backing or file child of @bs */
+static void bdrv_remove_file_or_backing_child(BlockDriverState *bs,
+  BdrvChild *child,
+  Transaction *tran)
 {
 BdrvRemoveFilterOrCowChild *s;
-BdrvChild *child = bdrv_filter_or_cow_child(bs);
+
+assert(child == bs->backing || child == bs->file);
 
 if (!child) {
 return;
@@ -4804,6 +4802,17 @@ static void 
bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
 }
 }
 
+/*
+ * A function to remove backing-chain child of @bs if exists: cow child for
+ * format nodes (always .backing) and filter child for filters (may be .file or
+ * .backing)
+ */
+static void bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
+Transaction *tran)
+{
+bdrv_remove_file_or_backing_child(bs, bdrv_filter_or_cow_child(bs), tran);
+}
+
 static int bdrv_replace_node_noperm(BlockDriverState *from,
 BlockDriverState *to,
 bool auto_skip, Transaction *tran,
-- 
2.29.2

[PATCH v5 6/9] block: move supports_backing check to bdrv_set_file_or_backing_noperm()

[Vladimir Sementsov-Ogievskiy]

Move supports_backing check of bdrv_reopen_parse_backing to called
(through bdrv_set_backing_noperm()) bdrv_set_file_or_backing_noperm()
function. The check applies to general case, so it's appropriate for
bdrv_set_file_or_backing_noperm().

We have to declare backing support for two test drivers, otherwise new
check fails.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c  | 29 +++--
 tests/unit/test-bdrv-drain.c |  1 +
 tests/unit/test-bdrv-graph-mod.c |  1 +
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/block.c b/block.c
index 7d208c708d..d90b35f8f1 100644
--- a/block.c
+++ b/block.c
@@ -3127,6 +3127,14 @@ static int 
bdrv_set_file_or_backing_noperm(BlockDriverState *parent_bs,
 return -EPERM;
 }
 
+if (is_backing && !parent_bs->drv->is_filter &&
+!parent_bs->drv->supports_backing)
+{
+error_setg(errp, "Driver '%s' of node '%s' does not support backing "
+   "files", parent_bs->drv->format_name, parent_bs->node_name);
+return -EINVAL;
+}
+
 if (parent_bs->drv->is_filter) {
 role = BDRV_CHILD_FILTERED | BDRV_CHILD_PRIMARY;
 } else if (is_backing) {
@@ -4253,20 +4261,13 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
 }
 }
 
-/*
- * Ensure that @bs can really handle backing files, because we are
- * about to give it one (or swap the existing one)
- */
-if (bs->drv->is_filter) {
-/* Filters always have a file or a backing child */
-if (!bs->backing) {
-error_setg(errp, "'%s' is a %s filter node that does not support a 
"
-   "backing child", bs->node_name, bs->drv->format_name);
-return -EINVAL;
-}
-} else if (!bs->drv->supports_backing) {
-error_setg(errp, "Driver '%s' of node '%s' does not support backing "
-   "files", bs->drv->format_name, bs->node_name);
+if (bs->drv->is_filter && !bs->backing) {
+/*
+ * Filters always have a file or a backing child, so we are trying to
+ * change wrong child
+ */
+error_setg(errp, "'%s' is a %s filter node that does not support a "
+   "backing child", bs->node_name, bs->drv->format_name);
 return -EINVAL;
 }
 
diff --git a/tests/unit/test-bdrv-drain.c b/tests/unit/test-bdrv-drain.c
index 892f7f47d8..ce071b5fc5 100644
--- a/tests/unit/test-bdrv-drain.c
+++ b/tests/unit/test-bdrv-drain.c
@@ -95,6 +95,7 @@ static int bdrv_test_change_backing_file(BlockDriverState *bs,
 static BlockDriver bdrv_test = {
 .format_name= "test",
 .instance_size  = sizeof(BDRVTestState),
+.supports_backing   = true,
 
 .bdrv_close = bdrv_test_close,
 .bdrv_co_preadv = bdrv_test_co_preadv,
diff --git a/tests/unit/test-bdrv-graph-mod.c b/tests/unit/test-bdrv-graph-mod.c
index 88f25c0cdb..a6e3bb79be 100644
--- a/tests/unit/test-bdrv-graph-mod.c
+++ b/tests/unit/test-bdrv-graph-mod.c
@@ -41,6 +41,7 @@ static void no_perm_default_perms(BlockDriverState *bs, 
BdrvChild *c,
 
 static BlockDriver bdrv_no_perm = {
 .format_name = "no-perm",
+.supports_backing = true,
 .bdrv_child_perm = no_perm_default_perms,
 };
 
-- 
2.29.2

[PATCH v5 3/9] block: bdrv_reopen_parse_backing(): don't check aio context

[Vladimir Sementsov-Ogievskiy]

We don't need this check: bdrv_set_backing_noperm() will do it anyway
(actually in bdrv_attach_child_common()).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c | 33 -
 1 file changed, 33 deletions(-)

diff --git a/block.c b/block.c
index 5141c04815..4e18bc3177 100644
--- a/block.c
+++ b/block.c
@@ -4190,29 +4190,6 @@ int bdrv_reopen_set_read_only(BlockDriverState *bs, bool 
read_only,
 return ret;
 }
 
-static bool bdrv_reopen_can_attach(BlockDriverState *parent,
-   BdrvChild *child,
-   BlockDriverState *new_child,
-   Error **errp)
-{
-AioContext *parent_ctx = bdrv_get_aio_context(parent);
-AioContext *child_ctx = bdrv_get_aio_context(new_child);
-GSList *ignore;
-bool ret;
-
-ignore = g_slist_prepend(NULL, child);
-ret = bdrv_can_set_aio_context(new_child, parent_ctx, &ignore, NULL);
-g_slist_free(ignore);
-if (ret) {
-return ret;
-}
-
-ignore = g_slist_prepend(NULL, child);
-ret = bdrv_can_set_aio_context(parent, child_ctx, &ignore, errp);
-g_slist_free(ignore);
-return ret;
-}
-
 /*
  * Take a BDRVReopenState and check if the value of 'backing' in the
  * reopen_state->options QDict is valid or not.
@@ -4264,16 +4241,6 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
 g_assert_not_reached();
 }
 
-/*
- * Check AioContext compatibility so that the bdrv_set_backing_hd() call in
- * bdrv_reopen_commit() won't fail.
- */
-if (new_backing_bs) {
-if (!bdrv_reopen_can_attach(bs, bs->backing, new_backing_bs, errp)) {
-return -EINVAL;
-}
-}
-
 /*
  * Ensure that @bs can really handle backing files, because we are
  * about to give it one (or swap the existing one)
-- 
2.29.2

[PATCH v5 0/9] Allow changing bs->file on reopen

[Vladimir Sementsov-Ogievskiy]

Hi all!

Alberto, I'm sorry for not consulting with you about sending this.

Actually, I wanted only one patch
"block: Allow changing bs->file on reopen", as I'm going to send another
series based on it. I started to work on updating this one patch it and
it turned into a refactoring series below. So I decided to add you patch
with test cases, for this series to be a complete* v5. I hope you'll
have time to work on the rest of your series on top of this my
suggestion :)

[*], supporting multiple reopen and final publishing x-blockdev-reopen
not included here. Also I didn't address Kevin's comment that we should
have some error-path testing of new feature. Probably I didn't address
some comments on "Allow changing" patch, but it changed so much that
review should start from scratch anyway.

v5:
1-7: new
8: changed a lot
9: unchanged

Alberto Garcia (2):
  block: Allow changing bs->file on reopen
  iotests: Test replacing files with x-blockdev-reopen

Vladimir Sementsov-Ogievskiy (7):
  block: introduce bdrv_remove_file_or_backing_child()
  block: introduce bdrv_set_file_or_backing_noperm()
  block: bdrv_reopen_parse_backing(): don't check aio context
  block: bdrv_reopen_parse_backing(): don't check frozen child
  block: bdrv_reopen_parse_backing(): simplify handling implicit filters
  block: move supports_backing check to
bdrv_set_file_or_backing_noperm()
  block: BDRVReopenState: drop replace_backing_bs field

 include/block/block.h|   2 +-
 block.c  | 287 ---
 tests/unit/test-bdrv-drain.c |   1 +
 tests/unit/test-bdrv-graph-mod.c |   1 +
 tests/qemu-iotests/245   | 140 +--
 tests/qemu-iotests/245.out   |  11 +-
 6 files changed, 287 insertions(+), 155 deletions(-)

-- 
2.29.2

[PATCH v5 9/9] iotests: Test replacing files with x-blockdev-reopen

[Vladimir Sementsov-Ogievskiy]

From: Alberto Garcia 

This patch adds new tests in which we use x-blockdev-reopen to change
bs->file

Signed-off-by: Alberto Garcia 
---
 tests/qemu-iotests/245 | 109 -
 tests/qemu-iotests/245.out |  11 +++-
 2 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/tests/qemu-iotests/245 b/tests/qemu-iotests/245
index 87b59666f5..1623544a6a 100755
--- a/tests/qemu-iotests/245
+++ b/tests/qemu-iotests/245
@@ -79,7 +79,7 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 for line in log.split("\n"):
 if line.startswith("Pattern verification failed"):
 raise Exception("%s (command #%d)" % (line, found))
-if re.match("read .*/.* bytes at offset", line):
+if re.match("(read|wrote) .*/.* bytes at offset", line):
 found += 1
 self.assertEqual(found, self.total_io_cmds,
  "Expected output of %d qemu-io commands, found %d" %
@@ -537,6 +537,113 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 result = self.vm.qmp('blockdev-del', conv_keys = True, node_name = 
'bv')
 self.assert_qmp(result, 'return', {})
 
+# Replace the protocol layer ('file' parameter) of a disk image
+def test_replace_file(self):
+# Create two small raw images and add them to a running VM
+qemu_img('create', '-f', 'raw', hd_path[0], '10k')
+qemu_img('create', '-f', 'raw', hd_path[1], '10k')
+
+hd0_opts = {'driver': 'file', 'node-name': 'hd0-file', 'filename':  
hd_path[0] }
+hd1_opts = {'driver': 'file', 'node-name': 'hd1-file', 'filename':  
hd_path[1] }
+
+result = self.vm.qmp('blockdev-add', conv_keys = False, **hd0_opts)
+self.assert_qmp(result, 'return', {})
+result = self.vm.qmp('blockdev-add', conv_keys = False, **hd1_opts)
+self.assert_qmp(result, 'return', {})
+
+# Add a raw format layer that uses hd0-file as its protocol layer
+opts = {'driver': 'raw', 'node-name': 'hd', 'file': 'hd0-file'}
+
+result = self.vm.qmp('blockdev-add', conv_keys = False, **opts)
+self.assert_qmp(result, 'return', {})
+
+# Fill the image with data
+self.run_qemu_io("hd", "read  -P 0 0 10k")
+self.run_qemu_io("hd", "write -P 0xa0 0 10k")
+
+# Replace hd0-file with hd1-file and fill it with (different) data
+self.reopen(opts, {'file': 'hd1-file'})
+self.run_qemu_io("hd", "read  -P 0 0 10k")
+self.run_qemu_io("hd", "write -P 0xa1 0 10k")
+
+# Use hd0-file again and check that it contains the expected data
+self.reopen(opts, {'file': 'hd0-file'})
+self.run_qemu_io("hd", "read  -P 0xa0 0 10k")
+
+# And finally do the same with hd1-file
+self.reopen(opts, {'file': 'hd1-file'})
+self.run_qemu_io("hd", "read  -P 0xa1 0 10k")
+
+# Insert (and remove) a throttle filter
+def test_insert_throttle_filter(self):
+# Add an image to the VM
+hd0_opts = hd_opts(0)
+result = self.vm.qmp('blockdev-add', conv_keys = False, **hd0_opts)
+self.assert_qmp(result, 'return', {})
+
+# Create a throttle-group object
+opts = { 'qom-type': 'throttle-group', 'id': 'group0',
+ 'limits': { 'iops-total': 1000 } }
+result = self.vm.qmp('object-add', conv_keys = False, **opts)
+self.assert_qmp(result, 'return', {})
+
+# Add a throttle filter with the group that we just created.
+# The filter is not used by anyone yet
+opts = { 'driver': 'throttle', 'node-name': 'throttle0',
+ 'throttle-group': 'group0', 'file': 'hd0-file' }
+result = self.vm.qmp('blockdev-add', conv_keys = False, **opts)
+self.assert_qmp(result, 'return', {})
+
+# Insert the throttle filter between hd0 and hd0-file
+self.reopen(hd0_opts, {'file': 'throttle0'})
+
+# Remove the throttle filter from hd0
+self.reopen(hd0_opts, {'file': 'hd0-file'})
+
+# Insert (and remove) a compress filter
+def test_insert_compress_filter(self):
+# Add an image to the VM: hd (raw) -> hd0 (qcow2) -> hd0-file (file)
+opts = {'driver': 'raw', 'node-name': 'hd', 'file': hd_opts(0)}
+result = self.vm.qmp('blockdev-add', conv_keys = False, **opts)
+self.assert_qmp(result, 'return', {})
+
+# Add a 'compress' filter
+filter_opts = {'driver': 'compress',
+   'node-name': 'compress0',
+   'file': 'hd0'}
+result = self.vm.qmp('blockdev-add', conv_keys = False, **filter_opts)
+self.assert_qmp(result, 'return', {})
+
+# Unmap the beginning of the image (we cannot write compressed
+# data to an allocated cluster)
+self.run_qemu_io("hd", "write -z -u 0 128k")
+
+# Write data to the first cluster
+self.run_qemu_io("hd", "write -P 0xa0 0 64k")
+
+# Inser

[PATCH v5 8/9] block: Allow changing bs->file on reopen

[Vladimir Sementsov-Ogievskiy]

From: Alberto Garcia 

When the x-blockdev-reopen was added it allowed reconfiguring the
graph by replacing backing files, but changing the 'file' option was
forbidden. Because of this restriction some operations are not
possible, notably inserting and removing block filters.

This patch adds support for replacing the 'file' option. This is
similar to replacing the backing file and the user is likewise
responsible for the correctness of the resulting graph, otherwise this
can lead to data corruption.

Signed-off-by: Alberto Garcia 
 [vsementsov: bdrv_reopen_parse_file_or_backing() is modified a lot]
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/block.h  |  1 +
 block.c| 78 +-
 tests/qemu-iotests/245 | 23 +++--
 3 files changed, 67 insertions(+), 35 deletions(-)

diff --git a/include/block/block.h b/include/block/block.h
index 0796f75b49..daae24073d 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -209,6 +209,7 @@ typedef struct BDRVReopenState {
 BlockdevDetectZeroesOptions detect_zeroes;
 bool backing_missing;
 BlockDriverState *old_backing_bs; /* keep pointer for permissions update */
+BlockDriverState *old_file_bs; /* keep pointer for permissions update */
 QDict *options;
 QDict *explicit_options;
 void *opaque;
diff --git a/block.c b/block.c
index 819e133dfa..564443ac32 100644
--- a/block.c
+++ b/block.c
@@ -100,7 +100,7 @@ static void 
bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
 
 static int bdrv_reopen_prepare(BDRVReopenState *reopen_state,
BlockReopenQueue *queue,
-   Transaction *set_backings_tran, Error **errp);
+   Transaction *change_child_tran, Error **errp);
 static void bdrv_reopen_commit(BDRVReopenState *reopen_state);
 static void bdrv_reopen_abort(BDRVReopenState *reopen_state);
 
@@ -4123,6 +4123,10 @@ int bdrv_reopen_multiple(BlockReopenQueue *bs_queue, 
Error **errp)
 refresh_list = bdrv_topological_dfs(refresh_list, found,
 state->old_backing_bs);
 }
+if (state->old_file_bs) {
+refresh_list = bdrv_topological_dfs(refresh_list, found,
+state->old_file_bs);
+}
 }
 
 /*
@@ -4215,64 +4219,81 @@ int bdrv_reopen_set_read_only(BlockDriverState *bs, 
bool read_only,
  *
  * Return 0 on success, otherwise return < 0 and set @errp.
  */
-static int bdrv_reopen_parse_backing(BDRVReopenState *reopen_state,
- Transaction *set_backings_tran,
- Error **errp)
+static int bdrv_reopen_parse_file_or_backing(BDRVReopenState *reopen_state,
+ bool is_backing, Transaction 
*tran,
+ Error **errp)
 {
 BlockDriverState *bs = reopen_state->bs;
-BlockDriverState *new_backing_bs;
+BlockDriverState *new_child_bs;
+BlockDriverState *old_child_bs = is_backing ? child_bs(bs->backing) :
+  child_bs(bs->file);
+const char *child_name = is_backing ? "backing" : "file";
 QObject *value;
 const char *str;
 
-value = qdict_get(reopen_state->options, "backing");
+value = qdict_get(reopen_state->options, child_name);
 if (value == NULL) {
 return 0;
 }
 
 switch (qobject_type(value)) {
 case QTYPE_QNULL:
-new_backing_bs = NULL;
+assert(is_backing); /* The 'file' option does not allow a null value */
+new_child_bs = NULL;
 break;
 case QTYPE_QSTRING:
 str = qstring_get_str(qobject_to(QString, value));
-new_backing_bs = bdrv_lookup_bs(NULL, str, errp);
-if (new_backing_bs == NULL) {
+new_child_bs = bdrv_lookup_bs(NULL, str, errp);
+if (new_child_bs == NULL) {
 return -EINVAL;
-} else if (bdrv_recurse_has_child(new_backing_bs, bs)) {
-error_setg(errp, "Making '%s' a backing file of '%s' "
-   "would create a cycle", str, bs->node_name);
+} else if (bdrv_recurse_has_child(new_child_bs, bs)) {
+error_setg(errp, "Making '%s' a %s child of '%s' would create a "
+   "cycle", str, child_name, bs->node_name);
 return -EINVAL;
 }
 break;
 default:
-/* 'backing' does not allow any other data type */
+/*
+ * The options QDict has been flattened, so 'backing' and 'file'
+ * do not allow any other data type here.
+ */
 g_assert_not_reached();
 }
 
-if (bs->backing) {
-if (bdrv_skip_implicit_filters(bs->backing->bs) == new_backing_bs) {
+if (old_child_bs == new_child_bs) {
+return 0;
+}
+
+if (old_child_bs) {
+if (bdrv_s

[PATCH v5 2/9] block: introduce bdrv_set_file_or_backing_noperm()

[Vladimir Sementsov-Ogievskiy]

To be used for reopen in future commit.

Notes:
 - It seems OK to update inherits_from if new bs is recursively inherits
 from parent bs. Let's just not check for backing_chain_contains, to
 support file child of non-filters.

 - Simply check child->frozen instead of
   bdrv_is_backing_chain_frozen(), as we really interested only in this
   one child.

 - Role determination of new child is a bit more complex: it remains
   the same for backing child, it's obvious for filter driver. But for
   non-filter file child let's for now restrict to only replacing
   existing child (and keeping its role).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c | 83 +++--
 1 file changed, 63 insertions(+), 20 deletions(-)

diff --git a/block.c b/block.c
index 75565ce4d4..5141c04815 100644
--- a/block.c
+++ b/block.c
@@ -92,6 +92,9 @@ static int bdrv_attach_child_noperm(BlockDriverState 
*parent_bs,
 BdrvChild **child,
 Transaction *tran,
 Error **errp);
+static void bdrv_remove_file_or_backing_child(BlockDriverState *bs,
+  BdrvChild *child,
+  Transaction *tran);
 static void bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
 Transaction *tran);
 
@@ -3094,54 +3097,94 @@ static BdrvChildRole bdrv_backing_role(BlockDriverState 
*bs)
 }
 
 /*
- * Sets the bs->backing link of a BDS. A new reference is created; callers
- * which don't need their own reference any more must call bdrv_unref().
+ * Sets the bs->backing or bs->file link of a BDS. A new reference is created;
+ * callers which don't need their own reference any more must call 
bdrv_unref().
  */
-static int bdrv_set_backing_noperm(BlockDriverState *bs,
-   BlockDriverState *backing_hd,
-   Transaction *tran, Error **errp)
+static int bdrv_set_file_or_backing_noperm(BlockDriverState *parent_bs,
+   BlockDriverState *child_bs,
+   bool is_backing,
+   Transaction *tran, Error **errp)
 {
 int ret = 0;
-bool update_inherits_from = bdrv_chain_contains(bs, backing_hd) &&
-bdrv_inherits_from_recursive(backing_hd, bs);
+bool update_inherits_from =
+bdrv_inherits_from_recursive(child_bs, parent_bs);
+BdrvChild *child = is_backing ? parent_bs->backing : parent_bs->file;
+BdrvChildRole role;
 
-if (bdrv_is_backing_chain_frozen(bs, child_bs(bs->backing), errp)) {
+if (!parent_bs->drv) {
+/*
+ * Node without drv is an object without a class :/. TODO: finally fix
+ * qcow2 driver to never clear bs->drv and implement format corruption
+ * handling in other way.
+ */
+error_setg(errp, "Node corrupted");
+return -EINVAL;
+}
+
+if (child && child->frozen) {
+error_setg(errp, "Cannot change frozen '%s' link from '%s' to '%s'",
+   child->name, parent_bs->node_name, child->bs->node_name);
 return -EPERM;
 }
 
-if (bs->backing) {
-/* Cannot be frozen, we checked that above */
-bdrv_unset_inherits_from(bs, bs->backing, tran);
-bdrv_remove_filter_or_cow_child(bs, tran);
+if (parent_bs->drv->is_filter) {
+role = BDRV_CHILD_FILTERED | BDRV_CHILD_PRIMARY;
+} else if (is_backing) {
+role = BDRV_CHILD_COW;
+} else {
+/*
+ * We only can use same role as it is in existing child. We don't have
+ * infrastructure to determine role of file child in generic way
+ */
+if (!child) {
+error_setg(errp, "Cannot set file child to format node without "
+   "file child");
+return -EINVAL;
+}
+role = child->role;
 }
 
-if (!backing_hd) {
+if (child) {
+bdrv_unset_inherits_from(parent_bs, child, tran);
+bdrv_remove_file_or_backing_child(parent_bs, child, tran);
+}
+
+if (!child_bs) {
 goto out;
 }
 
-ret = bdrv_attach_child_noperm(bs, backing_hd, "backing",
-   &child_of_bds, bdrv_backing_role(bs),
-   &bs->backing, tran, errp);
+ret = bdrv_attach_child_noperm(parent_bs, child_bs,
+   is_backing ? "backing" : "file",
+   &child_of_bds, role,
+   is_backing ? &parent_bs->backing :
+&parent_bs->file,
+   tran, errp);
 if (ret < 0) {
 return ret;
 }
 
 
 /*
- * If backing_hd was already part of bs's backing chain, and
-

[PATCH v5 5/9] block: bdrv_reopen_parse_backing(): simplify handling implicit filters

[Vladimir Sementsov-Ogievskiy]

The logic around finding overlay here is not obvious. Actually it does
two simple things:

1. If new bs is already in backing chain, split from parent bs by
   several implicit filters we are done, do nothing.

2. Otherwise, don't try to replace implicit filter.

Let's rewrite this in more obvious way.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c | 53 -
 1 file changed, 16 insertions(+), 37 deletions(-)

diff --git a/block.c b/block.c
index bfa497813b..7d208c708d 100644
--- a/block.c
+++ b/block.c
@@ -4212,7 +4212,7 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
  Error **errp)
 {
 BlockDriverState *bs = reopen_state->bs;
-BlockDriverState *overlay_bs, *below_bs, *new_backing_bs;
+BlockDriverState *new_backing_bs;
 QObject *value;
 const char *str;
 
@@ -4241,6 +4241,18 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
 g_assert_not_reached();
 }
 
+if (bs->backing) {
+if (bdrv_skip_implicit_filters(bs->backing->bs) == new_backing_bs) {
+return 0;
+}
+
+if (bs->backing->bs->implicit) {
+error_setg(errp, "Cannot change backing link if '%s' has "
+   "an implicit backing file", bs->node_name);
+return -EPERM;
+}
+}
+
 /*
  * Ensure that @bs can really handle backing files, because we are
  * about to give it one (or swap the existing one)
@@ -4258,42 +4270,9 @@ static int bdrv_reopen_parse_backing(BDRVReopenState 
*reopen_state,
 return -EINVAL;
 }
 
-/*
- * Find the "actual" backing file by skipping all links that point
- * to an implicit node, if any (e.g. a commit filter node).
- * We cannot use any of the bdrv_skip_*() functions here because
- * those return the first explicit node, while we are looking for
- * its overlay here.
- */
-overlay_bs = bs;
-for (below_bs = bdrv_filter_or_cow_bs(overlay_bs);
- below_bs && below_bs->implicit;
- below_bs = bdrv_filter_or_cow_bs(overlay_bs))
-{
-overlay_bs = below_bs;
-}
-
-/* If we want to replace the backing file we need some extra checks */
-if (new_backing_bs != bdrv_filter_or_cow_bs(overlay_bs)) {
-int ret;
-
-/* Check for implicit nodes between bs and its backing file */
-if (bs != overlay_bs) {
-error_setg(errp, "Cannot change backing link if '%s' has "
-   "an implicit backing file", bs->node_name);
-return -EPERM;
-}
-
-reopen_state->replace_backing_bs = true;
-reopen_state->old_backing_bs = bs->backing ? bs->backing->bs : NULL;
-ret = bdrv_set_backing_noperm(bs, new_backing_bs, set_backings_tran,
-  errp);
-if (ret < 0) {
-return ret;
-}
-}
-
-return 0;
+reopen_state->replace_backing_bs = true;
+reopen_state->old_backing_bs = bs->backing ? bs->backing->bs : NULL;
+return bdrv_set_backing_noperm(bs, new_backing_bs, set_backings_tran, 
errp);
 }
 
 /*
-- 
2.29.2

[Bug 1914870] Re: libvixl compilation failure on Debian unstable

[Thomas Huth]

The QEMU project is currently moving 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 the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

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/1914870

Title:
  libvixl compilation failure on Debian unstable

Status in QEMU:
  Incomplete

Bug description:
  As of commit 0e324626306:

  $ lsb_release -d
  Description:Debian GNU/Linux bullseye/sid

  Project version: 5.2.50
  C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 
20210110")
  C linker for the host machine: cc ld.bfd 2.35.1
  C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 
10.2.1 20210110")
  C++ linker for the host machine: c++ ld.bfd 2.35.1

  [6/79] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o
  FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o 
  c++ -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui/shader 
-I/usr/include/capstone -I/usr/include/glib-2.0 
-I/usr/lib/hppa-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall 
-Winvalid-pch -Wnon-virtual-dtor -Werror -std=gnu++11 -O2 -g -isystem 
/home/philmd/qemu/linux-headers -isystem linux-headers -iquote . -iquote 
/home/philmd/qemu -iquote /home/philmd/qemu/include -iquote 
/home/philmd/qemu/disas/libvixl -iquote /home/philmd/qemu/tcg/hppa -iquote 
/home/philmd/qemu/accel/tcg -pthread -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fPIE -MD -MQ 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc
  In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30,
   from ../disas/libvixl/vixl/utils.cc:27:
  /usr/include/string.h:36:43: error: missing binary operator before token "("
 36 | #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \
|   ^
  /usr/include/string.h:53:62: error: missing binary operator before token "("
 53 | #if defined __USE_MISC || defined __USE_XOPEN || __GLIBC_USE (ISOC2X)
|  ^
  /usr/include/string.h:165:21: error: missing binary operator before token "("
165 |  || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X))
| ^
  /usr/include/string.h:174:43: error: missing binary operator before token "("
174 | #if defined __USE_XOPEN2K8 || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE 
(ISOC2X)
|   ^
  /usr/include/string.h:492:19: error: missing binary operator before token "("
492 | #if __GNUC_PREREQ (3,4)
|   ^
  In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30,
   from ../disas/libvixl/vixl/utils.cc:27:
  /usr/include/string.h:28:1: error: ‘__BEGIN_DECLS’ does not name a type
 28 | __BEGIN_DECLS
| ^
  In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30,
   from ../disas/libvixl/vixl/utils.cc:27:
  /usr/include/string.h:44:8: error: ‘size_t’ has not been declared
 44 |size_t __n) __THROW __nonnull ((1, 2));
|^~
  /usr/include/string.h:44:20: error: expected initializer before ‘_

[Bug 1920913] Re: Openjdk11+ fails to install on s390x

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/319


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #319
   https://gitlab.com/qemu-project/qemu/-/issues/319

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

Title:
  Openjdk11+ fails to install on s390x

Status in QEMU:
  Expired

Bug description:
  While installing openjdk11 or higher from repo, it crashes while configuring 
ca-certificates-java.
  Although `java -version` passes, `jar -version` crashes. Detailed logs 
attached to this issue.

  ```
  # A fatal error has been detected by the Java Runtime Environment:
  #
  #  SIGILL (0x4) at pc=0x0040126f9980, pid=8425, tid=8430
  #
  # JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 
11.0.10+9-Ubuntu-0ubuntu1.20.04)
  # Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed 
mode, tiered, compressed oops, g1 gc, linux-s390x)
  # Problematic frame:
  # J 4 c1 java.lang.StringLatin1.hashCode([B)I java.base@11.0.10 (42 bytes) @ 
0x0040126f9980 [0x0040126f9980+0x]
  #
  # Core dump will be written. Default location: Core dumps may be processed 
with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to //core.8425)
  #
  # An error report file with more information is saved as:
  # //hs_err_pid8425.log
  sed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to 
/root/core.10740)
  #
  # An error report file with more information is saved as:
  # /root/hs_err_pid10740.log
  ```

  Observed this on s390x/ubuntu as well as s390x/alpine when run on amd64 host.
  Please note, on native s390x, the installation is successful. Also this crash 
is not observed while installing openjdk-8-jdk.

  Qemu version: 5.2.0

  Please let me know if any more details are needed.

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

[Bug 1921061] Re: Corsair iCUE Install Fails, qemu VM Reboots

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/320


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #320
   https://gitlab.com/qemu-project/qemu/-/issues/320

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

Title:
  Corsair iCUE Install Fails, qemu VM Reboots

Status in QEMU:
  Expired

Bug description:
  Hi,

  I had this working before, but in the latest version of QEMU (built
  from master), when I try to install Corsair iCUE, and it gets to the
  driver install point => my Windows 10 VM just reboots! I would be
  happy to capture logs, but ... what logs exist for an uncontrolled
  reboot? Thinking they are lost in the reboot :-(.

  Thanks!

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

[Bug 1920602] Re: QEMU crash after a QuickBASIC program integer overflow

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/318


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #318
   https://gitlab.com/qemu-project/qemu/-/issues/318

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

Title:
  QEMU crash after a QuickBASIC program integer overflow

Status in QEMU:
  Expired

Bug description:
  A trivial program compiled with QuickBASIC 4.5 with integer overflow
  will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:

  C:\KILLER>type killer.bas
  A% = VAL("9"):PRINT A%

  C:\KILLER>killer.exe
  **
    ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
  Aborted

  QEMU version v5.2, compiler for ARM, and started with command line:

  qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img

  The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version
  4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On
  DOSBOX, the machine does not die and program outputs the value -31073.

  The EXE to reproduce the issue is attached.

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