Re: [Qemu-devel] Internship idea: virtio-blk oss-fuzz support

[Ccing Nitesh] Stefan Hajnoczi writes: > On Fri, Jan 11, 2019 at 05:16:40PM +0100, Paolo Bonzini wrote: >> On 11/01/19 16:41, Max Moroz wrote: >> > On Fri, Jan 11, 2019 at 7:34 AM Paolo Bonzini > > > wrote: >> > >> > On 11/01/19 16:04, Max Moroz wrote: >> > >

Re: [Qemu-devel] PING: [PATCH] blk: postpone request execution on a context protected with "drained section"

On 17.01.2019 17:23, Kevin Wolf wrote: > Am 17.01.2019 um 13:57 hat Denis Plotnikov geschrieben: >> Kevin, >> >> could you please take a look at my last comments? > > I read it, and what it told me is essentially that I need to work on it > myself to fully understand the problem and possible

Re: [Qemu-devel] [RFC PATCH v2 24/37] build: convert sound.mak to Kconfig

On Wed, Jan 16, 2019 at 02:51:37PM +0100, Thomas Huth wrote: > On 2019-01-16 14:48, Thomas Huth wrote: > > On 2019-01-15 15:10, Yang Zhong wrote: > >> From: Paolo Bonzini > >> > >> There is really nothing special in these devices; they are just > >> ISA devices. Instead of including them for

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

On Tue, Jan 15, 2019 at 03:13:14PM +0800, Yu Zhang wrote: > On Fri, Dec 28, 2018 at 11:29:41PM -0200, Eduardo Habkost wrote: > > On Fri, Dec 28, 2018 at 10:32:59AM +0800, Yu Zhang wrote: > > > On Thu, Dec 27, 2018 at 01:14:11PM -0200, Eduardo Habkost wrote: > > > > On Wed, Dec 26, 2018 at

Re: [Qemu-devel] [RFC PATCH v2 23/37] build: convert pci.mak to Kconfig

On Wed, Jan 16, 2019 at 12:41:17PM +0100, Thomas Huth wrote: > > The e1000e is a PCI-e device, so maybe this should rather depend on > "PCIE" instead? > Thanks Thomas, yes, i will change this. Yang > With that fixed: > > Reviewed-by: Thomas Huth > > > > config RTL8139_PCI > > bool

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On Fri, 18 Jan 2019 at 12:00, Jason Wang wrote: > > > On 2019/1/18 上午11:32, Yongji Xie wrote: > > On Thu, 17 Jan 2019 at 17:57, Jason Wang wrote: > >> > >> On 2019/1/15 下午10:51, Yongji Xie wrote: > Well, this may work but here're my points: > > 1) The code want to recover from

Re: [Qemu-devel] [RFC PATCH v2 19/37] kconfig: introduce kconfig files

Hello Thomas, Thanks for detailed comments, i will add those into v3 patches. Regards, Yang

Re: [Qemu-devel] [RFC PATCH v2 19/37] kconfig: introduce kconfig files

On Wed, Jan 16, 2019 at 03:06:33PM +0100, Thomas Huth wrote: > FWIW, looks like we still need alpha/Kconfig, cris/Kconfig, > hppa/Kconfig, unicore32/Kconfig, tricore/Kconfig and xtensa/Kconfig ? > Hello Thomas, v3 will add below new ARCH/Kconfig alpha/Kconfig cris/Kconfig

Re: [Qemu-devel] [RFC PATCH v2 19/37] kconfig: introduce kconfig files

On Wed, Jan 16, 2019 at 11:44:13AM +0100, Thomas Huth wrote: > > +source ipmi/Kconfig > > +source vfio/Kconfig > > +source adc/Kconfig > > +source pcmcia/Kconfig > > +source hyperv/Kconfig > > Could you please sort the last 5 entries alphabetically into the list? Thanks Thomas, i will change

Re: [Qemu-devel] Live migration from Qemu 2.12 hosts to Qemu 3.2 hosts, with VMX flag enabled in the guest?

On Fri, Jan 18, 2019 at 7:33 AM Mark Mielke wrote: > > Thank you for the work on nested virtualization. Having had live migrations > fail in the past when nested virtualization has been active, it is great to > see that clever people have been working on this problem! > > My question is about

Re: [Qemu-devel] [PATCH v10 12/24] replay: introduce breakpoint at the specified step

> From: Markus Armbruster [mailto:arm...@redhat.com] > Pavel Dovgalyuk writes: > > > This patch introduces replay_break, replay_delete_break > > qmp and hmp commands. > > These commands allow stopping at the specified instruction. > > It may be useful for debugging when there are some known > >

[Qemu-devel] Live migration from Qemu 2.12 hosts to Qemu 3.2 hosts, with VMX flag enabled in the guest?

