Re: [Qemu-devel] [PATCH] migration: consolidate VMStateField.start

On 02/10/2017 12:24 PM, Dr. David Alan Gilbert wrote: * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: The member VMStateField.start is used for two things, partial data migration for VBUFFER data (basically provide migration for a sub-buffer) and for locating next in QTAILQ. The implementation

Re: [Qemu-devel] [PATCH] 9pfs: proxy: assert if unmarshal fails

Hi Greg, On 02/06/2017 02:20 PM, Greg Kurz wrote: Replies from the virtfs proxy are made up of a fixed-size header (8 bytes) and a payload of variable size (maximum 64kb). When receiving a reply, the proxy backend first reads the whole header and then unmarshals it. If the header is okay, it

Re: [Qemu-devel] [PATCH 3/3] slirp: tcp_listen(): Don't try to close() an fd we never opened

On 02/04/2017 08:08 PM, Peter Maydell wrote: Coverity points out (CID 1005725) that an error-exit path in tcp_listen() will try to close(s) even if the reason it got there was that the qemu_socket() failed and s was never opened. Not only that, this isn't even the right function to use, because

Re: [Qemu-devel] [PATCH 2/3] slirp: Convert mbufs to use g_malloc() and g_free()

On 02/04/2017 08:08 PM, Peter Maydell wrote: The mbuf code currently doesn't check the result of doing a malloc() or realloc() of its data (spotted by Coverity, CID 1238946). Since the m_inc() API assumes that extending an mbuf must succeed, just convert to g_malloc() and g_free().

Re: [Qemu-devel] [PATCH 1/3] slirp: Check qemu_socket() return value in udp_listen()

On 02/04/2017 08:08 PM, Peter Maydell wrote: Check the return value from qemu_socket() rather than trying to pass it to bind() as an fd argument even if it's negative. This wouldn't have caused any negative consequences, because it won't be a valid fd number and the bind call will fail; but

Re: [Qemu-devel] [PATCH 2/2] qemu-img: Avoid setting ret to unused value in img_convert()

On 02/10/2017 01:28 PM, Peter Maydell wrote: Coverity points out that we assign the return value from bdrv_snapshot_load_tmp() to 'ret' in img_convert(), but then never use that variable. (We check for failure by looking at local_err instead.) Drop the unused assignment, bringing the call into

Re: [Qemu-devel] [PATCH 1/2] qemu-img: Use qemu_strtoul() rather than raw strtoul()

On 02/10/2017 01:28 PM, Peter Maydell wrote: Some of the argument parsing in qemu-img uses strtoul() to parse integer arguments. This is tricky to get correct and in fact the code does not get it right, because it assigns the result of strtoul() to an 'int' variable and then tries to check for

[Qemu-devel] [PATCH v2] register: fix incorrect read mask

The register_read() function expects a bitmask argument. To avoid duplicated code, a new inlined function register_enabled_mask() is introduced. Signed-off-by: Philippe Mathieu-Daudé --- v2: squashed together both previous commits as suggested by Francis Alistair.

Re: [Qemu-devel] [PATCH 2/2] register: fix incorrect read mask

On 02/10/2017 07:19 PM, Alistair Francis wrote: On Mon, Feb 6, 2017 at 3:39 PM, Philippe Mathieu-Daudé wrote: The register_read() function expects a bitmask argument. Signed-off-by: Philippe Mathieu-Daudé The functionality of these two patches looks good

[Qemu-devel] [PATCH] migration: madvise error_report fixup!

Signed-off-by: Pavel Butsykin --- migration/qemu-file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/migration/qemu-file.c b/migration/qemu-file.c index 82dbef3c86..195fa94fcf 100644 --- a/migration/qemu-file.c +++ b/migration/qemu-file.c @@

Re: [Qemu-devel] [PATCH v3] hw/core/register: Mark the device with cannot_instantiate_with_device_add_yet

On Wed, Feb 8, 2017 at 11:27 PM, Markus Armbruster wrote: > Thomas Huth writes: > >> The "qemu,register" device needs to be wired up in source code, there >> is no way the user can make any real use of this device with the >> "-device" parameter or the

Re: [Qemu-devel] [PATCH v3] hw/core/or-irq: Mark the device with cannot_instantiate_with_device_add_yet

On Wed, Feb 8, 2017 at 11:27 PM, Markus Armbruster wrote: > Thomas Huth writes: > >> The "or-irq" device needs to be wired up in source code, there is no >> way the user can make any real use of this device with the "-device" >> parameter or the "device_add"

