date:20160530

[Qemu-devel] [PULL 00/30] Misc changes for 2016-05-27

2016-05-30 Thread Paolo Bonzini

The following changes since commit d6550e9ed2e1a60d889dfb721de00d9a4e3bafbe:

  Merge remote-tracking branch 'remotes/riku/tags/pull-linux-user-20160527' 
into staging (2016-05-27 14:05:48 +0100)

are available in the git repository at:

  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 0878d0e11ba8013dd759c6921cbf05ba6a41bd71:

  exec: hide mr->ram_addr from qemu_get_ram_ptr users (2016-05-29 09:11:12 
+0200)

Dropped the jinxed DMA change once more, and seriously thinking of
rewriting the whole thing in assembly language...


* docs/atomics fixes and atomic_rcu_* optimization (Emilio)
* NBD bugfix (Eric)
* Memory fixes and cleanups (Paolo, Paul)
* scsi-block support for SCSI status, including persistent
  reservations (Paolo)
* kvm_stat moves to the Linux repository
* SCSI bug fixes (Peter, Prasad)
* Killing qemu_char_get_next_serial, non-ARM parts (Xiaoqiang)


Emilio G. Cota (3):
  docs/atomics: update atomic_read/set comparison with Linux
  atomics: emit an smp_read_barrier_depends() barrier only for Alpha and 
Thread Sanitizer
  atomics: do not emit consume barrier for atomic_rcu_read

Eric Blake (1):
  nbd: Don't trim unrequested bytes

Fam Zheng (1):
  scsi-generic: Merge block max xfer len in INQUIRY response

Paolo Bonzini (13):
  Revert "memory: Drop FlatRange.romd_mode"
  kvm_stat: Remove
  bt: rewrite csrhci_write to avoid out-of-bounds writes
  docs/atomics: update comparison with Linux
  scsi-disk: introduce a common base class
  scsi-disk: introduce dma_readv and dma_writev
  scsi-disk: add need_fua_emulation to SCSIDiskClass
  scsi-disk: introduce scsi_disk_req_check_error
  scsi-block: always use SG_IO
  memory: remove qemu_get_ram_fd, qemu_set_ram_fd, qemu_ram_block_host_ptr
  exec: remove ram_addr argument from qemu_ram_block_from_host
  memory: split memory_region_from_host from qemu_ram_addr_from_host
  exec: hide mr->ram_addr from qemu_get_ram_ptr users

Paul Durrant (1):
  xen-hvm: ignore background I/O sections

Peter Lieven (1):
  block/iscsi: avoid potential overflow of acb->task->cdb

Prasad J Pandit (5):
  scsi: pvscsi: check command descriptor ring buffer size (CVE-2016-4952)
  scsi: mptsas: infinite loop while fetching requests
  scsi: megasas: use appropriate property buffer size
  scsi: megasas: initialise local configuration data buffer
  scsi: megasas: check 'read_queue_head' index value

xiaoqiang zhao (5):
  hw/char: QOM'ify escc.c
  hw/char: QOM'ify etraxfs_ser.c
  hw/char: QOM'ify lm32_juart.c
  hw/char: QOM'ify lm32_uart.c
  hw/char: QOM'ify milkymist-uart.c

 Makefile |   9 -
 block/iscsi.c|   7 +
 cputlb.c |   3 +-
 docs/atomics.txt |  38 +-
 exec.c   | 110 ++
 hw/bt/hci-csr.c  |  67 ++--
 hw/char/escc.c   |  30 +-
 hw/char/etraxfs_ser.c|  27 +-
 hw/char/lm32_juart.c |  17 +-
 hw/char/lm32_uart.c  |  28 +-
 hw/char/milkymist-uart.c |  10 +-
 hw/cris/axis_dev88.c |   4 +-
 hw/lm32/lm32.h   |  19 +-
 hw/lm32/lm32_boards.c|   9 +-
 hw/lm32/milkymist-hw.h   |   4 +-
 hw/lm32/milkymist.c  |   4 +-
 hw/misc/ivshmem.c|   5 +-
 hw/scsi/megasas.c|   6 +-
 hw/scsi/mptsas.c |   9 +-
 hw/scsi/scsi-disk.c  | 415 --
 hw/scsi/scsi-generic.c   |  12 +
 hw/scsi/vmw_pvscsi.c |  24 +-
 hw/virtio/vhost-user.c   |  25 +-
 include/exec/cpu-common.h|   4 +-
 include/exec/memory.h|  36 +-
 include/exec/ram_addr.h  |   3 -
 include/hw/cris/etraxfs.h|  16 +
 include/qemu/atomic.h|  25 +-
 memory.c |  43 ++-
 migration/postcopy-ram.c |   3 +-
 nbd/server.c |  20 +-
 scripts/dump-guest-memory.py |  19 +-
 scripts/kvm/kvm_stat | 825 ---
 scripts/kvm/kvm_stat.texi|  55 ---
 target-i386/kvm.c|   6 +-
 xen-hvm.c|  14 +-
 36 files changed, 709 insertions(+), 1242 deletions(-)
 delete mode 100755 scripts/kvm/kvm_stat
 delete mode 100644 scripts/kvm/kvm_stat.texi