Thank you for the work on nested virtualization. Having had live migrations fail in the past when nested virtualization has been active, it is great to see that clever people have been working on this problem! My question is about whether a migration path has been considered to allow live

Re: [Qemu-devel] [PATCH v2] hw/vfio/common: Refactor container initialization

On 18/01/2019 08:02, Eric Auger wrote: > In vfio_connect_container() the code that selects the > iommu type can benefit from helpers such as > vfio_iommu_get_type() and vfio_init_container(). As > a result we end up with a switch/case on the iommu type > that makes the code a little bit more

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On Fri, Jan 18, 2019 at 11:59:50AM +0800, Jason Wang wrote: > > On 2019/1/18 上午11:32, Yongji Xie wrote: > > On Thu, 17 Jan 2019 at 17:57, Jason Wang wrote: > > > > > > On 2019/1/15 下午10:51, Yongji Xie wrote: > > > > > Well, this may work but here're my points: > > > > > > > > > > 1) The code

Re: [Qemu-devel] [PATCH 1/2] vfio-pci: Introduce vfio_register_event_notifier helper

On 17/01/2019 20:16, Auger Eric wrote: > Hi Alexey, Cornelia, > > On 1/17/19 4:46 AM, Alexey Kardashevskiy wrote: >> >> >> On 12/01/2019 03:58, Eric Auger wrote: >>> The code used to attach the eventfd handler for the ERR and >>> REQ irq indices can be factorized into a helper. In subsequent

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On 2019/1/18 上午11:32, Yongji Xie wrote: On Thu, 17 Jan 2019 at 17:57, Jason Wang wrote: On 2019/1/15 下午10:51, Yongji Xie wrote: Well, this may work but here're my points: 1) The code want to recover from backed crash by introducing extra space to store inflight data, but it still depends

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On 2019/1/17 下午10:59, Michael S. Tsirkin wrote: On Thu, Jan 17, 2019 at 05:57:29PM +0800, Jason Wang wrote: On 2019/1/15 下午10:51, Yongji Xie wrote: Well, this may work but here're my points: 1) The code want to recover from backed crash by introducing extra space to store inflight data, but

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On Fri, Jan 18, 2019 at 11:32:03AM +0800, Yongji Xie wrote: > On Thu, 17 Jan 2019 at 17:57, Jason Wang wrote: > > > > > > On 2019/1/15 下午10:51, Yongji Xie wrote: > > >> Well, this may work but here're my points: > > >> > > >> 1) The code want to recover from backed crash by introducing extra

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory

On Thu, 17 Jan 2019 at 17:57, Jason Wang wrote: > > > On 2019/1/15 下午10:51, Yongji Xie wrote: > >> Well, this may work but here're my points: > >> > >> 1) The code want to recover from backed crash by introducing extra space > >> to store inflight data, but it still depends on the backend to

Re: [Qemu-devel] [PATCH v4 for-4.0 2/7] vhost-user: Support transferring inflight buffer between qemu and backend

On Tue, 15 Jan 2019 at 22:18, Yongji Xie wrote: > > On Tue, 15 Jan 2019 at 20:54, Michael S. Tsirkin wrote: > > > > On Tue, Jan 15, 2019 at 02:46:42PM +0800, Yongji Xie wrote: > > > On Tue, 15 Jan 2019 at 06:25, Michael S. Tsirkin wrote: > > > > > > > > On Wed, Jan 09, 2019 at 07:27:23PM +0800,

Re: [Qemu-devel] [PULL v2 00/49] pci, pc, virtio: fixes, features

On Thu, Jan 17, 2019 at 04:21:24PM +, Peter Maydell wrote: > On Thu, 17 Jan 2019 at 13:44, Michael S. Tsirkin wrote: > > > > On Thu, Jan 17, 2019 at 12:48:22PM +, Peter Maydell wrote: > > > This fails 'make check' on s390x host: > > > Oh. I am pretty sure it's endian-ness :( > > > > Any

Re: [Qemu-devel] Questions about VFIO enabling MSIX vector

On 2019/1/17 23:21, Alex Williamson wrote: On Thu, 17 Jan 2019 20:55:05 +0800 Heyi Guo wrote: On 2019/1/16 0:18, Alex Williamson wrote: On Tue, 15 Jan 2019 11:21:51 +0800 Heyi Guo wrote: Hi Alex, Really appreciate your comments. I have some more questions below. On 2019/1/15 0:07,

Re: [Qemu-devel] Emulation of TCG OPAL self-encrypting drive