Re: [Qemu-devel] [PATCH 12/24] block/dirty-bitmap: add bdrv_dirty_bitmap_next()

On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote: > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Max Reitz > --- > block/dirty-bitmap.c | 7 +++ > include/block/dirty-bitmap.h | 3 +++ > 2 files changed, 10

Re: [Qemu-devel] [PATCH 11/24] block: introduce persistent dirty bitmaps

On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote: > New field BdrvDirtyBitmap.persistent means, that bitmap should be saved > on bdrv_close, using format driver. Format driver should maintain bitmap > storing. > > Signed-off-by: Vladimir Sementsov-Ogievskiy

Re: [Qemu-devel] [PATCH v2 2/3] sd: sdhci: conditionally invoke multi block transfer

On Tue, Feb 7, 2017 at 10:42 PM, P J P wrote: > From: Prasad J Pandit > > In sdhci_write invoke multi block transfer if it is enabled > in the transfer mode register 's->trnmod'. > > Signed-off-by: Prasad J Pandit > --- >

Re: [Qemu-devel] [PATCH 10/24] block/dirty-bitmap: add autoload field to BdrvDirtyBitmap

On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote: > Mirror AUTO flag from Qcow2 bitmap in BdrvDirtyBitmap. This will be > needed in future, to save this flag back to Qcow2 for persistent > bitmaps. > > Signed-off-by: Vladimir Sementsov-Ogievskiy >

Re: [Qemu-devel] [PATCH 09/24] qcow2: add .bdrv_load_autoloading_dirty_bitmaps

On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote: > Auto loading bitmaps are bitmaps in Qcow2, with the AUTO flag set. They > are loaded when the image is opened and become BdrvDirtyBitmaps for the > corresponding drive. > > Extra data in bitmaps is not supported for now. > >

Re: [Qemu-devel] [PATCH v2 1/3] sd: sdhci: check transfer mode register in multi block transfer

On Tue, Feb 7, 2017 at 10:42 PM, P J P wrote: > From: Prasad J Pandit > > In SDHCI device emulation the transfer mode register value > is used during multi block transfer to check if block count > register is enabled and should be updated. Transfer

Re: [Qemu-devel] [PATCH 2/2] register: fix incorrect read mask

On Mon, Feb 6, 2017 at 3:39 PM, Philippe Mathieu-Daudé wrote: > The register_read() function expects a bitmask argument. > > Signed-off-by: Philippe Mathieu-Daudé The functionality of these two patches looks good to me. I think it's weird that we convert the

[Qemu-devel] [PULL 2/3] hw/vfio/pci-quirks: Set category of the "vfio-pci-igd-lpc-bridge" device

From: Thomas Huth The device has "bridge" in its name, so it should obviously be in the category DEVICE_CATEGORY_BRIDGE. Signed-off-by: Thomas Huth Signed-off-by: Alex Williamson --- hw/vfio/pci-quirks.c |1 + 1 file

[Qemu-devel] [PULL 3/3] hw/vfio: Add CONFIG switches for calxeda-xgmac and amd-xgbe

From: Thomas Huth Both devices seem to be specific to the ARM platform. It's confusing for the users if they show up on other target architectures, too (e.g. when the user runs QEMU with "-device ?" to get a list of supported devices). Thus let's introduce proper configuration

[Qemu-devel] [PULL 1/3] vfio-pci: Fix GTT wrap-around for Skylake+ IGD

Previous IGD, up through Broadwell, only seem to write GTT values into the first 1MB of space allocated for the BDSM, but clearly the GTT can be multiple MB in size. Our test in vfio_igd_quirk_data_write() correctly filters out indexes beyond 1MB, but given the 1MB mask we're using, we re-apply

[Qemu-devel] [PULL 0/3] VFIO updates 2017-02-10

The following changes since commit 98b2faeaee96ab084d0b1669918688d8895c155f: Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2017-02-10 18:07:02 +) are available in the git repository at: git://github.com/awilliam/qemu-vfio.git

[Qemu-devel] [PATCH v2] target-arm: Implement BCM2835 hardware RNG

Recent vanilla Raspberry Pi kernels started to make use of the hardware random number generator in BCM2835 SoC. As a result, those kernels wouldn't work anymore under QEMU but rather just freeze during the boot process. This patch implements a trivial BCM2835 compatible RNG, and adds it as a

[Qemu-devel] [PATCH] target-arm: Implement BCM2835 hardware RNG

Recent vanilla Raspberry Pi kernels started to make use of the hardware random number generator in BCM2835 SoC. As a result, those kernels wouldn't work anymore under QEMU but rather just freeze during the boot process. This patch implements a trivial BCM2835 compatible RNG, and adds it as a