-- 
2.5.5

Re: [Qemu-devel] [PATCH v6 01/17] pci: fix unaligned access in pci_xxx_quad()

2016-05-30 Thread Michael S. Tsirkin

On Mon, May 30, 2016 at 06:05:57PM +0300, Dmitry Fleytman wrote:
> 
> > On 30 May 2016, at 17:47 PM, Michael S. Tsirkin  wrote:
> > 
> > On Mon, May 30, 2016 at 12:14:26PM +0300, Leonid Bloch wrote:
> >> From: Dmitry Fleytman 
> >> 
> >> Replace legacy cpu_to_le64w()/le64_to_cpup()
> >> calls with stq_le_p()/ldq_le_p().
> >> 
> >> Signed-off-by: Dmitry Fleytman 
> >> Signed-off-by: Leonid Bloch 
> > 
> 
> Hi Michael,
> 
> > Could you please add a code comment to clarify what's going on a bit more?
> > Something to the point that capabilities are guaranteed to
> > be dword-aligned only.
> > 
> 
> Just to clarify, do you want to add these comments to 
> pci_set/get_quad functions or to the new DSN-generation function?

pci_set/get_quad

> > Also, this isn't a dependency of this patchset I think -
> > as far as I could say the only user of this is
> > pcie: Introduce function for DSN capability creation
> > but that merely accesses a capability, and all callers pass in
> > an aligned offset.
> 
> Right, this issue appeared after introduction of DSN generation function.

Does DSN generation function pass unaligned offsets?
It does not look like it does...

> All other callers pass aligned offsets so far.
> 
> Thanks,
> Dmitry
> 
> > 
> >> ---
> >> include/hw/pci/pci.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> >> index ef6ba51..ee238ad 100644
> >> --- a/include/hw/pci/pci.h
> >> +++ b/include/hw/pci/pci.h
> >> @@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
> >> static inline void
> >> pci_set_quad(uint8_t *config, uint64_t val)
> >> {
> >> -cpu_to_le64w((uint64_t *)config, val);
> >> +stq_le_p(config, val);
> >> }
> >> 
> >> static inline uint64_t
> >> pci_get_quad(const uint8_t *config)
> >> {
> >> -return le64_to_cpup((const uint64_t *)config);
> >> +return ldq_le_p(config);
> >> }
> >> 
> >> static inline void
> >> -- 
> >> 2.5.5

Re: [Qemu-devel] [PATCH v6 16/17] net: Introduce e1000e device emulation

2016-05-30 Thread Michael S. Tsirkin

On Mon, May 30, 2016 at 12:14:41PM +0300, Leonid Bloch wrote:
> diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
> new file mode 100644
> index 000..4da6bb1
> --- /dev/null
> +++ b/hw/net/e1000e.c

Here are minor style issues that can be fixed after this is upstream.
See below.