On 1/17/19 6:04 PM, David Kozub wrote: > On Wed, 16 Jan 2019, John Snow wrote: > >> I can answer some questions about the ATA layer, but I'm not well read >> on OPAL or the interrelationship between the two. >> >> We don't have an ATA-style passthrough in QEMU right now and nobody has >> ever

Re: [Qemu-devel] [PATCH 00/27] slirp: make it again a standalone project (part 2)

Also thinking about it: I guess we'd want to make the usage of libslirp optional, at least because (I guess) at some points the future libslirp may want to change the API (nobody can do something perfect at first try), and when that breaks qemu build it would nasty if people couldn't just disable

Re: [Qemu-devel] [PATCH 01/27] slirp: generalize guestfwd with a callback based approach

Marc-André Lureau, le jeu. 17 janv. 2019 15:43:33 +0400, a ecrit: > /* XXX this blocks entire thread. Rewrite to use > * qemu_chr_fe_write and background I/O callbacks */ Seeing this, I guess a whole pass will be useful to turn these qemu comment references into something that

Re: [Qemu-devel] Emulation of TCG OPAL self-encrypting drive

On Wed, 16 Jan 2019, John Snow wrote: I can answer some questions about the ATA layer, but I'm not well read on OPAL or the interrelationship between the two. We don't have an ATA-style passthrough in QEMU right now and nobody has ever asked! Would you mind elaborating for me what kind of

Re: [Qemu-devel] [PATCH 21/27] slirp: prefer c99 types over BSD kind

Marc-André Lureau, le jeu. 17 janv. 2019 15:43:53 +0400, a ecrit: > (indentation mess is hopefully going to be fixed when slirp is made a > separate project and clang-format is applied over the history) Yes, let's do it :) Samuel

Re: [Qemu-devel] [PATCH 09/27] slirp: replace qemu_set_nonblock()

Hi On Thu, Jan 17, 2019 at 9:55 PM Eric Blake wrote: > > On 1/17/19 5:43 AM, Marc-André Lureau wrote: > > Replace qemu_set_nonblock() with slirp_set_nonblock() > > > > qemu_set_nonblock() does some event registration with the main > > loop. Add a new callback register_poll_fd() for that reason.

Re: [Qemu-devel] [PATCH 3/5] vfio/display: add xres + yres properties

On Fri, 11 Jan 2019 10:31:14 +0100 Gerd Hoffmann wrote: > This allows configure the display resolution which the vgpu should use. > The information will be passed to the guest using EDID, so the mdev > driver must support the vfio edid region for this to work. > > Signed-off-by: Gerd Hoffmann

Re: [Qemu-devel] [PATCH 4/5] vfio/display: delay link up event

On Fri, 11 Jan 2019 10:31:15 +0100 Gerd Hoffmann wrote: > Kick the display link up event with a 0.1 sec delay, > so the guest has a chance to notice the link down first. > > Signed-off-by: Gerd Hoffmann > --- > include/hw/vfio/vfio-common.h | 1 + > hw/vfio/display.c | 22

Re: [Qemu-devel] [PATCH 2/5] vfio/display: add edid support.