Re: [Qemu-devel] [PATCH 07/24] qcow2: add bitmaps extension

On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote: > Add bitmap extension as specified in docs/specs/qcow2.txt. > For now, just mirror extension header into Qcow2 state and check > constraints. > > For now, disable image resize if it has bitmaps. It will be fixed later. > >

Re: [Qemu-devel] [PATCH V3 0/4] Add vPMU vPMU support under TCG mode

On 02/10/2017 09:11 AM, Peter Maydell wrote: > On 10 February 2017 at 15:00, Peter Maydell wrote: >> On 7 February 2017 at 21:49, Wei Huang wrote: >>> QEMU has implemented cycle count support for guest VM under TCG mode. >>> But this feature is not

Re: [Qemu-devel] [PULL 0/1] Ide patches

On 10 February 2017 at 18:46, John Snow wrote: > > > On 02/10/2017 12:49 PM, Peter Maydell wrote: >> On 10 February 2017 at 16:48, John Snow wrote: >>> The following changes since commit 61eedf7aec0e2395aabd628cc055096909a3ea15: >>> >>> tests/prom-env: Ease

Re: [Qemu-devel] [PULL 0/1] Ide patches

On 02/10/2017 12:49 PM, Peter Maydell wrote: > On 10 February 2017 at 16:48, John Snow wrote: >> The following changes since commit 61eedf7aec0e2395aabd628cc055096909a3ea15: >> >> tests/prom-env: Ease time-out problems on slow hosts (2017-02-10 15:44:53 >> +) >> >> are

[Qemu-devel] [PATCH v2 2/2] tcg: Set jmp_env for exceptions from atomic execution

The current method of executing atomic code in a guest uses cpu_exec_step_atomic() from the outermost loop. This causes an abort() when single stepping over atomic code since debug exception longjmp will point to the the setlongjmp in cpu_exec(). Properly set jmp_env so that it jumps back here on

[Qemu-devel] [PATCH v2 1/2] tcg: Save cpu flags in atomic execution

The current mechanism discards the flags which were set in atomic execution. Properly save them. CC: Alex Bennée CC: Richard Henderson CC: Paolo Bonzini Signed-off-by: Pranith Kumar --- cpu-exec.c | 5 +

[Qemu-devel] [PATCH v2 0/2] mttcg: Handle exception and flags in atomic execution

The previous version, though ideal, needs more work to enable calling start_exclusive() from cpu_exec() and also does not properly handle exception from atomic context. Exceptions in atomic context will not call exclusive_end() and would go to the outer most loop causing a deadlock. The following

Re: [Qemu-devel] [PATCH v4] nios2: Add Altera JTAG UART emulation

Hello Fred, thanks for the clarification. > >> Changelog is missing ... > > > > I modelled this patch based on other nios2 patches, none of them > contained > > Changelog. So please elaborate. > > Things after "---" disappear when commited in the git. > > Thanks, > Fred >

Re: [Qemu-devel] [PATCH v4] nios2: Add Altera JTAG UART emulation

