Skip to content
Snippets Groups Projects
  1. Mar 22, 2019
  2. Mar 21, 2019
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/berrange/tags/authz-next-pull-request' into staging · c692931c
      Peter Maydell authored
      
      Fix object interface check macro usage
      
      # gpg: Signature made Thu 21 Mar 2019 11:53:15 GMT
      # gpg:                using RSA key BE86EBB415104FDF
      # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
      # gpg:                 aka "Daniel P. Berrange <berrange@redhat.com>" [full]
      # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF
      
      * remotes/berrange/tags/authz-next-pull-request:
        authz: Use OBJECT_CHECK() on objects
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      c692931c
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/berrange/tags/qcrypto-next-pull-request' into staging · 9b198f93
      Peter Maydell authored
      
      Avoid struct packing warnings with gcc9
      
      # gpg: Signature made Thu 21 Mar 2019 11:55:03 GMT
      # gpg:                using RSA key BE86EBB415104FDF
      # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
      # gpg:                 aka "Daniel P. Berrange <berrange@redhat.com>" [full]
      # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF
      
      * remotes/berrange/tags/qcrypto-next-pull-request:
        crypto/block: remove redundant struct packing to fix build with gcc 9
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      9b198f93
    • Greg Kurz's avatar
      crypto/block: remove redundant struct packing to fix build with gcc 9 · 5993e3be
      Greg Kurz authored
      
      Build fails with gcc 9:
      
      crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
        689 |     be32_to_cpus(&luks->header.payload_offset);
            |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
        690 |     be32_to_cpus(&luks->header.key_bytes);
            |                  ^~~~~~~~~~~~~~~~~~~~~~~
      crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
        691 |     be32_to_cpus(&luks->header.master_key_iterations);
            |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      ... a bunch of similar errors...
      
      crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
       1288 |         be32_to_cpus(&luks->header.key_slots[i].stripes);
            |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      cc1: all warnings being treated as errors
      
      All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are
      naturally aligned and we already check at build time there isn't any
      unwanted padding. Drop the QEMU_PACKED attribute.
      
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      5993e3be
    • Philippe Mathieu-Daudé's avatar
      authz: Use OBJECT_CHECK() on objects · 063603d4
      Philippe Mathieu-Daudé authored
      
      TYPE_QAUTHZ is an abstract object of type TYPE_OBJECT. All other
      are children of TYPE_QAUTHZ, thus also objects.
      
      Keep INTERFACE_CHECK() for interfaces, and use OBJECT_CHECK() on
      objects.
      
      Reported-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      063603d4
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request' into staging · 6532dceb
      Peter Maydell authored
      
      Merge I/O patch queue
      
      Fix problem with end of file handling with websock channels
      
      # gpg: Signature made Wed 20 Mar 2019 16:57:15 GMT
      # gpg:                using RSA key BE86EBB415104FDF
      # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
      # gpg:                 aka "Daniel P. Berrange <berrange@redhat.com>" [full]
      # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF
      
      * remotes/berrange/tags/qio-next-pull-request:
        io: fix handling of EOF / error conditions in websock GSource
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      6532dceb
  3. Mar 20, 2019
    • Daniel P. Berrangé's avatar
      io: fix handling of EOF / error conditions in websock GSource · dd154c4d
      Daniel P. Berrangé authored
      
      We were never reporting the G_IO_HUP event when an end of file was hit
      on the websocket channel.
      
      We also didn't report G_IO_ERR when we hit a fatal error processing the
      websocket protocol.
      
      The latter in particular meant that the chardev code would not notice
      when an eof/error was encountered on the websocket channel, unless the
      guest OS happened to trigger a write operation.
      
      This meant that once the first client had quit, the chardev would never
      listen to accept a new client.
      
      Fixes launchpad bug 1816819
      Acked-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      dd154c4d
    • Daniel P. Berrangé's avatar
      docs: add note about stibp CPU feature for spectre v2 · 21ee4787
      Daniel P. Berrangé authored
      
      While the stibp CPU feature is not commonly used by guest OS for spectre
      mitigation due to its performance impact, it is none the less best
      practice to expose it to all guest OS. This allows the guest OS to
      decide whether to make use or it.
      
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-Id: <20190307121838.6345-3-berrange@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      21ee4787
    • Daniel P. Berrangé's avatar
      docs: clarify that spec-ctrl is only needed for Spectre v2 · 174a78a8
      Daniel P. Berrangé authored
      
      The docs currently say that the spec-ctrl feature is needed for both
      Spectre variants, but it is only used to address Spectre v2. Also
      remove the note about retpolines. The guest OS is usually treated
      as a blackbox from host mgmt pov, so it won't have knowledge about
      use of retpolines and thus should unconditionally expose spec-ctrl,
      allowing the guest to decide whether to use it or not.
      
      Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-Id: <20190307121838.6345-2-berrange@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      174a78a8
    • Eduardo Habkost's avatar
      i386: Disable OSPKE on CPU model definitions · bb4928c7
      Eduardo Habkost authored
      
      Currently, the Cascadelake-Server, Icelake-Client, and
      Icelake-Server are always generating the following warning:
      
        qemu-system-x86_64: warning: \
          host doesn't support requested feature: CPUID.07H:ECX [bit 4]
      
      This happens because OSPKE was never returned by
      GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word().
      OSPKE is a runtime flag automatically set by the KVM module or by
      TCG code, was always cleared by x86_cpu_filter_features(), and
      was not supposed to appear on the CPU model table.
      
      Remove the OSPKE flag from the CPU model table entries, to avoid
      the bogus warning and avoid returning invalid feature data on
      query-cpu-* QMP commands.  As OSPKE was always cleared by
      x86_cpu_filter_features(), this won't have any guest-visible
      impact.
      
      Include a test case that should detect the problem if we introduce
      a similar bug again.
      
      Fixes: c7a88b52 ("i386: Add new model of Cascadelake-Server")
      Fixes: 8a11c62d ("i386: Add new CPU model Icelake-{Server,Client}")
      Cc: Tao Xu <tao3.xu@intel.com>
      Cc: Robert Hoo <robert.hu@linux.intel.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20190319200515.14999-1-ehabkost@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      bb4928c7
    • Eduardo Habkost's avatar
      i386: Make arch_capabilities migratable · 014018e1
      Eduardo Habkost authored
      
      Now that kvm_arch_get_supported_cpuid() will only return
      arch_capabilities if QEMU is able to initialize the MSR properly,
      we know that the feature is safely migratable.
      
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20190125220606.4864-3-ehabkost@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      014018e1
    • Eduardo Habkost's avatar
      i386: kvm: Disable arch_capabilities if MSR can't be set · 485b1d25
      Eduardo Habkost authored
      
      KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:
      
      1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
         is always supported") makes GET_SUPPORTED_CPUID return
         arch_capabilities even if running on SVM.  This makes "-cpu
         host,migratable=off" incorrectly expose arch_capabilities on CPUID on
         AMD hosts (where the MSR is not emulated by KVM).
      
      2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if
         the MSR is not supported by the host CPU.  This makes QEMU not
         initialize the MSR properly at kvm_put_msrs() on those hosts.
      
      Work around both bugs on the QEMU side, by checking if the MSR
      was returned by KVM_GET_MSR_INDEX_LIST before returning the
      feature flag on kvm_arch_get_supported_cpuid().
      
      This has the unfortunate side effect of making arch_capabilities
      unavailable on hosts without hardware support for the MSR until bug #2
      is fixed on KVM, but I can't see another way to work around bug #1
      without that side effect.
      
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20190125220606.4864-2-ehabkost@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      485b1d25
  4. Mar 19, 2019
Loading