On Fri, 11 Jan 2019 10:31:13 +0100 Gerd Hoffmann wrote: > This patch adds EDID support to the vfio display (aka vgpu) code. > When supported by the mdev driver qemu will generate a EDID blob > and pass it on using the new vfio edid region. The EDID blob will > be updated on UI changes (i.e.

[Qemu-devel] [PATCH 1/2] memory: Fix the memory region type assignment order

Currently, a callback registered through the RAMBlock notifier is not able to get the memory region type (i.e callback is not able to use memory_region_is_ram_device function). This is because mr->ram assignment happens _after_ the memory is allocated whereas the callback is executed during

[Qemu-devel] [PATCH 2/2] target/i386: sev: Do not pin the ram device memory region

The RAM device presents a memory region that should be handled as an IO region and should not be pinned. In the case of the vfio-pci, RAM device represents a MMIO BAR and the memory region is not backed by pages hence KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range. Fixes:

[Qemu-devel] [PATCH 0/2] Fix SEV VM device assignment

Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 Brijesh Singh (2): memory: Fix the memory region type assignment order target/i386: sev: Do not pin the ram device memory region memory.c | 9 - target/i386/sev.c | 11 +++ 2 files changed, 19 insertions(+),

Re: [Qemu-devel] [PATCH v5 4/6] nbd/server: implement dirty bitmap export

On 1/9/19 2:21 PM, Eric Blake wrote: > Why are we restricting things to only export disabled bitmaps? Late reply, but the original thought almost surely was that we would only be exporting bitmaps for fleecing use, which should have a non-changing bitmap attached to it. Just some error

[Qemu-devel] [PATCH v2 1/2] vfio-pci: Introduce vfio_set_event_handler helper

The code used to attach the eventfd handler for the ERR and REQ irq indices can be factorized into a helper. In subsequent patches we will extend this helper to support other irq indices. We test whether the notification is allowed outside of the helper: respectively check vdev->pci_aer and

[Qemu-devel] [PATCH v2 0/2] vfio-pci: Introduce vfio_set_event_handler()

This small series introduces the vfio_set_event_handler() helper which allows to set up/tear down the VFIO signalling of eventfd for ERR, REQ and INTX irq indices. On top of that, a new irq index is planned to signal DMA faults in nested mode use case. This would use exactly the same mechanics.

[Qemu-devel] [PATCH v2 2/2] vfio-pci: Use vfio_set_event_handler in vfio_intx_enable

vfio_set_event_handler() can be used in vfio_intx_enable() to set the signalling associated with VFIO_PCI_INTX_IRQ_INDEX. We also turn vfio_intx_enable() into a void function. Signed-off-by: Eric Auger --- vfio_set_event_handler cannot be used in vfio_intx_disable. The reason is not a call

[Qemu-devel] [PATCH v2] hw/vfio/common: Refactor container initialization

In vfio_connect_container() the code that selects the iommu type can benefit from helpers such as vfio_iommu_get_type() and vfio_init_container(). As a result we end up with a switch/case on the iommu type that makes the code a little bit more readable and ready for addition of new iommu types.

Re: [Qemu-devel] [PATCH 0/3] WHPX introduce changes for Windows Insider SDK 17110

Am 14.03.2018 um 15:52 schrieb Justin Terry (VM) via Qemu-devel: > This change set fixes two breaking changes that were introduced in the > Windows Insider SDK 17110. First, a change to the WHvGetCapability function > decl to include the 'out' WrittenSizeInBytes. Second, changes to the >

Re: [Qemu-devel] [PATCH v10 14/14] target/arm: Send interrupts on PMU counter overflow

On 12/12/18 2:20 AM, Aaron Lindsay wrote: > Setup a QEMUTimer to get a callback when we expect counters to next > overflow and trigger an interrupt at that time. > > Signed-off-by: Aaron Lindsay > Signed-off-by: Aaron Lindsay > --- > target/arm/cpu.c| 12 + > target/arm/cpu.h| 8

[Qemu-devel] [PULL 9/9] scripts/replay-dump.py: fix utf-8 mangling

From: Alex Bennée Signed-off-by: Alex Bennée Message-Id: <20190117153338.11820-1-alex.ben...@linaro.org> Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Cleber Rosa Signed-off-by: Eduardo Habkost --- scripts/replay-dump.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Qemu-devel] [PULL 7/9] Acceptance tests: add Linux initrd checking test

From: Wainer dos Santos Moschetta QEMU used to exits with a not accurate error message when an initrd > 2GiB was passed. That was fixed on patch: commit f3839fda5771596152b75dd1e1a6d050e6e6e380 Author: Li Zhijian Date: Thu Sep 13 18:07:13 2018 +0800 change

[Qemu-devel] [PULL 6/9] check-help: visual and content improvements

From: Cleber Rosa The "check" target is not a target that will run all other tests listed, so in order to be accurate it's necessary to list those that will run. The same is true for "check-clean". Then, to give a better visual impression of the differences in the various targets, let's add

[Qemu-devel] [PULL 2/9] scripts: Remove unused python imports

From: Philippe Mathieu-Daudé Reported-by: LGTM code review Signed-off-by: Philippe Mathieu-Daudé Message-Id: <20181108143422.15955-1-phi...@redhat.com> Signed-off-by: Eduardo Habkost --- scripts/analyse-locks-simpletrace.py | 1 - scripts/analyze-migration.py | 1 -

[Qemu-devel] [PULL 4/9] check-venv: use recorded Python version

From: Cleber Rosa The current approach works fine, but it runs Python on every make command (even if it's not related to the venv usage). This is just an optimization, and not a change of behavior. Signed-off-by: Cleber Rosa Message-Id: <20181109150710.31085-3-cr...@redhat.com> Signed-off-by:

[Qemu-devel] [PULL 8/9] qemu.py: Fix error message when qemu dies from signal

From: Eric Blake When qemu dies from a signal, the python code gets a negative value for exitcode; but signal numbers are positive. Copy the pattern used in qemu-iotests/iotests.py for reporting a positive value. CC: qemu-triv...@nongnu.org Signed-off-by: Eric Blake Message-Id:

[Qemu-devel] [PULL 5/9] Travis CI: make specified Python versions usable on jobs

From: Cleber Rosa For the two Python jobs, which seem to have the goal of making sure QEMU builds successfully on the 3.0-3.6 spectrum of Python 3 versions, the specified version is only applicable if a Python virtual environment is used. To do that, it's necessary to define the (primary?)

[Qemu-devel] [PULL 1/9] scripts/device-crash-test: Remove known crashes

From: Thomas Huth Looks like we've fixed them all already in the past months, e.g. with: f7d6bfcdc0fe49040aac3ac131a319cb5427957e spapr_pci: fail gracefully with non-pseries machine types 2363d5ee231bf047479422d56d3b85b7d37a7c23 hw/ppc/spapr_cpu_core: Add a proper check for spapr machine

[Qemu-devel] [PULL 0/9] Python queue, 2019-01-17

The following changes since commit 681d61362d3f766a00806b89d6581869041f73cb: Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-01-17 12:48:42 +) are available in the Git repository at: git://github.com/ehabkost/qemu.git

