qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 5449c2: spec/vhost-user: fix the VHOST_USER p


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 5449c2: spec/vhost-user: fix the VHOST_USER prefix
Date: Fri, 02 Dec 2016 01:30:04 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 5449c230fac9cd6a645fe8c85693444dad512b59
      
https://github.com/qemu/qemu/commit/5449c230fac9cd6a645fe8c85693444dad512b59
  Author: Wei Wang <address@hidden>
  Date:   2016-11-30 (Wed, 30 Nov 2016)

  Changed paths:
    M docs/specs/vhost-user.txt

  Log Message:
  -----------
  spec/vhost-user: fix the VHOST_USER prefix

Signed-off-by: Wei Wang <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 6cb99acc2808cc41e2d772a23e9cc564515535cc
      
https://github.com/qemu/qemu/commit/6cb99acc2808cc41e2d772a23e9cc564515535cc
  Author: Peter Xu <address@hidden>
  Date:   2016-11-30 (Wed, 30 Nov 2016)

  Changed paths:
    M hw/i386/intel_iommu.c

  Log Message:
  -----------
  intel_iommu: fix incorrect device invalidate

"mask" needs to be inverted before use.

Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: aa6c6ae843cbdc251224bc6170d2663ac929b04f
      
https://github.com/qemu/qemu/commit/aa6c6ae843cbdc251224bc6170d2663ac929b04f
  Author: Laszlo Ersek <address@hidden>
  Date:   2016-11-30 (Wed, 30 Nov 2016)

  Changed paths:
    M hw/arm/virt-acpi-build.c
    M hw/core/loader.c
    M hw/i386/acpi-build.c
    M hw/lm32/lm32_hwsetup.h
    M include/hw/loader.h

  Log Message:
  -----------
  loader: fix handling of custom address spaces when adding ROM blobs

