Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

On 6/3/19 5:01 PM, Alex Bennée wrote: > When running on 32 bit TCG backends a wide unaligned load ends up > truncating data before returning to the guest. We specifically have > the return type as uint64_t to avoid any premature truncation so we > should use the same for the interim types. > > Hop

Re: [Qemu-devel] [Qemu-ppc] [PATCH v9 5/6] ppc: spapr: Enable FWNMI capability

On Monday 03 June 2019 08:55 PM, Greg Kurz wrote: > On Wed, 29 May 2019 11:10:49 +0530 > Aravinda Prasad wrote: > >> Enable the KVM capability KVM_CAP_PPC_FWNMI so that >> the KVM causes guest exit with NMI as exit reason >> when it encounters a machine check exception on the >> address belong

Re: [Qemu-devel] [PATCH v16 16/23] Add rx-softmmu

Hi Richard, On 5/31/19 3:43 PM, Richard Henderson wrote: > From: Yoshinori Sato > > Tested-by: Philippe Mathieu-Daudé > Reviewed-by: Philippe Mathieu-Daudé > Signed-off-by: Yoshinori Sato > Message-Id: <20190516055244.95559-10-ys...@users.sourceforge.jp> > Signed-off-by: Richard Henderson >

Re: [Qemu-devel] [PATCH v9 4/6] target/ppc: Build rtas error log upon an MCE

On Monday 03 June 2019 07:30 PM, Greg Kurz wrote: > On Wed, 29 May 2019 11:10:40 +0530 > Aravinda Prasad wrote: > >> Upon a machine check exception (MCE) in a guest address space, >> KVM causes a guest exit to enable QEMU to build and pass the >> error to the guest in the PAPR defined rtas err

Re: [Qemu-devel] QMP; unsigned 64-bit ints; JSON standards compliance

We've discussed possible solutions. Is anyone working or intending to work on patches?

[Qemu-devel] [PATCH v3] migratioin/ram: leave RAMBlock->bmap blank on allocating

During migration, we would sync bitmap from ram_list.dirty_memory to RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap(). Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this means at the first round this sync is meaningless and is a duplicated work. Leaving RAMBlock->bma