[Qemu-devel] [PULL 3/9] configure: keep track of Python version

From: Cleber Rosa Some functionality is dependent on the Python version detected/configured on configure. While it's possible to run the Python version later and check for the version, doing it once is preferable. Also, it's a relevant information to keep in build logs, as the overall behavior

Re: [Qemu-devel] [PULL 0/7] check-softfloat, fp-bench and clang compile fixes

Peter Maydell writes: > On Thu, 17 Jan 2019 at 18:30, Emilio G. Cota wrote: >> >> On Thu, Jan 17, 2019 at 17:37:54 +, Peter Maydell wrote: >> > On Thu, 17 Jan 2019 at 13:27, Alex Bennée wrote: >> > > >> > > The following changes since commit >> > >

Re: [Qemu-devel] [PULL 0/7] check-softfloat, fp-bench and clang compile fixes

On Thu, Jan 17, 2019 at 18:55:33 +, Peter Maydell wrote: > On Thu, 17 Jan 2019 at 18:30, Emilio G. Cota wrote: > > What are the contents of "int-to-float.err"? > > linux1@lxub05:~$ cat qemu/build/all/tests/fp/int-to-float.err > >> Testing i32_to_f16, rounding near_even > 372 tests total. >

[Qemu-devel] [PATCH v4 13/21] nbd/client: Refactor return of nbd_receive_negotiate()

The function could only ever return 0 or -EINVAL; make this clearer by dropping a useless 'fail:' label. Signed-off-by: Eric Blake Reviewed-by: Richard W.M. Jones Reviewed-by: Vladimir Sementsov-Ogievskiy Message-Id: <20181215135324.152629-16-ebl...@redhat.com> --- nbd/client.c | 51

[Qemu-devel] [PATCH v4 12/21] nbd/client: Split out nbd_receive_one_meta_context()

Extract portions of nbd_negotiate_simple_meta_context() to a new function nbd_receive_one_meta_context() that copies the pattern of nbd_receive_list() for performing the argument validation of one reply. The error message when the server replies with more than one context changes slightly, but

Re: [Qemu-devel] [PATCH] hw/core/generic-loader: Fix PC overwriting

On Thu, 17 Jan 2019 at 19:27, Peter Maydell wrote: > recent gdb neither emits > 'c addr' nor supports it in its gdbserver implementation ...and I dug about in the gdb git history, and as far as I can tell even back in 2005 or so gdb's gdbserver never supported the 'addr' parameter to 'c' and

Re: [Qemu-devel] [PATCH] dmg: fix binary search

On 1/17/19 2:29 PM, John Snow wrote: > > > On 12/21/18 8:58 AM, yuchenlin wrote: >> There is a possible hang in original binary searsh implemtation. That is >> if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case. >> >> The chunk1 will be still 4, and so on. >> >> Signed-off-by:

[Qemu-devel] [PATCH v4 10/21] nbd/client: Change signature of nbd_negotiate_simple_meta_context()

Pass 'info' instead of three separate parameters related to info, when requesting the server to set the meta context. Update the NBDExportInfo struct to rename the received id field to match the fact that we are currently overloading the field to match whatever context the user supplied through

[Qemu-devel] [PATCH v4 19/21] qemu-nbd: Add --list option

We want to be able to detect whether a given qemu NBD server is exposing the right export(s) and dirty bitmaps, at least for regression testing. We could use 'nbd-client -l' from the upstream NBD project to list exports, but it's annoying to rely on out-of-tree binaries; furthermore, nbd-client

Re: [Qemu-devel] [PATCH v6 4/4] i386: allow to load initrd below 4 GB for recent linux

On Thu, Jan 17, 2019 at 08:49:04PM +0800, Li Zhijian wrote: > Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version > 2)") > linux has supported initrd up to 4 GB, but the header field > ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs". > > When use

[Qemu-devel] [PATCH v4 17/21] nbd/client: Add nbd_receive_export_list()