* Commit 3e76099aacb4 ("loader: Allow a custom AddressSpace when loading
  ROMs") introduced the "Rom.as" field:

  (1) It modified the utility callers of rom_insert() to take "as" as a
      new parameter from *their* callers, and set "rom->as" from that
      parameter. The functions covered were rom_add_file() and
      rom_add_elf_program().

  (2) It also modified rom_insert() itself, to auto-assign
      "&address_space_memory", in case the external caller passed -- and
      the utility caller forwarded -- as=NULL.

  Except, commit 3e76099aacb4 forgot to update the third utility caller of
  rom_insert(), under point (1), namely rom_add_blob().

* Later, commit 5e774eb3bd264 ("loader: Add AddressSpace loading support
  to uImages") added the load_uimage_as() function, and the
  rom_add_blob_fixed_as() function-like macro, with the necessary changes
  elsewhere to propagate the new "as" parameter to rom_add_blob():

    load_uimage_as()
      load_uboot_image()
  rom_add_blob_fixed_as()
    rom_add_blob()

  At this point, the signature (and workings) of rom_add_blob() had been
  broken already, and the rom_add_blob_fixed_as() macro passed its "_as"
  parameter to rom_add_blob() as "callback_opaque". Given that the
  "fw_callback" parameter itself was set to NULL (correctly), this did no
  additional damage (the opaque arg would never be used), but ultimately
  it broke the new functionality of load_uimage_as().

* The load_uimage_as() function would be put to use in one of the later
  patches, commit e481a1f63c93 ("generic-loader: Add a generic loader").

* We can fix this only in a unified patch now. Append "AddressSpace *as"
  to the signature of rom_add_blob(), and handle the new parameter. Pass
  NULL from all current callers, except from rom_add_blob_fixed_as(),
  where "_as" has to be bumped to the proper position.

* Note that rom_add_file() rejects the case when both "mr" and "as" are
  passed in as non-NULL. The action that this is apparently supposed to
  prevent is the

    rom->mr = mr;

  assignment (that's the only place where the "mr" parameter is used in
  rom_add_file()). In rom_add_blob() though, we have no "mr" parameter,
  and the actions done on the fw_cfg branch:

    if (fw_file_name && fw_cfg) {
  if (mc->rom_file_has_mr) {
      data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
      mr = rom->mr;
  } else {
      data = rom->data;
  }

  reflect those that are performed by rom_add_file() too (with mr==NULL):

    if (rom->fw_file && fw_cfg) {
  if ((!option_rom || mc->option_rom_has_mr) &&
      mc->rom_file_has_mr) {
      data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
  } else {
      data = rom->data;
  }

  Hence we need no additional restrictions in rom_add_blob().

* Stable is not affected as both problematic commits appeared first in
  v2.8.0-rc0.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Alistair Francis <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Michael Walle <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Cc: Peter Maydell <address@hidden>
Cc: Shannon Zhao <address@hidden>
Cc: address@hidden
Cc: address@hidden
Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6
Fixes: 5e774eb3bd264c76484906f4bd0fb38e00b8090e
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 1b57bd4f2f4993104a5cb48912435396faa10d58
      
https://github.com/qemu/qemu/commit/1b57bd4f2f4993104a5cb48912435396faa10d58
  Author: Laszlo Ersek <address@hidden>
  Date:   2016-11-30 (Wed, 30 Nov 2016)

  Changed paths:
    M hw/core/loader.c

  Log Message:
  -----------
  loader: fix undefined behavior in rom_order_compare()

According to ISO C99 / N1256 (referenced in HACKING):

> 6.5.8 Relational operators
>
> 4 For the purposes of these operators, a pointer to an object that is
>   not an element of an array behaves the same as a pointer to the first
>   element of an array of length one with the type of the object as its
>   element type.
>
> 5 When two pointers are compared, the result depends on the relative
>   locations in the address space of the objects pointed to. If two
>   pointers to object or incomplete types both point to the same object,
>   or both point one past the last element of the same array object, they
>   compare equal. If the objects pointed to are members of the same
>   aggregate object, pointers to structure members declared later compare
>   greater than pointers to members declared earlier in the structure,
>   and pointers to array elements with larger subscript values compare
>   greater than pointers to elements of the same array with lower
>   subscript values. All pointers to members of the same union object
>   compare equal. If the expression /P/ points to an element of an array
>   object and the expression /Q/ points to the last element of the same
>   array object, the pointer expression /Q+1/ compares greater than /P/.
>   In all other cases, the behavior is undefined.

Our AddressSpace objects are allocated generally individually, and kept in
the "address_spaces" linked list, so we mustn't compare their addresses
with relops.

Convert the pointers subjected to the relop in rom_order_compare() to
"uintptr_t":

> 7.18.1.4 Integer types capable of holding object pointers
>
> 1 [...]
>
>   The following type designates an unsigned integer type with the
>   property that any valid pointer to void can be converted to this type,
>   then converted back to pointer to void, and the result will compare
>   equal to the original pointer:
>
>   /uintptr_t/
>
>   These types are optional.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Alistair Francis <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Cc: Peter Maydell <address@hidden>
Cc: address@hidden
Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 9730280d54634caa5d63f0d8fcd85da8311d2ebf
      
https://github.com/qemu/qemu/commit/9730280d54634caa5d63f0d8fcd85da8311d2ebf
  Author: Gonglei <address@hidden>
  Date:   2016-11-30 (Wed, 30 Nov 2016)

  Changed paths:
    M hw/virtio/virtio-crypto.c

  Log Message:
  -----------
  virtio-crypto: fix uninitialized variables

Though crypto_cfg.reserve is an unused field, let me
initialize the structure in order to make coverity happy.

*** CID 1365923:  Uninitialized variables  (UNINIT)
/hw/virtio/virtio-crypto.c: 851 in virtio_crypto_get_config()
845         stl_le_p(&crypto_cfg.mac_algo_h, c->conf.mac_algo_h);
846         stl_le_p(&crypto_cfg.aead_algo, c->conf.aead_algo);
847         stl_le_p(&crypto_cfg.max_cipher_key_len, 
c->conf.max_cipher_key_len);
848         stl_le_p(&crypto_cfg.max_auth_key_len, c->conf.max_auth_key_len);
849         stq_le_p(&crypto_cfg.max_size, c->conf.max_size);
850
>>>     CID 1365923:  Uninitialized variables  (UNINIT)
>>>     Using uninitialized value "crypto_cfg". Field "crypto_cfg.reserve"
       is uninitialized when calling "memcpy".
      [Note: The source code implementation of the function
       has been overridden by a builtin model.]
851         memcpy(config, &crypto_cfg, c->config_size);
852     }
853

Rported-by: Markus Armbruster <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 5c0139a8c2f01e068c96d456ecf12b0eeb707660
      
https://github.com/qemu/qemu/commit/5c0139a8c2f01e068c96d456ecf12b0eeb707660
  Author: Michael Roth <address@hidden>
  Date:   2016-12-01 (Thu, 01 Dec 2016)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: fix default DRC state for coldplugged LMBs

Currently we set the initial isolation/allocation state for DRCs
associated with coldplugged LMBs to ISOLATED/UNUSABLE,
respectively, under the assumption that the guest will move this
state to UNISOLATED/USABLE.

In fact, this is only the case for LMBs added via hotplug. For
coldplugged LMBs, the guest actually assumes the initial state to
be UNISOLATED/USABLE.

In practice, this only becomes an issue when we attempt to unplug
one of these LMBs, where the guest kernel will issue an
rtas-get-sensor-state call to check that the corresponding DRC is
in an USABLE state before it will release the LMB back to
QEMU. If the returned state is otherwise, the guest will assume no
further action is needed, which bypasses the QEMU-side cleanup that
occurs during the USABLE->UNUSABLE transition. This results in
LMBs and their corresponding pc-dimm devices to stick around
indefinitely.

This patch fixes the issue by manually setting DRCs associated with
cold-plugged LMBs to UNISOLATED/ALLOCATED, but leaving the hotplug
state untouched. As it turns out, this is analogous to the handling
for cold-plugged CPUs in spapr_core_plug().

Cc: address@hidden
Cc: David Gibson <address@hidden>
Cc: Bharata B Rao <address@hidden>
Cc: Greg Kurz <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 2cfe5d7bc2662b1fe4a8bfc0a847ab0db6948695
      
https://github.com/qemu/qemu/commit/2cfe5d7bc2662b1fe4a8bfc0a847ab0db6948695
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-12-01 (Thu, 01 Dec 2016)

  Changed paths:
    M docs/specs/vhost-user.txt
    M hw/arm/virt-acpi-build.c
    M hw/core/loader.c
    M hw/i386/acpi-build.c
    M hw/i386/intel_iommu.c
    M hw/lm32/lm32_hwsetup.h
    M hw/virtio/virtio-crypto.c
    M include/hw/loader.h

  Log Message:
  -----------
  Merge remote-tracking branch 'mst/tags/for_upstream' into staging

virtio, vhost, pc: fixes

Minor fixes since 2.8.0-rc2.

Signed-off-by: Michael S. Tsirkin <address@hidden>

# gpg: Signature made Wed 30 Nov 2016 02:25:12 AM GMT
# gpg:                using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <address@hidden>"
# gpg:                 aka "Michael S. Tsirkin <address@hidden>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* mst/tags/for_upstream:
  virtio-crypto: fix uninitialized variables
  loader: fix undefined behavior in rom_order_compare()
  loader: fix handling of custom address spaces when adding ROM blobs
  intel_iommu: fix incorrect device invalidate
  spec/vhost-user: fix the VHOST_USER prefix

Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: bd8ef5060dd2124a54578241da9a572faf7658dd
      
https://github.com/qemu/qemu/commit/bd8ef5060dd2124a54578241da9a572faf7658dd
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-12-01 (Thu, 01 Dec 2016)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  Merge remote-tracking branch 'dgibson/tags/ppc-for-2.8-20161201' into staging

ppc patch queue 2016-12-01

Just a single migration / hotplug fix in this set.  I believe it's
important enough to go in this late in the 2.8 release process.

# gpg: Signature made Thu 01 Dec 2016 04:43:49 AM GMT
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* dgibson/tags/ppc-for-2.8-20161201:
  spapr: fix default DRC state for coldplugged LMBs

Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>


Compare: https://github.com/qemu/qemu/compare/1cd56fd2e14f...bd8ef5060dd2

reply via email to

[Prev in Thread] Current Thread [Next in Thread]