Re: [Qemu-devel] [Qemu-ppc] [PATCH v9 1/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls

On Monday 03 June 2019 04:47 PM, Greg Kurz wrote: > On Mon, 3 Jun 2019 12:12:43 +0200 > Greg Kurz wrote: > >> On Wed, 29 May 2019 11:10:14 +0530 >> Aravinda Prasad wrote: >> >>> This patch adds support in QEMU to handle "ibm,nmi-register" >>> and "ibm,nmi-interlock" RTAS calls. >>> >>> The ma

Re: [Qemu-devel] [PATCH v16 22/23] target/rx: Collect all bytes during disassembly

On 5/31/19 3:43 PM, Richard Henderson wrote: > Collected, to be used in the next patch. > > Reviewed-by: Yoshinori Sato > Signed-off-by: Richard Henderson > --- > target/rx/disas.c | 62 --- > 1 file changed, 42 insertions(+), 20 deletions(-) > > dif

[Qemu-devel] [Bug 1831545] [NEW] "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host

Public bug reported: As described in https://lists.gnu.org/archive/html/qemu- devel//2019-05/msg07362.html I run into TCG regression in qemu-git. Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-effective for my case. For reproduction (on 32-bit x86 host,

Re: [Qemu-devel] [PATCH v16 20/23] target/rx: Use prt_ldmi for XCHG_mr disassembly

On 5/31/19 3:43 PM, Richard Henderson wrote: > Note that the ld == 3 case handled by prt_ldmi is decoded as > XCHG_rr and cannot appear here. > > Reviewed-by: Yoshinori Sato > Signed-off-by: Richard Henderson > --- > target/rx/disas.c | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(

Re: [Qemu-devel] [PATCH v16 23/23] target/rx: Dump bytes for each insn during disassembly

On 5/31/19 3:43 PM, Richard Henderson wrote: > There are so many different forms of each RX instruction > that it will be very useful to be able to look at the bytes > to see on which path a bug may lie. > > Reviewed-by: Yoshinori Sato > Signed-off-by: Richard Henderson > --- > target/rx/disas.

Re: [Qemu-devel] [PATCH v16 19/23] target/rx: Replace operand with prt_ldmi in disassembler

On 5/31/19 3:43 PM, Richard Henderson wrote: > This has consistency with prt_ri(). It loads all data before > beginning output. It uses exactly one call to prt() to emit > the full instruction. > > Reviewed-by: Yoshinori Sato > Signed-off-by: Richard Henderson > --- > target/rx/disas.c | 77 +

Re: [Qemu-devel] [PATCH v16 21/23] target/rx: Emit all disassembly in one prt()

On 5/31/19 3:43 PM, Richard Henderson wrote: > Many of the multi-part prints have been eliminated by previous > patches. Eliminate the rest of them. > > Reviewed-by: Yoshinori Sato > Signed-off-by: Richard Henderson > --- > target/rx/disas.c | 75 ---

Re: [Qemu-devel] Deprecation policy and build dependencies

Peter Maydell writes: > On Mon, 3 Jun 2019 at 19:21, John Snow wrote: >> I get it, we don't want to require Python 3.8 because some dev wanted >> assignment conditionals -- but we're talking about Python 2 here, which >> suffers its EOL by the end of this calendar year. "Not because some dev wa

Re: [Qemu-devel] [PATCH v16 15/23] hw/rx: Honor -accel qtest

On 5/31/19 3:43 PM, Richard Henderson wrote: > Issue an error if no kernel, no bios, and not qtest'ing. > Fixes make check-qtest-rx: test/qom-test. > > Signed-off-by: Richard Henderson > --- > hw/rx/rx62n.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/hw/rx

Re: [Qemu-devel] [PATCH v3 00/14] tests/vm: serial console autoinstall, misc fixes.

Cc'ing Paolo & Marc-André (and removing the BSD folks). On 5/30/19 12:30 PM, Philippe Mathieu-Daudé wrote: > Cc'ing the Python team. > > On 5/30/19 12:18 PM, Alex Bennée wrote: >> >> Philippe Mathieu-Daudé writes: >> >>> On 5/30/19 11:33 AM, Alex Bennée wrote: Gerd Hoffmann writes: >>

Re: [Qemu-devel] [PATCH v16 14/23] tests: Add rx to machine-none-test.c

On 5/31/19 3:43 PM, Richard Henderson wrote: > Fixes check-qtest-rx: tests/machine-none-test. > > Cc: Thomas Huth > Cc: Laurent Vivier > Cc: Paolo Bonzini > Signed-off-by: Richard Henderson > --- > tests/machine-none-test.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/machi

Re: [Qemu-devel] [PATCH v16 12/23] target/rx: Add RX to SysEmuTarget

On 5/31/19 3:43 PM, Richard Henderson wrote: > Fixes check-qtest-rx: tests/qmp-cmd-test > > Cc: Eric Blake > Cc: Markus Armbruster > Signed-off-by: Richard Henderson > --- > qapi/common.json | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/qapi/common.json b/qapi/com

Re: [Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

On Tue, Jun 04, 2019 at 11:51:24AM +0800, Peter Xu wrote: >On Tue, Jun 04, 2019 at 08:28:10AM +0800, Wei Yang wrote: >> During migration, we would sync bitmap from ram_list.dirty_memory to >> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap(). >> >> Since we set RAMBlock.bmap and ram_list.di

Re: [Qemu-devel] Deprecation policy and build dependencies

Hi, > >> Normally I'd say it's only nice to also follow the depreciation policy > >> for tooling as well to give people a chance to switch away, but with > >> regards to Python2, I feel like we're in the clear to drop it for the > >> first release that will happen after the Python2 doomsday cloc

Re: [Qemu-devel] [PATCH v16 00/23] Add RX architecture

On 5/31/19 3:42 PM, Richard Henderson wrote: > The v14 patch set, from which I had prepared the pull request, > contained errors within make check-qtest-rx. I have added 4 > new patches, 12 through 15, to address those failures. These > are placed before the enablement patch 16 so that there is n

Re: [Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

On Tue, Jun 04, 2019 at 08:28:10AM +0800, Wei Yang wrote: > During migration, we would sync bitmap from ram_list.dirty_memory to > RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap(). > > Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this > means at the first round this

Re: [Qemu-devel] [PULL 00/28] Block layer patches

Patchew URL: https://patchew.org/QEMU/20190603150233.6614-1-kw...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PULL 00/28] Block layer patches Type: series Message-id: 20190603150233.6614-1-kw...@redhat.com

Re: [Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL

Patchew URL: https://patchew.org/QEMU/20190603232209.20704-1-richard.hender...@linaro.org/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL Type: series Message-id: 20190603232

Re: [Qemu-devel] [PATCH 5/5] virtio: add "use-started" property

On Tue, 4 Jun 2019 at 04:49, Greg Kurz wrote: > > On Wed, 29 May 2019 15:09:55 +0800 > elohi...@gmail.com wrote: > > > From: Xie Yongji > > > > In order to avoid migration issues, we introduce a "use-started" > > property to the base virtio device to indicate whether "started" > > and "start_on_k

[Qemu-devel] [PATCH] migration/multifd: sync packet_num after all thread are done

Notification from recv thread is not ordered, which means we may be notified by one MultiFDRecvParams but adjust packet_num for another. Move the adjustment after we are sure each recv thread are sync-ed. Signed-off-by: Wei Yang --- migration/ram.c | 8 1 file changed, 4 insertions(+),

Re: [Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

On Tue, 4 Jun 2019, at 09:07, Joel Stanley wrote: > On Mon, 3 Jun 2019 at 19:11, Adriana Kobylak wrote: > > > > From: Adriana Kobylak > > > > The Swift board is an OpenPOWER system hosting POWER processors. > > Add support for their BMC including the I2C devices as found on HW. > > > > Signed-

Re: [Qemu-devel] [PATCH 0/4] Multifd Cleanup

Hi, David Do you prefer I resend 3/4 or it is ok for you to pick up here directly? On Tue, May 28, 2019 at 09:46:59AM +0800, Wei Yang wrote: >Just found several small places for unused variables. > >Wei Yang (4): > migration: multifd_save_setup always return 0 > migration/ram.c: use same type i

Re: [Qemu-devel] [PATCH] target/ppc: Use tcg_gen_gvec_bitsel

On Mon, Jun 03, 2019 at 11:49:27AM -0500, Richard Henderson wrote: > Replace the target-specific implementation of XXSEL. Applied, thanks. > > Signed-off-by: Richard Henderson > --- > target/ppc/translate/vsx-impl.inc.c | 24 ++-- > 1 file changed, 2 insertions(+), 22 delet

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

On Tue, 4 Jun 2019 at 04:16, Greg Kurz wrote: > > On Wed, 29 May 2019 15:09:52 +0800 > elohi...@gmail.com wrote: > > > From: Xie Yongji > > > > We should migrate the "start_on_kick" flag so that we > > would not miss starting device on kicking at startup > > after migration. > > > > Hmm... IIUC "

Re: [Qemu-devel] [PATCH 1/5] virtio: Set "start_on_kick" on virtio_set_features()

On Tue, 4 Jun 2019 at 00:53, Greg Kurz wrote: > > On Wed, 29 May 2019 15:09:51 +0800 > elohi...@gmail.com wrote: > > > From: Xie Yongji > > > > The guest feature is not set correctly on virtio_reset() and > > virtio_init(). So we should not use it to set "start_on_kick" at that > > point. This pa

Re: [Qemu-devel] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration

On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote: > On Thu, 30 May 2019 20:44:38 -0400 > Yan Zhao wrote: > > > This patchset introduces a migration_version attribute under sysfs of VFIO > > Mediated devices. > > > > This migration_version attribute is used to check migration compa

[Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

During migration, we would sync bitmap from ram_list.dirty_memory to RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap(). Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this means at the first round this sync is meaningless and is a duplicated work. Leaving RAMBlock->bma

Re: [Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

On Mon, 3 Jun 2019 at 19:11, Adriana Kobylak wrote: > > From: Adriana Kobylak > > The Swift board is an OpenPOWER system hosting POWER processors. > Add support for their BMC including the I2C devices as found on HW. > > Signed-off-by: Adriana Kobylak > Reviewed-by: Cédric Le Goater > --- > hw

[Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL

These instructions shift left or right depending on the sign of the input, and 7 bits are significant to the shift. This requires several masks and selects in addition to the actual shifts to form the complete answer. That said, the operation is still a small improvement even for two 64-bit eleme

[Qemu-devel] [PATCH] [RFC] Add a eBPF-capable PCIe device

This RFC adds a PCIe device model that is capable of running machine code complaint with the extended Berkeley Packet Filter (eBPF) virtual machine [1]. This machine can then be used to run offloaded code in the PCIe device against data passed to the PCIe device via DMA. eBPF is a very well support

[Qemu-devel] [patch QEMU] kvm: i386: halt poll control MSR support

(CC'ing qemu devel) Add support for halt poll control MSR: save/restore, migration and new feature name. The purpose of this MSR is to allow the guest to disable host halt poll. Signed-off-by: Marcelo Tosatti diff --git a/include/standard-headers/asm-x86/kvm_para.h b/include/standard-headers/

[Qemu-devel] [PATCH] hw: misc: Add Aspeed XDMA device

The XDMA engine embedded in the Aspeed SOCs performs PCI DMA operations between the SOC (acting as a BMC) and a host processor in a server. The XDMA engine exists on the AST2400, AST2500, and AST2600 SOCs, so enable it for all of those. Signed-off-by: Eddie James --- hw/arm/aspeed_soc.c

Re: [Qemu-devel] [Qemu-block] [PATCH v2 1/5] block/nvme: don't flip CQ phase bits

On 4/17/19 3:53 PM, Maxim Levitsky wrote: > Phase bits are only set by the hardware to indicate new completions > and not by the device driver. > > Signed-off-by: Maxim Levitsky > --- > block/nvme.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/block/nvme.c b/block/nvme.c > index

Re: [Qemu-devel] [Qemu-block] [PATCH] qemu-img: Fix options leakage in img_rebase()

On 5/28/19 3:53 PM, Max Reitz wrote: > img_rebase() can leak a QDict in two occasions. Fix it. > > Coverity: CID 1401416 > Fixes: d16699b64671466b42079c45b89127aeea1ca565 > Fixes: 330c72957196e0ae382abcaa97ebf4eb9bc8574f > Signed-off-by: Max Reitz > --- > qemu-img.c | 3 +++ > 1 file changed

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] blockdev: Overlays are not snapshots

On 6/3/19 4:22 PM, Max Reitz wrote: > QEMU’s always been confused over what a snapshot is: Is it the overlay? > Is it the backing image? > > Confusion is rarely a good thing. I can’t think of any objective reason > why the overlay would be a snapshot. A snapshot is something that does > not c

Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

On 6/3/19 10:01 AM, Alex Bennée wrote: > When running on 32 bit TCG backends a wide unaligned load ends up > truncating data before returning to the guest. We specifically have > the return type as uint64_t to avoid any premature truncation so we > should use the same for the interim types. > > Ho

Re: [Qemu-devel] [PATCH] target/s390x: Use tcg_gen_gvec_bitsel

On 6/3/19 2:41 PM, David Hildenbrand wrote: >> -static void gen_sel_vec(unsigned vece, TCGv_vec d, TCGv_vec a, TCGv_vec b, >> -TCGv_vec c) >> -{ >> -TCGv_vec t = tcg_temp_new_vec_matching(d); >> - >> -tcg_gen_andc_vec(vece, t, b, c); >> -tcg_gen_and_vec(vece, d,

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

On Mon, Jun 03, 2019 at 11:25:23PM +0200, Greg Kurz wrote: > On Mon, 3 Jun 2019 17:03:06 -0400 > "Michael S. Tsirkin" wrote: > > > On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote: > > > On Wed, 29 May 2019 15:09:52 +0800 > > > elohi...@gmail.com wrote: > > > > > > > From: Xie Yongji

[Qemu-devel] [PATCH v3 3/3] docs/bitmaps: use QMP lexer instead of json

The annotated style json we use in QMP documentation is not strict json and depending on the version of Sphinx (2.0+) or Pygments installed, might cause the build to fail. Use the new QMP lexer. Further, some versions of Sphinx can not apply custom lexers to "code" directives and require the use

[Qemu-devel] [PATCH v3 1/3] docs/interop/bitmaps.rst: Fix typos

Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches these errors. Signed-off-by: John Snow --- docs/interop/bitmaps.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst index 510e8809a9..c29ac4a854 10064

Re: [Qemu-devel] [PATCH RFC v20 4/8] target-avr: Add instruction decoding

On 6/3/19 3:13 PM, Michael Rolnik wrote: > Richard, > I don't understand what I should do. Do you want me to merge decode files? Yes, using the mechanisms previously described. r~ > > On Fri, May 31, 2019 at 5:45 PM Richard Henderson > > wrote: > > O

[Qemu-devel] [PATCH v3 2/3] sphinx: add qmp_lexer

Sphinx, through Pygments, does not like annotated json examples very much. In some versions of Sphinx (1.7), it will render the non-json portions of code blocks in red, but in newer versions (2.0) it will throw an exception and not highlight the block at all. Though we can suppress this warning, it

[Qemu-devel] [PATCH v3 0/3] Add QMP lexer for annotated JSON to Sphinx

QMP isn't json. It turns out Pygments cares about this. Teach Pygments to go with the annotated flow. V3: - Also annotate elision indicators '...', which cause problems in Sphinx 2.1+ - Adjust setup.py to cope with future versions of Sphinx that change the add_lexer interface V2: - Chang

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

On Mon, 3 Jun 2019 17:03:06 -0400 "Michael S. Tsirkin" wrote: > On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote: > > On Wed, 29 May 2019 15:09:52 +0800 > > elohi...@gmail.com wrote: > > > > > From: Xie Yongji > > > > > > We should migrate the "start_on_kick" flag so that we > > > w

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote: > On Wed, 29 May 2019 15:09:52 +0800 > elohi...@gmail.com wrote: > > > From: Xie Yongji > > > > We should migrate the "start_on_kick" flag so that we > > would not miss starting device on kicking at startup > > after migration. > > > >

[Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

From: Adriana Kobylak The Swift board is an OpenPOWER system hosting POWER processors. Add support for their BMC including the I2C devices as found on HW. Signed-off-by: Adriana Kobylak Reviewed-by: Cédric Le Goater --- hw/arm/aspeed.c | 42 ++ 1 file c

Re: [Qemu-devel] [PATCH 5/5] virtio: add "use-started" property

On Wed, 29 May 2019 15:09:55 +0800 elohi...@gmail.com wrote: > From: Xie Yongji > > In order to avoid migration issues, we introduce a "use-started" > property to the base virtio device to indicate whether "started" > and "start_on_kick" flag could be used. This property will be > true by defaul

[Qemu-devel] [PATCH v2 2/2] blockdev: Overlays are not snapshots

There are error messages which refer to an overlay node as the snapshot. That is wrong, those are two different things. Signed-off-by: Max Reitz Reviewed-by: Eric Blake --- blockdev.c | 10 +- tests/qemu-iotests/085.out | 10 +- 2 files changed, 10 insertions(+),

[Qemu-devel] [PATCH v2 0/2] blockdev: Overlays are not snapshots

QEMU’s always been confused over what a snapshot is: Is it the overlay? Is it the backing image? Confusion is rarely a good thing. I can’t think of any objective reason why the overlay would be a snapshot. A snapshot is something that does not change over time; the overlay does. (I suppose hist

[Qemu-devel] [PATCH v2 1/2] qapi/block-core: Overlays are not snapshots

A snapshot is something that reflects the state of something at a certain point in time. It does not change. The file our snapshot commands create (or the node they install) is not a snapshot, as it does change over time. It is an overlay. We cannot do anything about the parameter names, but we

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

On Wed, 29 May 2019 15:09:52 +0800 elohi...@gmail.com wrote: > From: Xie Yongji > > We should migrate the "start_on_kick" flag so that we > would not miss starting device on kicking at startup > after migration. > Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has not b

Re: [Qemu-devel] [PATCH RFC v20 4/8] target-avr: Add instruction decoding

Richard, I don't understand what I should do. Do you want me to merge decode files? On Fri, May 31, 2019 at 5:45 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 5/30/19 2:07 PM, Michael Rolnik wrote: > > This includes: > > - encoding of all 16 bit instructions > > - encoding of a

Re: [Qemu-devel] [PATCH 2/2] blockdev: Overlays are not snapshots

On 03.06.19 18:25, Max Reitz wrote: > There are error messages which refer to an overlay node as the snapshot. > That is wrong, those are two different things. > > Signed-off-by: Max Reitz > --- > blockdev.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Oops. I remember I

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

On Mon, 3 Jun 2019 20:51:50 +0200 Auger Eric wrote: > Hi Alex, > > On 6/3/19 8:31 PM, Alex Williamson wrote: > > On Mon, 27 May 2019 11:59:04 +0200 > > Eric Auger wrote: > > > >> The code used to assign an interrupt index/subindex to an > >> eventfd is duplicated many times. Let's introduce

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote: > On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote: > > On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote: > > > On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote: > > > > On Tue, May 21, 2019

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

Hi Alex, On 6/3/19 9:36 PM, Alex Williamson wrote: > On Mon, 3 Jun 2019 20:51:50 +0200 > Auger Eric wrote: > >> Hi Alex, >> >> On 6/3/19 8:31 PM, Alex Williamson wrote: >>> On Mon, 27 May 2019 11:59:04 +0200 >>> Eric Auger wrote: >>> The code used to assign an interrupt index/subindex t

Re: [Qemu-devel] [PATCH 1/2] qapi/block-core: Overlays are not snapshots

On 6/3/19 11:25 AM, Max Reitz wrote: > A snapshot is something that reflects the state of something at a > certain point in time. It does not change. > > The file our snapshot commands create (or the node they install) is not > a snapshot, as it does change over time. It is an overlay. We canno

Re: [Qemu-devel] [PATCH RFC v20 8/8] target/avr: Register AVR support with the rest of QEMU, the build system, and the MAINTAINERS file

Thanks! On Mon, Jun 3, 2019 at 10:47 PM Eric Blake wrote: > On 6/1/19 4:20 PM, Michael Rolnik wrote: > > Hi Eric. > > > > please explain what should I do or point to an example or documentation. > > > > >>> # Since: 3.0 > >>> ## > >>> { 'enum' : 'SysEmuTarget', > >>> - 'data' : [ 'aarch64',

Re: [Qemu-devel] [PATCH] target/s390x: Use tcg_gen_gvec_bitsel

On 03.06.19 18:57, Richard Henderson wrote: > This replaces the target-specific implementations for VSEL. > > Signed-off-by: Richard Henderson > --- > target/s390x/translate_vx.inc.c | 38 ++--- > 1 file changed, 6 insertions(+), 32 deletions(-) > > diff --git a/targ

Re: [Qemu-devel] [PATCH 2/2] blockdev: Overlays are not snapshots

On 6/3/19 11:25 AM, Max Reitz wrote: > There are error messages which refer to an overlay node as the snapshot. > That is wrong, those are two different things. > > Signed-off-by: Max Reitz > --- > blockdev.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > Reviewed-by: Eri

Re: [Qemu-devel] Deprecation policy and build dependencies

On Mon, Jun 03, 2019 at 08:16:29PM +0200, Cornelia Huck wrote: > On Mon, 3 Jun 2019 14:02:16 -0400 > John Snow wrote: > > > On 6/3/19 8:26 AM, Markus Armbruster wrote: > > > John Snow writes: > > > > > >> On 5/31/19 3:24 PM, Eduardo Habkost wrote: > > >>> Long story short: I would really li

Re: [Qemu-devel] [PATCH RFC v20 8/8] target/avr: Register AVR support with the rest of QEMU, the build system, and the MAINTAINERS file

On 6/1/19 4:20 PM, Michael Rolnik wrote: > Hi Eric. > > please explain what should I do or point to an example or documentation. > >>> # Since: 3.0 >>> ## >>> { 'enum' : 'SysEmuTarget', >>> - 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32', >>> + 'data' : [ 'aarch64', '

Re: [Qemu-devel] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration

On Thu, 30 May 2019 20:44:38 -0400 Yan Zhao wrote: > This patchset introduces a migration_version attribute under sysfs of VFIO > Mediated devices. > > This migration_version attribute is used to check migration compatibility > between two mdev devices of the same mdev type. > > Patch 1 defines

Re: [Qemu-devel] [PATCH v2 09/10] hw/vfio/pci: Use the QOM DEVICE() macro to access DeviceState.qdev

On Tue, 28 May 2019 18:40:19 +0200 Philippe Mathieu-Daudé wrote: > Rather than looking inside the definition of a DeviceState with > "s->qdev", use the QOM prefered style: "DEVICE(s)". > > This patch was generated using the following Coccinelle script: > > // Use DEVICE() macros to access D

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

Hi Alex, On 6/3/19 8:31 PM, Alex Williamson wrote: > On Mon, 27 May 2019 11:59:04 +0200 > Eric Auger wrote: > >> The code used to assign an interrupt index/subindex to an >> eventfd is duplicated many times. Let's introduce an helper that >> allows to set/unset the signaling for an ACTION_TRIGGE

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

On Mon, 3 Jun 2019 14:10:52 -0400 Laine Stump wrote: > On 6/3/19 4:24 AM, Jens Freimann wrote: > > On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote: > >> On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote: > >>> On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Ts

Re: [Qemu-devel] Deprecation policy and build dependencies

On Mon, 3 Jun 2019 at 19:21, John Snow wrote: > I get it, we don't want to require Python 3.8 because some dev wanted > assignment conditionals -- but we're talking about Python 2 here, which > suffers its EOL by the end of this calendar year. > > So do we think it's reasonable to drop support for

[Qemu-devel] [Bug 1830872] Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

(+Igor) On 06/03/19 17:01, Alex Bennée wrote: > When running on 32 bit TCG backends a wide unaligned load ends up > truncating data before returning to the guest. We specifically have > the return type as uint64_t to avoid any premature truncation so we > should use the same for the interim types.

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

On Mon, 27 May 2019 11:59:04 +0200 Eric Auger wrote: > The code used to assign an interrupt index/subindex to an > eventfd is duplicated many times. Let's introduce an helper that > allows to set/unset the signaling for an ACTION_TRIGGER, > ACTION_MASK or ACTION_UNMASK action. > > Signed-off-by:

[Qemu-devel] [Bug 1831486] [NEW] qmp monitor deadlock (with spice events for ex)

Public bug reported: If an event is emitted during monitor_flush_locked() it will deadlock. Thread 1 (Thread 0x7f14f1854000 (LWP 7245)): #0 0x7f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0 #1 0x7f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0 #2 0x55de6

Re: [Qemu-devel] Deprecation policy and build dependencies

On 6/3/19 2:27 PM, Peter Maydell wrote: > On Mon, 3 Jun 2019 at 19:21, John Snow wrote: >> I get it, we don't want to require Python 3.8 because some dev wanted >> assignment conditionals -- but we're talking about Python 2 here, which >> suffers its EOL by the end of this calendar year. >> >>

Re: [Qemu-devel] Deprecation policy and build dependencies

On 6/3/19 2:17 PM, Peter Maydell wrote: > On Mon, 3 Jun 2019 at 19:02, John Snow wrote: >> That policy strikes me as weird, because RHEL7 is not going to be, in >> general, using the latest and greatest QEMU. Usually stable versions of >> distros stick with the versions of the programs that cam

Re: [Qemu-devel] Deprecation policy and build dependencies

On Mon, 3 Jun 2019 at 19:02, John Snow wrote: > That policy strikes me as weird, because RHEL7 is not going to be, in > general, using the latest and greatest QEMU. Usually stable versions of > distros stick with the versions of the programs that came out at the time. > > What's the benefit of mak

Re: [Qemu-devel] Deprecation policy and build dependencies

On Mon, 3 Jun 2019 14:02:16 -0400 John Snow wrote: > On 6/3/19 8:26 AM, Markus Armbruster wrote: > > John Snow writes: > > > >> On 5/31/19 3:24 PM, Eduardo Habkost wrote: > >>> Long story short: I would really like to drop support for Python > >>> 2 in QEMU 4.1. > > > > The sooner, the b

Re: [Qemu-devel] [PATCH 2/2] target/arm: Use tcg_gen_gvec_bitsel

On 5/23/19 8:30 AM, Peter Maydell wrote: > On Thu, 23 May 2019 at 14:16, Richard Henderson > wrote: >> >> On 5/23/19 9:08 AM, Peter Maydell wrote: Because the three different instructions perform the same operation with reshuffled register arguments. >>> >>> Ah, so they do. Next question

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 6/3/19 2:12 PM, Michael S. Tsirkin wrote: On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote: On 5/28/19 10:54 PM, Michael S. Tsirkin wrote: On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote: On 5/21/2019 11:49 AM, Jens Freimann wrote: On Tue, May 21, 2019 at 07:37:19AM

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

On 6/3/19 4:24 AM, Jens Freimann wrote: On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote: On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote: On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote: > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan

Re: [Qemu-devel] [PULL 00/24] Misc patches for 2019-06-03

On Mon, 3 Jun 2019 at 18:12, Paolo Bonzini wrote: > > The following changes since commit ad88e4252f09c2956b99c90de39e95bab2e8e7af: > > Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-1-2019' > into staging (2019-06-03 10:25:12 +0100) > > are available in the git repository a

Re: [Qemu-devel] [PATCH v2 0/2] Add QMP lexer for annotated JSON to Sphinx

Peter: I think this one would be through your tree if anyone's, yes? Any thoughts? --js On 5/23/19 8:12 AM, John Snow wrote: > QMP isn't json. It turns out Pygments cares about this. > Teach Pygments to go with the annotated flow. > > V2: > - Change GPL2 to GPLv2+ (Peter Maydell) > - Change "h

[Qemu-devel] [PULL v2 14/14] bios-tables-test: list all tables that differ

Fail after comparing all tables: this way user gets the full list of tables that need to be updated or whitelisted. Signed-off-by: Michael S. Tsirkin --- tests/bios-tables-test.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/bios-tables-test.c b/tests/bios-table

[Qemu-devel] [PULL v2 13/14] vhost-scsi: Allow user to enable migration

From: Liran Alon In order to perform a valid migration of a vhost-scsi device, the following requirements must be met: (1) The virtio-scsi device state needs to be saved & loaded. (2) The vhost backend must be stopped before virtio-scsi device state is saved: (2.1) Sync vhost backend state to v

[Qemu-devel] [PULL v2 11/14] vhost-scsi: The vhost backend should be stopped when the VM is not running

From: Nir Weiner vhost-scsi doesn’t takes into account whether the VM is running or not in order to decide if it should start/stop vhost backend. This would lead to vhost backend still being active when VM's RunState suddenly change to stopped. An example of when this issue is encountered is whe

[Qemu-devel] [PULL v2 12/14] vhost-scsi: Add VMState descriptor

From: Nir Weiner As preparation of enabling migration of vhost-scsi device, define it’s VMState. Note, we keep the convention of verifying in the pre_save() method that the vhost backend must be stopped before attempting to save the device state. Similar to how it is done for vhost-vsock. Review

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote: > On 5/28/19 10:54 PM, Michael S. Tsirkin wrote: > > On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote: > > > > > > > > > On 5/21/2019 11:49 AM, Jens Freimann wrote: > > > > On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S.

[Qemu-devel] [PULL v2 10/14] bios-tables-test: add diff allowed list

Expected table change is then handled like this: 1. add table to diff allowed list 2. change generating code (can be combined with 1) 3. maintainer runs a script to update expected + blows away allowed diff list Signed-off-by: Michael S. Tsirkin --- tests/bios-tables-test-allowed-diff.h | 1

[Qemu-devel] [PULL v2 00/14] virtio, pci, pc: cleanups, features

The following changes since commit 8c1ecb590497b0349c550607db923972b37f6963: Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-next-280519-2' into staging (2019-05-28 17:38:32 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git ta

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 5/28/19 10:54 PM, Michael S. Tsirkin wrote: On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote: On 5/21/2019 11:49 AM, Jens Freimann wrote: On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote: On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote: On Mon, M

Re: [Qemu-devel] Deprecation policy and build dependencies

On 6/3/19 8:26 AM, Markus Armbruster wrote: > John Snow writes: > >> On 5/31/19 3:24 PM, Eduardo Habkost wrote: >>> Long story short: I would really like to drop support for Python >>> 2 in QEMU 4.1. > > The sooner, the better, as far as I'm concerned. > >>> What exactly prevents us from doi

Re: [Qemu-devel] [PULL 22/27] vl: Create block backends before setting machine properties

I apologize for the delay, got distracted. Michal Privoznik writes: > On 5/16/19 1:43 PM, Markus Armbruster wrote: > > >>> Actually, there is more problems with this. Trying to run a guest with >>> persistent reservations fails after this patch is applied (git bisect >>> points me to this commi

[Qemu-devel] qemu build error with latest kernel headers due to net: socket: implement 64-bit timestamps

Arnd, with kernel headers from the latest kernel QEMU fails to build if the user run configure with --target-list=s390x-linux-user: when the kernel has commit 0768e17073dc527ccd18ed5f96ce85f9985e9115 net: socket: implement 64-bit timestamps /root/rpmbuild/BUILD/qemu-4.0.50/linux-user/ioct

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

** Attachment added: "bzImage-4.12.0-x64" https://bugs.launchpad.net/bugs/1830872/+attachment/5268560/+files/bzImage-4.12.0-x64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1830872 Title: AARC

[Qemu-devel] [PULL 22/24] ci: store Patchew configuration in the tree

Patchew cannot yet retrieve the configuration from the QEMU Git tree, but this is planned. In the meanwhile, let's start storing it as YAML so that the Patchew configuration (currently accessible only to administrators) is public and documented. Signed-off-by: Paolo Bonzini --- .patchew.yml | 3

[Qemu-devel] [PULL 06/24] edu: mmio: allow 64-bit access

From: Li Qiang The edu spec says the MMIO area can be accessed by 64-bit. However currently the 'max_access_size' is not so the MMIO access dispatch can only access 32-bit one time. This patch fixes this to respect the spec. Signed-off-by: Li Qiang Reviewed-by: Philippe Mathieu-Daude Message-I

Re: [Qemu-devel] [PATCH 1/2] target/arm: Vectorize USHL and SSHL

On 5/23/19 8:03 AM, Peter Maydell wrote: > On Thu, 23 May 2019 at 13:44, Peter Maydell wrote: >> >> On Sat, 18 May 2019 at 20:19, Richard Henderson >> wrote: >>> >>> These instructions shift left or right depending on the sign >>> of the input, and 7 bits are significant to the shift. This >>> r

  1   2   3   >