We want to be able to detect whether a given qemu NBD server is exposing the right export(s) and dirty bitmaps, at least for regression testing. We could use 'nbd-client -l' from the upstream NBD project to list exports, but it's annoying to rely on out-of-tree binaries; furthermore, nbd-client

[Qemu-devel] [PATCH v4 16/21] nbd/client: Refactor nbd_opt_go() to support NBD_OPT_INFO

Rename the function to nbd_opt_info_or_go() with an added parameter and slight changes to comments and trace messages, in order to reuse the function for NBD_OPT_INFO. Signed-off-by: Eric Blake --- v4: split out new patch [Vladimir] --- nbd/client.c | 36

[Qemu-devel] [PATCH v4 21/21] iotests: Enhance 223, 233 to cover 'qemu-nbd --list'

Any good new feature deserves some regression testing :) Coverage includes: - 223: what happens when there are 0 or more than 1 export, proof that we can see multiple contexts including qemu:dirty-bitmap - 233: proof that we can list over TLS, and that mix-and-match of plain/TLS listings will

[Qemu-devel] [PATCH v4 18/21] nbd/client: Add meta contexts to nbd_receive_export_list()

We want to be able to detect whether a given qemu NBD server is exposing the right export(s) and dirty bitmaps, at least for regression testing. We could use 'nbd-client -l' from the upstream NBD project to list exports, but it's annoying to rely on out-of-tree binaries; furthermore, nbd-client

[Qemu-devel] [PATCH v4 14/21] nbd/client: Split handshake into two functions

An upcoming patch will add the ability for qemu-nbd to list the services provided by an NBD server. Share the common code of the TLS handshake by splitting the initial exchange into a separate function, leaving only the export handling in the original function. Functionally, there should be no

[Qemu-devel] [PATCH v4 11/21] nbd/client: Split out nbd_send_meta_query()

Refactor nbd_negotiate_simple_meta_context() to pull out the code that can be reused to send a LIST request for 0 or 1 query. No semantic change. The old comment about 'sizeof(uint32_t)' being equivalent to '/* number of queries */' is no longer needed, now that we are computing 'sizeof(queries)'

[Qemu-devel] [PATCH v4 07/21] qemu-nbd: Avoid strtol open-coding

Our copy-and-pasted open-coding of strtol handling forgot to handle overflow conditions. Use qemu_strto*() instead. In the case of --partition, since we insist on a user-supplied partition to be non-zero, we can use 0 rather than -1 for our initial value to distinguish when a partition is not

[Qemu-devel] [PATCH v4 20/21] nbd/client: Work around 3.0 bug for listing meta contexts

Commit 3d068aff forgot to advertise available qemu: contexts when the client requests a list with 0 queries. Furthermore, 3.0 shipped with a qemu-img hack of x-dirty-bitmap (commit 216ee365) that _silently_ acts as though the entire image is clean if a requested bitmap is not present. Both bugs

[Qemu-devel] [PATCH v4 15/21] nbd/client: Pull out oldstyle size determination

Another refactoring creating nbd_negotiate_finish_oldstyle() for further reuse during 'qemu-nbd --list'. Signed-off-by: Eric Blake Reviewed-by: Richard W.M. Jones --- nbd/client.c | 49 - 1 file changed, 32 insertions(+), 17 deletions(-) diff

[Qemu-devel] [PATCH v4 03/21] qemu-nbd: Enhance man page

Document some useful qemu-nbd command lines. Mention some restrictions on particular options, like -p being only for MBR images, or -c/-d being Linux-only. Update some text given the recent change to no longer serve oldstyle protocol (missed in commit 7f7dfe2a). Also, consistently use trailing

[Qemu-devel] [PATCH v4 08/21] nbd/client: Refactor nbd_receive_list()

Right now, nbd_receive_list() is only called by nbd_receive_query_exports(), which in turn is only called if the server lacks NBD_OPT_GO but has working option negotiation, and is merely used as a quality-of-implementation trick since servers can't give decent errors for NBD_OPT_EXPORT_NAME.

[Qemu-devel] [PATCH v4 09/21] nbd/client: Move export name into NBDExportInfo

Refactor the 'name' parameter of nbd_receive_negotiate() from being a separate parameter into being part of the in-out 'info'. This also spills over to a simplification of nbd_opt_go(). The main driver for this refactoring is that an upcoming patch would like to add support to qemu-nbd to list

[Qemu-devel] [PATCH v4 05/21] nbd/server: Hoist length check to qmp_nbd_server_add