> @@ -0,0 +1,739 @@
> +/*
> +* QEMU INTEL 82574 GbE NIC emulation
> +*
> +* Software developer's manuals:
> +* 
> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf
> +*
> +* Copyright (c) 2015 Ravello Systems LTD (http://ravellosystems.com)
> +* Developed by Daynix Computing LTD (http://www.daynix.com)
> +*
> +* Authors:
> +* Dmitry Fleytman 
> +* Leonid Bloch 
> +* Yan Vugenfirer 
> +*
> +* Based on work done by:
> +* Nir Peleg, Tutis Systems Ltd. for Qumranet Inc.
> +* Copyright (c) 2008 Qumranet
> +* Based on work done by:
> +* Copyright (c) 2007 Dan Aloni
> +* Copyright (c) 2004 Antony T Curtis
> +*
> +* This library is free software; you can redistribute it and/or
> +* modify it under the terms of the GNU Lesser General Public
> +* License as published by the Free Software Foundation; either
> +* version 2 of the License, or (at your option) any later version.
> +*
> +* This library is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +* Lesser General Public License for more details.
> +*
> +* You should have received a copy of the GNU Lesser General Public
> +* License along with this library; if not, see 
> .
> +*/
> +
> +#include "qemu/osdep.h"
> +#include "net/net.h"
> +#include "net/tap.h"
> +#include "qemu/range.h"
> +#include "sysemu/sysemu.h"
> +#include "hw/pci/msi.h"
> +#include "hw/pci/msix.h"
> +
> +#include "hw/net/e1000_regs.h"
> +
> +#include "e1000x_common.h"
> +#include "e1000e_core.h"
> +
> +#include "trace.h"
> +
> +#define TYPE_E1000E "e1000e"
> +#define E1000E(obj) OBJECT_CHECK(E1000EState, (obj), TYPE_E1000E)
> +
> +typedef struct {
> +PCIDevice parent_obj;
> +NICState *nic;
> +NICConf conf;
> +
> +MemoryRegion mmio;
> +MemoryRegion flash;
> +MemoryRegion io;
> +MemoryRegion msix;
> +
> +uint32_t ioaddr;
> +
> +uint16_t subsys_ven;
> +uint16_t subsys;
> +
> +uint16_t subsys_ven_used;
> +uint16_t subsys_used;
> +
> +uint32_t intr_state;
> +bool disable_vnet;
> +
> +E1000ECore core;
> +
> +} E1000EState;

typedef struct E1000EState is preferably because older
gdb versions do not always see typedefs.