Hello Konrad, I agree with all your comments. [...] > > +static void altera_juart_init(Object *obj) > > +{ > > +SysBusDevice *sbd = SYS_BUS_DEVICE(obj); > > +AlteraJUARTState *s = ALTERA_JUART(obj); > > + > > +memory_region_init_io(>mmio, OBJECT(s), _ops, s, > > +

Re: [Qemu-devel] [PATCH] target-arm: Implement BCM2835 hardware RNG

On 10 February 2017 at 18:06, Marcin Chojnacki wrote: > Recent vanilla Raspberry Pi kernels started to make use of > the hardware random number generator in BCM2835 SoC. As a > result, those kernels wouldn't work anymore under QEMU > but rather just freeze during the boot

Re: [Qemu-devel] [PATCH v5 00/10] Add support for VM Generation ID

Am 10.02.2017 um 19:18 schrieb Andrew Jones: > On Fri, Feb 10, 2017 at 05:16:59PM +0100, Igor Mammedov wrote: >> On Fri, 10 Feb 2017 17:31:33 +0200 >> "Michael S. Tsirkin" wrote: >> >>> On Fri, Feb 10, 2017 at 11:12:13AM +0100, Laszlo Ersek wrote: On 02/05/17 10:11,

Re: [Qemu-devel] [PATCH v5 00/10] Add support for VM Generation ID

On Fri, Feb 10, 2017 at 05:16:59PM +0100, Igor Mammedov wrote: > On Fri, 10 Feb 2017 17:31:33 +0200 > "Michael S. Tsirkin" wrote: > > > On Fri, Feb 10, 2017 at 11:12:13AM +0100, Laszlo Ersek wrote: > > > On 02/05/17 10:11, b...@skyportsystems.com wrote: > > > > From: Ben

[Qemu-devel] [PULL 02/12] target-arm: Add support for AArch64 PMU register PMXEVTYPER_EL0

From: Wei Huang In order to support Linux perf, which uses PMXEVTYPER register, this patch adds read/write access support for PMXEVTYPER. The access is CONSTRAINED UNPREDICTABLE when PMSELR is not 0x1f. Additionally this patch adds support for PMXEVTYPER_EL0. Signed-off-by: Wei

[Qemu-devel] [PATCH] tests/prom-env: Enable the test for the sun4u machine, too

The 32-bit TCG bug has been fixed a while ago, so we can enable this test for sparc64 now, too. Unfortunately, OpenBIOS does not work with the sun4v machine anymore (it needs to catch up with the improved emulation), so we can only enable this test for the sun4u machine right now. Signed-off-by:

[Qemu-devel] [PULL 08/12] hw/arm/virt: Declare fwcfg as dma cache coherent in dt

From: Alexander Graf Fw-cfg recently learned how to directly access guest memory and does so in cache coherent fashion. Tell the guest about that fact when it's using DT. Signed-off-by: Alexander Graf Reviewed-by: Laszlo Ersek Reviewed-by: Ard

[Qemu-devel] [PULL 11/12] aspeed/smc: handle dummies only in fast read mode

From: Cédric Le Goater HW works fine in normal read mode with dummy bytes being set. So let's check this case to not transfer bytes. Signed-off-by: Cédric Le Goater Message-id: 1486648058-520-4-git-send-email-...@kaod.org Signed-off-by: Peter Maydell

[Qemu-devel] [PULL 12/12] aspeed/smc: use a modulo to check segment limits

From: Cédric Le Goater The size of a segment is not necessarily a power of 2. Signed-off-by: Cédric Le Goater Reviewed-by: Philippe Mathieu-Daudé Message-id: 1486648058-520-5-git-send-email-...@kaod.org Signed-off-by: Peter Maydell

[Qemu-devel] [PULL 06/12] hw/arm/virt: Declare virtio-mmio as dma cache coherent in ACPI

From: Alexander Graf Virtio-mmio devices can directly access guest memory and do so in cache coherent fashion. Tell the guest about that fact when it's using ACPI. Signed-off-by: Alexander Graf Reviewed-by: Laszlo Ersek Reviewed-by: Ard

[Qemu-devel] [PULL 09/12] aspeed: check for negative values returned by blk_getlength()

From: Cédric Le Goater write_boot_rom() does not check for negative values. This is more a problem for coverity than the actual code as the size of the flash device is checked when the m25p80 object is created. If there is anything wrong with the backing file, we should not even

[Qemu-devel] [PULL 01/12] target-arm: Add support for PMU register PMSELR_EL0

From: Wei Huang This patch adds support for AArch64 register PMSELR_EL0. The existing PMSELR definition is revised accordingly. Signed-off-by: Wei Huang Reviewed-by: Peter Maydell [PMM: Moved #ifndef CONFIG_USER_ONLY to cover new

[Qemu-devel] [PULL 10/12] aspeed: remove useless comment on controller segment size

From: Cédric Le Goater The flash devices used for the FMC controller (BMC firmware) are well defined for each Aspeed machine and are all smaller than the default mapping window size, at least for CE0 which is the chip the SoC boots from. Signed-off-by: Cédric Le Goater

[Qemu-devel] [PULL 03/12] target-arm: Add support for PMU register PMINTENSET_EL1

From: Wei Huang This patch adds access support for PMINTENSET_EL1. Signed-off-by: Wei Huang Reviewed-by: Peter Maydell Message-id: 1486504171-26807-4-git-send-email-...@redhat.com Signed-off-by: Peter Maydell

[Qemu-devel] [PULL 00/12] target-arm queue

repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20170210 for you to fetch changes up to b4cc583f0285a2e1e78621dfba142f00ca47414a: aspeed/smc: use a modulo to check segment limits (2017-02-10 17:40:30 +

[Qemu-devel] [PULL 07/12] hw/arm/virt: Declare fwcfg as dma cache coherent in ACPI

From: Alexander Graf Fw-cfg recently learned how to directly access guest memory and does so in cache coherent fashion. Tell the guest about that fact when it's using ACPI. Signed-off-by: Alexander Graf Reviewed-by: Laszlo Ersek Reviewed-by:

[Qemu-devel] [PULL 05/12] target-arm: Declare virtio-mmio as dma-coherent in dt

From: Alexander Graf QEMU emulated hardware is always dma coherent with its guest. We do annotate that correctly on the PCI host controller, but left out virtio-mmio. Recent kernels have started to interpret that flag rather than take dma coherency as granted with virtio-mmio.

[Qemu-devel] [PULL 04/12] target-arm: Enable vPMU support under TCG mode

From: Wei Huang This patch contains several fixes to enable vPMU under TCG mode. It first removes the checking of kvm_enabled() while unsetting ARM_FEATURE_PMU. With it, the .pmu option can be used to turn on/off vPMU under TCG mode. Secondly the PMU node of DT table is now

Re: [Qemu-devel] [PATCH v7 2/2] mach-virt: Provide sample configuration files

On Fri, Feb 10, 2017 at 06:25:06PM +0100, Andrea Bolognani wrote: > These are very much like the sample configuration files > for q35, and can be used both as documentation and as > a starting point for creating your own guest. > > Two sample configuration files are provided: > > *

Re: [Qemu-devel] Sparc sun4v machine currently broken?

On 10.02.2017 18:43, Artyom Tarasenko wrote: > On Fri, Feb 10, 2017 at 6:29 PM, Thomas Huth wrote: >> On 10.02.2017 14:49, Thomas Huth wrote: >>> Hi, >>> >>> is it just me, or could it be that the sun4v machine is currently broken? >>> I get the following error when I try to

Re: [Qemu-devel] [PULL 0/1] Ide patches

On 10 February 2017 at 16:48, John Snow wrote: > The following changes since commit 61eedf7aec0e2395aabd628cc055096909a3ea15: > > tests/prom-env: Ease time-out problems on slow hosts (2017-02-10 15:44:53 > +) > > are available in the git repository at: > >

Re: [Qemu-devel] Sparc sun4v machine currently broken?

On Fri, Feb 10, 2017 at 6:29 PM, Thomas Huth wrote: > On 10.02.2017 14:49, Thomas Huth wrote: >> Hi, >> >> is it just me, or could it be that the sun4v machine is currently broken? >> I get the following error when I try to run QEMU with this machine: >> >> qemu-system-sparc64

[Qemu-devel] [PATCH v4 18/18] block: pass option prefix down to crypto layer

While the crypto layer uses a fixed option name "key-secret", the upper block layer may have a prefix on the options. e.g. "luks-key-secret", "aes-key-secret", in order to avoid clashes between crypto option names & other block option names. To ensure the crypto layer can report accurate error

[Qemu-devel] [PATCH v4 17/18] block: remove all encryption handling APIs

Now that all encryption keys must be provided upfront via the QCryptoSecret API and associated block driver properties there is no need for any explicit encryption handling APIs in the block layer. Encryption can be handled transparently within the block driver. We only retain an API for querying

[Qemu-devel] [PATCH v4 16/18] block: rip out all traces of password prompting

Now that qcow & qcow2 are wired up to get encryption keys via the QCryptoSecret object, nothing is relying on the interactive prompting for passwords. All the code related to password prompting can thus be ripped out. Reviewed-by: Max Reitz Signed-off-by: Daniel P. Berrange

Re: [Qemu-devel] [PATCH 0/5] risu: add m68k target support

On 10 February 2017 at 17:32, Peter Maydell wrote: > On 10 February 2017 at 15:33, Laurent Vivier wrote: >> Le 10/02/2017 à 16:25, Peter Maydell a écrit : >>> Thanks for this; I think patches 1-3 are good, and have >>> applied them to risu master. For

[Qemu-devel] [PATCH v4 12/18] qcow2: extend specification to cover LUKS encryption

Update the qcow2 specification to describe how the LUKS header is placed inside a qcow2 file, when using LUKS encryption for the qcow2 payload instead of the legacy AES-CBC encryption Reviewed-by: Max Reitz Signed-off-by: Daniel P. Berrange ---

Re: [Qemu-devel] [PATCH 0/5] risu: add m68k target support

On 10 February 2017 at 15:33, Laurent Vivier wrote: > Le 10/02/2017 à 16:25, Peter Maydell a écrit : >> Thanks for this; I think patches 1-3 are good, and have >> applied them to risu master. For 4 I wonder if we can >> find a better way of handling variable-length instruction

[Qemu-devel] [PATCH v4 09/18] qcow: convert QCow to use QCryptoBlock for encryption

This converts the qcow2 driver to make use of the QCryptoBlock APIs for encrypting image content. This is only wired up to permit use of the legacy QCow encryption format. Users who wish to have the strong LUKS format should switch to qcow2 instead. With this change it is now required to use the

[Qemu-devel] [PATCH v7 2/2] mach-virt: Provide sample configuration files

These are very much like the sample configuration files for q35, and can be used both as documentation and as a starting point for creating your own guest. Two sample configuration files are provided: * mach-virt-graphical.cfg can be used to start a fully-featured (USB, graphical console,

[Qemu-devel] [PATCH v4 10/18] qcow2: make qcow2_encrypt_sectors encrypt in place

Instead of requiring separate input/output buffers for encrypting data, change qcow2_encrypt_sectors() to assume use of a single buffer, encrypting in place. The current callers all used the same buffer for input/output already. Reviewed-by: Eric Blake Reviewed-by: Fam Zheng

Re: [Qemu-devel] Sparc sun4v machine currently broken?

On 10.02.2017 14:49, Thomas Huth wrote: > Hi, > > is it just me, or could it be that the sun4v machine is currently broken? > I get the following error when I try to run QEMU with this machine: > > qemu-system-sparc64 -nographic -M sun4v > qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL

[Qemu-devel] [PATCH v7 1/2] q35: Improve sample configuration files

Instead of having a single sample configuration file, we now have several: * q35-emulated.cfg documents the default devices QEMU adds to a q35 guest and the additional devices that are pretty much guaranteed to be present in a physical q35-based machine; *

[Qemu-devel] [PATCH v7 0/2] docs: Improve sample configuration files

Changes since [v6] * Address review comments: - re-introduce optical media support; - rename PCIe Root Ports from pci.* to pcie.*; - remove reference to GTK+. Changes since [v5] * Address review comments: - use the native serial console rather than the VirtIO based

[Qemu-devel] [PATCH v4 13/18] qcow2: add support for LUKS encryption format

This adds support for using LUKS as an encryption format with the qcow2 file. The use of the existing 'encryption=on' parameter is replaced by a new parameter 'encryption-format' which takes the values 'aes' or 'luks'. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2

[Qemu-devel] [PATCH v4 08/18] qcow: make encrypt_sectors encrypt in place

Instead of requiring separate input/output buffers for encrypting data, change encrypt_sectors() to assume use of a single buffer, encrypting in place. One current caller uses the same buffer for input/output already and the other two callers are easily converted to do so. Reviewed-by: Eric Blake

[Qemu-devel] [PATCH v4 04/18] qcow: require image size to be > 1 for new images

The qcow driver refuses to open images which are less than 2 bytes in size, but will happily create such images. Add a check in the create path to avoid this discrepancy. Reviewed-by: Max Reitz Reviewed-by: Alberto Garcia Reviewed-by: Eric Blake

[Qemu-devel] [PATCH v4 15/18] iotests: enable tests 134 and 158 to work with qcow (v1)

The 138 and 158 iotests exercise the legacy qcow2 aes encryption code path and they work fine with qcow v1 too. Reviewed-by: Max Reitz Signed-off-by: Daniel P. Berrange --- tests/qemu-iotests/134 | 2 +- tests/qemu-iotests/158 | 2 +- 2 files changed, 2

[Qemu-devel] [PATCH v4 06/18] iotests: skip 048 with qcow which doesn't support resize

Test 048 is designed to verify data preservation during an image resize. The qcow (v1) format impl has never supported resize so always fails. Reviewed-by: Max Reitz Reviewed-by: Alberto Garcia Signed-off-by: Daniel P. Berrange ---

[Qemu-devel] [PATCH v4 02/18] block: add ability to set a prefix for opt names

When integrating the crypto support with qcow/qcow2, we don't want to use the bare LUKS option names "hash-alg", "key-secret", etc. We want to namespace them "luks-hash-alg", "luks-key-secret" so that they don't clash with any general qcow options at a later date. Reviewed-by: Max Reitz

[Qemu-devel] [PATCH v4 14/18] qcow2: add iotests to cover LUKS encryption support

This extends the 087 iotest to cover LUKS encryption when doing blockdev-add. Two further tests are added to validate read/write of LUKS encrypted images with a single file and with a backing file. Reviewed-by: Max Reitz Signed-off-by: Daniel P. Berrange

[Qemu-devel] [PATCH v4 00/18] Convert QCow[2] to QCryptoBlock & add LUKS support

Previously posted: v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00201.html v2: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05147.html v3: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05671.html This series is a continuation of previous work to support

[Qemu-devel] [PATCH v4 05/18] iotests: skip 042 with qcow which dosn't support zero sized images

Test 042 is designed to verify operation with zero sized images. Such images are not supported with qcow (v1), so this test has always failed. Reviewed-by: Max Reitz Reviewed-by: Alberto Garcia Signed-off-by: Daniel P. Berrange ---

[Qemu-devel] [PATCH v4 11/18] qcow2: convert QCow2 to use QCryptoBlock for encryption

This converts the qcow2 driver to make use of the QCryptoBlock APIs for encrypting image content, using the legacyy QCow2 AES scheme. With this change it is now required to use the QCryptoSecret object for providing passwords, instead of the current block password APIs / interactive prompting.

[Qemu-devel] [PATCH v4 07/18] iotests: fix 097 when run with qcow

The previous commit: commit a3e1505daec31ef56f0489f8c8fff1b8e4ca92bd Author: Eric Blake Date: Mon Dec 5 09:49:34 2016 -0600 qcow2: Don't strand clusters near 2G intervals during commit extended the 097 test case so that it did two passes, once with an internal

[Qemu-devel] [PATCH v4 01/18] block: expose crypto option names / defs to other drivers

The block/crypto.c defines a set of QemuOpts that provide parameters for encryption. This will also be needed by the qcow/qcow2 integration, so expose the relevant pieces in a new block/crypto.h header. Reviewed-by: Max Reitz Reviewed-by: Eric Blake

[Qemu-devel] [PATCH v4 03/18] qcow: document another weakness of qcow AES encryption

Document that use of guest virtual sector numbers as the basis for the initialization vectors is a potential weakness, when combined with internal snapshots or multiple images using the same passphrase. This fixes the formatting of the itemized list too. Reviewed-by: Max Reitz

[Qemu-devel] [PULL 0/1] Ide patches

The following changes since commit 61eedf7aec0e2395aabd628cc055096909a3ea15: tests/prom-env: Ease time-out problems on slow hosts (2017-02-10 15:44:53 +) are available in the git repository at: https://github.com/jnsnow/qemu.git tags/ide-pull-request for you to fetch changes up to

[Qemu-devel] [PULL 1/1] ahci: advertise HOST_CAP_64

From: Ladi Prosek The AHCI emulation code supports 64-bit addressing and should advertise this fact in the Host Capabilities register. Both Linux and Windows drivers test this bit to decide if the upper 32 bits of various registers may be written to, and at least some

Re: [Qemu-devel] [PATCH v2] tests/prom-env: Ease time-out problems on slow hosts

On 10 February 2017 at 15:14, Thomas Huth wrote: > Peter Maydell recently ran into time-out problems with the > prom-env test on a rather slow ARM board. To tackle this issue, > we can speed up the test by running QEMU with "-nodefaults" for > the pseries machine, so that SLOF

[Qemu-devel] [PATCH 1/2] qemu-img: Use qemu_strtoul() rather than raw strtoul()

Some of the argument parsing in qemu-img uses strtoul() to parse integer arguments. This is tricky to get correct and in fact the code does not get it right, because it assigns the result of strtoul() to an 'int' variable and then tries to check for > INT_MAX. Coverity correctly complains that

[Qemu-devel] [PATCH 0/2] qemu-img: fix coverity nits

Coverity points out a couple of nits in qemu-img: * misuse of strtoul() * variable set but not used These patches fix the issues. Peter Maydell (2): qemu-img: Use qemu_strtoul() rather than raw strtoul() qemu-img: Avoid setting ret to unused value in img_convert() qemu-img.c | 40

[Qemu-devel] [PATCH 2/2] qemu-img: Avoid setting ret to unused value in img_convert()

Coverity points out that we assign the return value from bdrv_snapshot_load_tmp() to 'ret' in img_convert(), but then never use that variable. (We check for failure by looking at local_err instead.) Drop the unused assignment, bringing the call into line with the following call to

Re: [Qemu-devel] [Qemu-block] [PATCH v3 08/18] qcow: make encrypt_sectors encrypt in place

On Fri, Feb 10, 2017 at 11:44:15AM +0100, Alberto Garcia wrote: > On Thu 26 Jan 2017 11:18:17 AM CET, Daniel P. Berrange wrote: > > Instead of requiring separate input/output buffers for > > encrypting data, change encrypt_sectors() to assume > > use of a single buffer, encrypting in place. One

Re: [Qemu-devel] [PATCH v5 00/10] Add support for VM Generation ID

On Fri, 10 Feb 2017 17:31:33 +0200 "Michael S. Tsirkin" wrote: > On Fri, Feb 10, 2017 at 11:12:13AM +0100, Laszlo Ersek wrote: > > On 02/05/17 10:11, b...@skyportsystems.com wrote: > > > From: Ben Warren [...] > > > > - or else, add another boolean

Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration

> Well, not so much solved as worked around it. > > It seems that the problem only showed up on Broadwell, which made us wonder > about something hardware specific. Yes, the bug seems to be related to PML. I am looking at the code, but I haven't found anything yet. Paolo

Re: [Qemu-devel] [PATCH 0/3] COLO: fix some bugs

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote: > Hi, > > This series fix three bugs of COLO. > patch 1 fix one usage case which users want to change checkpoint-delay > with an extream big value set before, the new value may not take effect > until finishing a long time of sleep. > >

Re: [Qemu-devel] [PULL 0/2] Travis updates

On 10 February 2017 at 15:04, Alex Bennée wrote: > The following changes since commit 7d2c6c95511e42dffe2b263275e09957723d0ff4: > > Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20170206-1' into > staging (2017-02-06 11:44:08 +) > > are available in the

Re: [Qemu-devel] [PATCH v5 00/10] Add support for VM Generation ID

On Fri, Feb 10, 2017 at 11:12:13AM +0100, Laszlo Ersek wrote: > On 02/05/17 10:11, b...@skyportsystems.com wrote: > > From: Ben Warren > > > > This patch set adds support for passing a GUID to Windows guests. It is a > > re-implementation of previous patch sets written

Re: [Qemu-devel] [PATCH v11 23/24] hw/misc/imx6_src: defer clearing of SRC_SCR reset bits

On 10 February 2017 at 15:19, Alex Bennée wrote: > Peter Maydell writes: >> I guess a malloc-and-free is OK since the guest isn't going to be >> bouncing CPUs through reset very often, though it's a bit ugly to >> see in device code. > > Previous

Re: [Qemu-devel] [PATCH 0/5] risu: add m68k target support

Le 10/02/2017 à 16:25, Peter Maydell a écrit : > On 7 February 2017 at 18:33, Laurent Vivier wrote: >> This series add the files needed to test the m68k target. >> >> For the moment, it doesn't support FPU instructions. >> >> Laurent Vivier (5): >> m68k: implement risugen

Re: [Qemu-devel] [PATCH v3] migrate: Introduce zero RAM checks to skip RAM migration

* Ashijeet Acharya (ashijeetacha...@gmail.com) wrote: > Migration of a "none" machine with no RAM crashes abruptly as > bitmap_new() fails and thus aborts. Instead place zero RAM checks at > appropriate places to skip migration of RAM in this case and complete > migration successfully for devices

Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration

Well, not so much solved as worked around it. It seems that the problem only showed up on Broadwell, which made us wonder about something hardware specific. Setting "kvm-intel.eptad=0" in the kernel boot args seems to mask the problem for us. Chris On 02/10/2017 03:11 AM, Herongguang

Re: [Qemu-devel] [PATCH 0/5] risu: add m68k target support

On 7 February 2017 at 18:33, Laurent Vivier wrote: > This series add the files needed to test the m68k target. > > For the moment, it doesn't support FPU instructions. > > Laurent Vivier (5): > m68k: implement risugen module > m68k: implement server and client side >

Re: [Qemu-devel] [PATCH] migration: consolidate VMStateField.start

* Halil Pasic (pa...@linux.vnet.ibm.com) wrote: > The member VMStateField.start is used for two things, partial data > migration for VBUFFER data (basically provide migration for a > sub-buffer) and for locating next in QTAILQ. > > The implementation of the VBUFFER feature is broken when

Re: [Qemu-devel] [PATCH v11 23/24] hw/misc/imx6_src: defer clearing of SRC_SCR reset bits

Peter Maydell writes: > On 9 February 2017 at 17:09, Alex Bennée wrote: >> The arm_reset_cpu/set_cpu_on/set_cpu_off() functions do their work >> asynchronously in the target vCPUs context. As a result we need to >> ensure the SRC_SCR reset bits

Re: [Qemu-devel] [PATCH 0/4] aspeed: miscellaneous small fixes

On 9 February 2017 at 13:47, Cédric Le Goater wrote: > Hello, > > Here is a short series fixing small issues in the SMC controller model > of the Aspeed SoC. > > Thanks, > > C. > > Cédric Le Goater (4): > aspeed: check for negative values returned by blk_getlength() > aspeed:

  1   2   >