We only had two callers to nbd_export_new; qemu-nbd.c always passed a valid offset/length pair (because it already checked the file length, to ensure that offset was in bounds), while blockdev-nbd.c always passed 0/-1. Then nbd_export_new reduces the size to a multiple of BDRV_SECTOR_SIZE (can

[Qemu-devel] [PATCH v4 04/21] qemu-nbd: Sanity check partition bounds

When the user requests a partition, we were using data read from the disk as disk offsets without a bounds check. We got lucky that even when computed offsets are out-of-bounds, blk_pread() will gracefully catch the error later (so I don't think a malicious image can crash or exploit qemu-nbd, and

[Qemu-devel] [PATCH v4 02/21] maint: Allow for EXAMPLES in texi2pod

The next commit will add an EXAMPLES section to qemu-nbd.8; for that to work, we need to recognize EXAMPLES in texi2pod. We also need to add a dependency from all man pages against the generator script, since a change to the generator may cause the resulting man page to differ. Signed-off-by:

[Qemu-devel] [PATCH v4 06/21] nbd/server: Favor [u]int64_t over off_t

Although our compile-time environment is set up so that we always support long files with 64-bit off_t, we have no guarantee whether off_t is the same type as int64_t. This requires casts when printing values, and prevents us from directly using qemu_strtoi64() (which will be done in the next

[Qemu-devel] [PATCH v4 01/21] iotests: Make 233 output more reliable

We have a race between the nbd server and the client both trying to report errors at once which can make the test sometimes fail if the output lines swap order under load. Break the race by collecting server messages into a file and then replaying that at the end of the test. Signed-off-by: Eric

Re: [Qemu-devel] [PATCH] ARM: GIC: error out early when creating VGICv2 failed

On Thu, 17 Jan 2019 at 03:09, Shannon Zhao wrote: > > Currently if creating a gicv2 VM on the platform without > VGICv2 support, it failed in kvm_arm_pmu_set_irq while > trying to set the interrupt number for PMU with below > error message. > KVM_SET_DEVICE_ATTR failed: Invalid argument > > This

[Qemu-devel] [PATCH v4 00/21] nbd: add qemu-nbd --list

I got tired of debugging whether a server was advertising the correct things during negotiation by inspecting the trace logs of qemu-io as client - not to mention that without SOME sort of client tracing particular commands, we can't easily regression test the server for correct behavior. The

Re: [Qemu-devel] [PATCH] dmg: fix binary search

On 12/21/18 8:58 AM, yuchenlin wrote: > There is a possible hang in original binary searsh implemtation. That is > if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case. > > The chunk1 will be still 4, and so on. > > Signed-off-by: yuchenlin Generally we ask that people use their full

Re: [Qemu-devel] [PATCH] hw/core/generic-loader: Fix PC overwriting

On Thu, 17 Jan 2019 at 10:58, Julia Suvorova wrote: > > On 17.01.2019 13:13, Stefan Hajnoczi wrote: > > generic_loader_reset() calls cpu_reset(s->cpu) followed by > > CPUClass->set_pc(s->cpu, s->addr). > > > > ARM's arm_cpu_set_pc() doesn't special-case the Thumb bit (that's only > > done in

[Qemu-devel] [PATCH 16/18] Boot Linux Console Test: add a test for arm + virt

Just like the previous tests, boots a Linux kernel on an arm target using the virt machine. Signed-off-by: Cleber Rosa --- .travis.yml| 2 +- tests/acceptance/boot_linux_console.py | 19 +++ 2 files changed, 20 insertions(+), 1 deletion(-) diff

[Qemu-devel] [PATCH 01/18] scripts/qemu.py: log QEMU launch command line

Even when the launch of QEMU succeeds, it's useful to have the command line recorded. Signed-off-by: Cleber Rosa --- scripts/qemu.py | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/qemu.py b/scripts/qemu.py index 6e3b0e6771..ec3567d4e2 100644 --- a/scripts/qemu.py +++

[Qemu-devel] [PATCH 17/18] Boot Linux Console Test: add a test for s390x + s390-ccw-virtio

Just like the previous tests, boots a Linux kernel on a s390x target using the s390-ccw-virtio machine. Because it's not possible to have multiple VT220 consoles, '-nodefaults' is used, so that the one set with set_console() works correctly. Signed-off-by: Cleber Rosa --- .travis.yml

[Qemu-devel] [PATCH 13/18] Boot Linux Console Test: add a test for mips64el + malta

Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta board and verify the serial is working. If mips64el is a target being built, "make check-acceptance" will automatically include this test by the use of the "arch:mips" tags. Alternatively, this test can be run using: $

[Qemu-devel] [PATCH 06/18] Acceptance tests: use "arch:" tag to filter target specific tests

Currently, the only test that contains some target architecture information is "boot_linux_console.py" which test contains a "x86_64" tag. But that tag is not respected in the default execution, that is, "make check-acceptance" doesn't do anything with it. That said, even the target architecture

[Qemu-devel] [PATCH 08/18] Boot Linux Console Test: rename the x86_64 after the arch and machine

Given that the test is specific to x86_64 and pc, and new tests are going to be added to the same class, let's rename it accordingly. Also, let's make the class documentation not architecture specific. Signed-off-by: Cleber Rosa --- tests/acceptance/boot_linux_console.py | 11 +++ 1

[Qemu-devel] [PATCH 03/18] Acceptance tests: improve docstring on pick_default_qemu_bin()

Making it clear what is returned by this utility function. Signed-off-by: Cleber Rosa Reviewed-by: Philippe Mathieu-Daudé --- tests/acceptance/avocado_qemu/__init__.py | 4 1 file changed, 4 insertions(+) diff --git a/tests/acceptance/avocado_qemu/__init__.py

[Qemu-devel] [PATCH 18/18] Boot Linux Console Test: add a test for alpha + clipper

Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta board and verify the serial is working. One extra command added to the QEMU command line is '-vga std', because the kernel used is known to crash without it. If alpha is a target being built, "make check-acceptance" will

[Qemu-devel] [PATCH 15/18] Boot Linux Console Test: add a test for aarch64 + virt

Just like the previous tests, boots a Linux kernel on a aarch64 target using the virt machine. One special option added is the CPU type, given that the kernel selected fails to boot on the virt machine's default CPU (cortex-a15). Signed-off-by: Cleber Rosa --- .travis.yml

[Qemu-devel] [PATCH 00/18] Acceptance Tests: target architecture support

The current acceptance tests don't provide any type of architecture information that can be used to influence the selection of the QEMU binary used on them[1]. If one is running tests on a x86_64 host, the default QEMU binary will be "x86_64-softmmu/qemu-system-x86_64". Given the nature of QEMU,

[Qemu-devel] [PATCH 14/18] Boot Linux Console Test: add a test for ppc64 + pseries

Just like the previous tests, boots a Linux kernel on a ppc64 target using the pseries machine. Signed-off-by: Cleber Rosa --- .travis.yml| 2 +- scripts/qemu.py| 1 - tests/acceptance/boot_linux_console.py | 19 +++ 3 files

[Qemu-devel] [PATCH 07/18] Acceptance tests: look for target architecture in test tags first

A test can, optionally, be tagged for one or many architectures. If a test has been tagged for a single architecture, there's a high chance that the test won't run on other architectures. This changes the default order of choosing a default target architecture to use based on the 'arch' tag

[Qemu-devel] [PATCH 05/18] Acceptance tests: introduce arch parameter and attribute

It's useful to define the architecture that should be used in situations such as: * the intended target of the QEMU binary to be used on tests * the architecture of code to be run within the QEMU binary, such as a kernel image or a full blown guest OS image This commit introduces both a test

[Qemu-devel] [PATCH 04/18] Acceptance tests: fix doc reference to avocado_qemu directory

The "this directory" reference is misleading and confusing, it's a leftover from when this text was proposed in a README file inside the "tests/acceptance/avocado_qemu" directory. When that text was moved to the top level docs directory, the reference was not updated. Signed-off-by: Cleber Rosa

[Qemu-devel] [PATCH 10/18] Boot Linux Console Test: refactor the console watcher into utility method

This introduces a utility method that monitors the console device and looks for either a message that signals the test success or failure. Signed-off-by: Cleber Rosa --- tests/acceptance/boot_linux_console.py | 30 ++ 1 file changed, 21 insertions(+), 9 deletions(-)

[Qemu-devel] [PATCH 11/18] scripts/qemu.py: support adding a console with the default serial device

The set_console() utility function traditionally adds a device either based on the explicitly given device type, or based on the machine type, a known good type of device. But, for a number of machine types, it may be impossible or inconvenient to add the devices my means of "-device" command

[Qemu-devel] [PATCH 12/18] Boot Linux Console Test: add a test for mips + malta

From: Philippe Mathieu-Daudé Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta board and verify the serial is working. Also, it relies on the serial device set by the machine itself. If mips is a target being built, "make check-acceptance" will automatically include this test

[Qemu-devel] [PATCH 09/18] Boot Linux Console Test: update the x86_64 kernel

To the stock Fedora 29 kernel, from the Fedora 28. New tests will be added using the 29 kernel, so for consistency, let's also update it here. Signed-off-by: Cleber Rosa --- tests/acceptance/boot_linux_console.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Qemu-devel] [PATCH 02/18] Acceptance tests: show avocado test execution by default

The current version of the "check-acceptance" target will only show one line for execution of all tests. That's probably OK if the tests to be run are quick enough and they're always the same. But, there's already one test alone that takes on average ~5 seconds to run, we intend to adapt the

  1   2   3   4   5   >