> +
> +#define E1000E_MMIO_IDX 0
> +#define E1000E_FLASH_IDX1
> +#define E1000E_IO_IDX   2
> +#define E1000E_MSIX_IDX 3
> +
> +#define E1000E_MMIO_SIZE(128 * 1024)
> +#define E1000E_FLASH_SIZE   (128 * 1024)
> +#define E1000E_IO_SIZE  (32)
> +#define E1000E_MSIX_SIZE(16 * 1024)
> +
> +#define E1000E_MSIX_TABLE   (0x)
> +#define E1000E_MSIX_PBA (0x2000)
> +
> +#define E1000E_USE_MSI BIT(0)
> +#define E1000E_USE_MSIXBIT(1)
> +
> +static uint64_t
> +e1000e_mmio_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +E1000EState *s = opaque;
> +return e1000e_core_read(&s->core, addr, size);
> +}
> +
> +static void
> +e1000e_mmio_write(void *opaque, hwaddr addr,
> +   uint64_t val, unsigned size)
> +{
> +E1000EState *s = opaque;
> +e1000e_core_write(&s->core, addr, val, size);
> +}
> +
> +static bool
> +e1000e_io_get_reg_index(E1000EState *s, uint32_t *idx)
> +{
> +if (s->ioaddr < 0x1) {
> +*idx = s->ioaddr;
> +return true;
> +}
> +
> +if (s->ioaddr < 0x7) {
> +trace_e1000e_wrn_io_addr_undefined(s->ioaddr);
> +return false;
> +}
> +
> +if (s->ioaddr < 0xF) {
> +trace_e1000e_wrn_io_addr_flash(s->ioaddr);
> +return false;
> +}
> +
> +trace_e1000e_wrn_io_addr_unknown(s->ioaddr);
> +return false;
> +}
> +
> +static uint64_t
> +e1000e_io_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +E1000EState *s = opaque;
> +uint32_t idx;
> +uint64_t val;
> +
> +switch (addr) {
> +case E1000_IOADDR:
> +trace_e1000e_io_read_addr(s->ioaddr);
> +return s->ioaddr;
> +case E1000_IODATA:
> +if (e1000e_io_get_reg_index(s, &idx)) {
> +val = e1000e_core_read(&s->core, idx, sizeof(val));
> +trace_e1000e_io_read_data(idx, val);
> +return val;
> +}
> +return 0;
> +default:
> +trace_e1000e_wrn_io_read_unknown(addr);
> +return 0;
> +}
> +}
> +
> +static void
> +e1000e_io_write(void *opaque, hwaddr addr,
> +uint64_t val, unsigned size)
> +{
> +E1000EState *s = opaque;
> +uint32_t idx;
> +
> +switch (addr) {
> +case E1000_IOADDR:
> +trace_e1000e_io_write_addr(val);
> +s->ioaddr = (uint32_t) val;
> +return;
> +case E1000_IODATA:
> +

Re: [Qemu-devel] [PATCH v6 01/17] pci: fix unaligned access in pci_xxx_quad()

2016-05-30 Thread Dmitry Fleytman


> On 30 May 2016, at 17:47 PM, Michael S. Tsirkin  wrote:
> 
> On Mon, May 30, 2016 at 12:14:26PM +0300, Leonid Bloch wrote:
>> From: Dmitry Fleytman 
>> 
>> Replace legacy cpu_to_le64w()/le64_to_cpup()
>> calls with stq_le_p()/ldq_le_p().
>> 
>> Signed-off-by: Dmitry Fleytman 
>> Signed-off-by: Leonid Bloch 
> 

Hi Michael,

> Could you please add a code comment to clarify what's going on a bit more?
> Something to the point that capabilities are guaranteed to
> be dword-aligned only.
> 

Just to clarify, do you want to add these comments to 
pci_set/get_quad functions or to the new DSN-generation function?

> Also, this isn't a dependency of this patchset I think -
> as far as I could say the only user of this is
>   pcie: Introduce function for DSN capability creation
> but that merely accesses a capability, and all callers pass in
> an aligned offset.

Right, this issue appeared after introduction of DSN generation function.
All other callers pass aligned offsets so far.

Thanks,
Dmitry

> 
>> ---
>> include/hw/pci/pci.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
>> index ef6ba51..ee238ad 100644
>> --- a/include/hw/pci/pci.h
>> +++ b/include/hw/pci/pci.h
>> @@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
>> static inline void
>> pci_set_quad(uint8_t *config, uint64_t val)
>> {
>> -cpu_to_le64w((uint64_t *)config, val);
>> +stq_le_p(config, val);
>> }
>> 
>> static inline uint64_t
>> pci_get_quad(const uint8_t *config)
>> {
>> -return le64_to_cpup((const uint64_t *)config);
>> +return ldq_le_p(config);
>> }
>> 
>> static inline void
>> -- 
>> 2.5.5

Re: [Qemu-devel] [PATCH v6 00/17] Introduce Intel 82574 GbE Controller Emulation (e1000e)

2016-05-30 Thread Michael S. Tsirkin

On Mon, May 30, 2016 at 12:14:25PM +0300, Leonid Bloch wrote:
> Hello All,
> 
> This is v6 of e1000e series.
> 
> For convenience, the same patches are available at:
> https://github.com/daynix/qemu-e1000e/tree/e1000e-submit-v6
> 
> Best regards,
> Dmitry.

There are some things that can be improved further
but overall I think it's OK to merge this.

Reviewed-by: Michael S. Tsirkin 



> Changes since v5:
> 
> 1. Fixed build failure on old clang versions
> 2. Added patch that fixes unaligned access in pci_[set|get]_quad()
> 3. Rebased to the latest master
> 
> Changes since v4:
> 
> 1. Rebased to the latest master (2.6.0+)
> 
> Changes since v3:
> 
> 1. Various code fixes as suggested by Jason and Michael
> 2. Rebased to the latest master
> 
> Changes since v2:
> 
> 1. Interrupt storm on latest Linux kernels fixed
> 2. Device unit test added
> 3. Introduced code sharing between e1000 and e1000e
> 4. Various code fixes as suggested by Jason
> 5. Rebased to the latest master
> 
> Changes since v1:
> 
> 1. PCI_PM_CAP_VER_1_1 is defined now in include/hw/pci/pci_regs.h and
>not in include/standard-headers/linux/pci_regs.h.
> 2. Changes in naming and extra comments in hw/pci/pcie.c and in
>include/hw/pci/pcie.h.
> 3. Defining pci_dsn_ver and pci_dsn_cap static const variables in
>hw/pci/pcie.c, instead of PCI_DSN_VER and PCI_DSN_CAP symbolic
>constants in include/hw/pci/pcie_regs.h.
> 4. Changing the vmxnet3_device_serial_num function in hw/net/vmxnet3.c
>to avoid the cast when it is called.
> 5. Avoiding a preceding underscore in all the e1000e-related names.
> 6. Minor style changes.
> 
> ===
> 
> Hello All,
> 
> This series is the final code of the e1000e device emulation, that we
> have developed. Please review, and consider acceptance of these patches
> to the upstream QEMU repository.
> 
> The code stability was verified by various traffic tests using Fedora 22
> Linux, and Windows Server 2012R2 guests. Also, Microsoft Hardware
> Certification Kit (HCK) tests were run on a Windows Server 2012R2 guest.
> 
> There was a discussion on the possibility of code sharing between the
> e1000e, and the existing e1000 devices. We have reviewed the final code
> for parts that may be shared between this device and the currently
> available e1000 emulation. The device specifications are very different,
> and there are almost no registers, nor functions, that were left as is
> from e1000. The ring descriptor structures were changed as well, by the
> introduction of extended and PS descriptors, as well as additional bits.
> 
> Additional differences stem from the fact that the e1000e device re-uses
> network packet abstractions introduced by the vmxnet3 device, while the
> e1000 has its own code for packet handling. BTW, it may be worth reusing
> those abstractions in e1000 as well. (Following these changes the
> vmxnet3 device was successfully tested for possible regressions.)
> 
> There are a few minor parts that may be shared, e.g. the default
> register handlers, and the ring management functions. The total amount
> of shared lines will be about 100--150, so we're not sure if it makes
> sense bothering, and taking a risk of breaking e1000, which is a good,
> old, and stable device.
> 
> Currently, the e1000e code is stand alone w.r.t. e1000.
> 
> Please share your thoughts.
> 
> Thanks in advance,
> Dmitry.
> 
> Changes since RFCv2:
> 
> 1. Device functionality verified using Microsoft Hardware Certification
> Test Kit (HCK)
> 2. Introduced a number of performance improvements
> 3. The code was cleaned, and rebased to the latest master
> 4. Patches verified with checkpatch.pl
> 
> ===
> 
> Changes since RFCv1:
> 
> 1. Added support for all the device features:
>   - Interrupt moderation.
>   - RSS.
>   - Multiqueue.
> 2. Simulated exact PCI/PCIe configuration space layout.
> 3. Made fixes needed to pass Microsoft's HW certification tests (HCK).
> 
> This series is still an RFC, because the following tasks are not done
> yet:
> 
> 1. See which code can be shared between this device and the existing
> e1000 device.
> 2. Rebase patches to the latest master (current base is v2.3.0).
> 
> Please share your thoughts,
> Thanks, Dmitry.
> 
> ===
> 
> Hello qemu-devel,
> 
> This patch series is an RFC for the new networking device emulation
> we're developing for QEMU.
> 
> This new device emulates the Intel 82574 GbE Controller and works
> with unmodified Intel e1000e drivers from the Linux/Windows kernels.
> 
> The status of the current series is "Functional Device Ready, work
> on Extended Features in Progress".
> 
> More precisely, these patches represent a functional device, which
> is recognized by the standard Intel drivers, and is able to transfer
> TX/RX packets with CSO/TSO offloads, according to the spec.
> 
> Extended features not supported yet (work in progress):
>   1. TX/RX Interrupt moderation mechanisms
>   2. RSS
>   3. Full-featured multi-q

Re: [Qemu-devel] [PATCH v6 01/17] pci: fix unaligned access in pci_xxx_quad()

2016-05-30 Thread Michael S. Tsirkin

On Mon, May 30, 2016 at 12:14:26PM +0300, Leonid Bloch wrote:
> From: Dmitry Fleytman 
> 
> Replace legacy cpu_to_le64w()/le64_to_cpup()
> calls with stq_le_p()/ldq_le_p().
> 
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Leonid Bloch 

Could you please add a code comment to clarify what's going on a bit more?
Something to the point that capabilities are guaranteed to
be dword-aligned only.

Also, this isn't a dependency of this patchset I think -
as far as I could say the only user of this is
pcie: Introduce function for DSN capability creation
but that merely accesses a capability, and all callers pass in
an aligned offset.

> ---
>  include/hw/pci/pci.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index ef6ba51..ee238ad 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
>  static inline void
>  pci_set_quad(uint8_t *config, uint64_t val)
>  {
> -cpu_to_le64w((uint64_t *)config, val);
> +stq_le_p(config, val);
>  }
>  
>  static inline uint64_t
>  pci_get_quad(const uint8_t *config)
>  {
> -return le64_to_cpup((const uint64_t *)config);
> +return ldq_le_p(config);
>  }
>  
>  static inline void
> -- 
> 2.5.5

Re: [Qemu-devel] [PATCH 04/10] qcow: add qcow_co_write_compressed

2016-05-30 Thread Pavel Butsykin


On 27.05.2016 20:45, Stefan Hajnoczi wrote:

On Sat, May 14, 2016 at 03:45:52PM +0300, Denis V. Lunev wrote:

+qemu_co_mutex_lock(&s->lock);
+cluster_offset = get_cluster_offset(bs, sector_num << 9, 2, out_len, 0, 0);
+qemu_co_mutex_unlock(&s->lock);
+if (cluster_offset == 0) {
+ret = -EIO;
+goto fail;
+}
+cluster_offset &= s->cluster_offset_mask;
+
+iov = (struct iovec) {
+.iov_base   = out_buf,
+.iov_len= out_len,
+};
+qemu_iovec_init_external(&hd_qiov, &iov, 1);
+ret = bdrv_co_pwritev(bs->file->bs, cluster_offset, out_len, &hd_qiov, 0);


Not sure if this has the same race condition as the qcow2 patch.  It
seems that bdrv_getlength() is used to extend the file on a per-sector
basis.  That would mean compressed data is not packed inside sectors and
no read-write-modify race condition exists, but I haven't fully audited
get_cluster_offset().



The get_cluster_offset() also doesn't allow to do multiple compressed
writes in a single cluster, because this function for all offsets
within the cluster returns the same cluster_offset. So here we just
can't write at offset in the cluster, only at the beginning of the
cluster.


Stefan

[Qemu-devel] [Bug 1587065] [NEW] btrfs qemu-ga - multiple mounts block fsfreeze

2016-05-30 Thread Dadio

Public bug reported:

Having two mounts of the same device makes fsfreeze through qemu-ga impossible.
root@CmsrvMTA:/# mount -l | grep /dev/vda2
/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
/dev/vda2 on /home type btrfs
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

Having two mounts is rather common with btrfs, so the feature fsfreeze
is unusable on these systems.

Below more information about how we encountered this issue...

Message send to qemu-disc...@nongnu.org:

Message 1:
--
I use external snapshots to backup my guests. I use the 'quiesce' option to
flush and frees the guest file system with the qemu guest agent.

With the exeption of one guest, this procedure works fine. On the 'unwilling'
guest, I get this error message:
"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable
to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /:
Device or resource busy"

I don't think this is not some sort of time-out error, because
activation of the fsfreeze and the error message happen immediately
after each other:

$ grep qemu-ga syslog.1
May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

This is the only entry of the qemu guest agent in syslog.

$ sudo virsh version
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Gebruikte API: QEMU 1.3.1
Draaiende hypervisor: QEMU 2.5.0

$ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
{"return":{"version":"2.5.0", ...
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
... }

For making an external snapshot, I use this command:
$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce
--no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

Piece of reply 1:
-
I have encountered this before. Some operating systems
may have bind-mounts that let a device appear multiple times in the mount
list. Unfortunately the guest agent is not smart enough to consider a device
that has been frozen as succesfull and keep going. This causes this specific
error.

Piece of reply 2:
-
Ok, that seems to be it.

I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
two separate sub volumes.

** Affects: qemu
Importance: Undecided
Status: New

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

Title:
btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
New

Bug description:
Having two mounts of the same device makes fsfreeze through qemu-ga
impossible.
root@CmsrvMTA:/# mount -l | grep /dev/vda2
/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
/dev/vda2 on /home type btrfs
(rw,relatime,space_cache,subvolid=258,subvol=/@home)

Having two mounts is rather common with btrfs, so the feature fsfreeze
is unusable on these systems.

Below more information about how we encountered this issue...

Message send to qemu-disc...@nongnu.org:

Message 1:
--
I use external snapshots to backup my guests. I use the 'quiesce' option to
flush and frees the guest file system with the qemu guest agent.

With the exeption of one guest, this procedure works fine. On the 'unwilling'
guest, I get this error message:
"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error:
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze
/: Device or resource busy"

I don't think this is not some sort of time-out error, because
activation of the fsfreeze and the error message happen immediately
after each other:

$ grep qemu-ga syslog.1
May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

This is the only entry of the qemu guest agent in syslog.

$ sudo virsh version
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Gebruikte API: QEMU 1.3.1
Draaiende hypervisor: QEMU 2.5.0

For making an external snapshot, I use this command:
$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

Re: [Qemu-devel] [PATCH RFC 0/2] enable iommu with -device

2016-05-30 Thread Marcel Apfelbaum


On 05/30/2016 04:43 PM, Peter Xu wrote:

On Mon, May 23, 2016 at 05:01:28PM +0300, Marcel Apfelbaum wrote:

This is a proposal on how to create the iommu with
'-device intel-iommu' instead of '-machine,iommu=on'.

The device is part of the machine properties because we wanted
to ensure it is created before any other PCI device.

The alternative is to skip the bus_master_enable_region at
the time the device is created. We can create this region
at machine_done phase. (patch 1)

Then we can enable sysbus devices for PC machines and make all the
init steps inside the iommu realize function. (patch 2)

The series is working, but a lot of issues are not resolved:
   - minimum testing was done
   - the iommu addr should be passed (maybe) in command line rather than 
hard-coded
   - enabling sysbus devices for PC machines is risky, I am not aware yet
 of the side effects of this modification.
   - I am not sure moving the bus_master_enable_region to machine_done
 is with no undesired effects.


I gave it a shot on the patches and it works nicely (of course no
complex configurations, like hot plug).

Could you help introduce what will bring us if we use "-device" rather
than "-M" options?  Benefits I can see is that, we can specify
parameters with specific device, rather than messing them up in
"machine" options. Do we have any other benefits that I may have
missed?


Hi Peter,
Thanks for trying it!

Mainly is about not hard-coding device options (e.g. PCI address for AMD IOMMU),
but also to avoid having devices added as a side-effect of some machine option.
This will bring as closer to a cleaner model of a modular machine.

I plan to post a non-rfc version soon.
Thanks,
Marcel




Thanks!

-- peterx

[Qemu-devel] [Bug 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze

2016-05-30 Thread Christian Theune

I'm the responder from the Qemu list. I reviewed that C code a while ago
when I stumbled over it. If someone helps me through the Qemu patch
acceptance process then I'm willing to provide a patch.

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

Title:
btrfs qemu-ga - multiple mounts block fsfreeze

Status in QEMU:
New

Having two mounts is rather common with btrfs, so the feature fsfreeze
is unusable on these systems.

Below more information about how we encountered this issue...

Message send to qemu-disc...@nongnu.org:

Message 1:
--
I use external snapshots to backup my guests. I use the 'quiesce' option to
flush and frees the guest file system with the qemu guest agent.

With the exeption of one guest, this procedure works fine. On the 'unwilling'
guest, I get this error message:
"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error:
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze
/: Device or resource busy"

I don't think this is not some sort of time-out error, because
activation of the fsfreeze and the error message happen immediately
after each other:

$ grep qemu-ga syslog.1
May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called

This is the only entry of the qemu guest agent in syslog.

$ sudo virsh version
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Gebruikte API: QEMU 1.3.1
Draaiende hypervisor: QEMU 2.5.0

For making an external snapshot, I use this command:
$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1

Piece of reply 2:
-
Ok, that seems to be it.

I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
two separate sub volumes.

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

< 1 2 3 >

101 - 200 of 207 matches

Mail list logo