Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. May 30, 2022
  3. May 26, 2022
  5. May 25, 2022
  7. May 19, 2022
    • Peter Maydell's avatar
      target/arm: Implement FEAT_IDST · 75662f36
      Peter Maydell authored 
      
The Armv8.4 feature FEAT_IDST specifies that exceptions generated by
read accesses to the feature ID space should report a syndrome code
of 0x18 (EC_SYSTEMREGISTERTRAP) rather than 0x00 (EC_UNCATEGORIZED).
The feature ID space is defined to be:
 op0 == 3, op1 == {0,1,3}, CRn == 0, CRm == {0-7}, op2 == {0-7}

In our implementation we might return the EC_UNCATEGORIZED syndrome
value for a system register access in four cases:
 * no reginfo struct in the hashtable
 * cp_access_ok() fails (ie ri->access doesn't permit the access)
 * ri->accessfn returns CP_ACCESS_TRAP_UNCATEGORIZED at runtime
 * ri->type includes ARM_CP_RAISES_EXC, and the readfn raises
   an UNDEF exception at runtime

We have very few regdefs that set ARM_CP_RAISES_EXC, and none of
them are in the feature ID space. (In the unlikely event that any
are added in future they would need to take care of setting the
correct syndrome themselves.) This patch deals with the other
three cases, and enables FEAT_IDST for AArch64 -cpu max.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220509155457.3560724-1-peter.maydell@linaro.org
      75662f36
    • Peter Maydell's avatar
      target/arm: Enable FEAT_S2FWB for -cpu max · e04bf5a7
      Peter Maydell authored 
      
Enable the FEAT_S2FWB for -cpu max. Since FEAT_S2FWB requires that
CLIDR_EL1.{LoUU,LoUIS} are zero, we explicitly squash these (the
inherited CLIDR_EL1 value from the Cortex-A57 has them as 1).

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20220505183950.2781801-5-peter.maydell@linaro.org
      e04bf5a7
  9. May 18, 2022
    • Thomas Huth's avatar
      docs/about: Update the support statement for Windows · 0ce9b08c
      Thomas Huth authored 
      Our support statement for Windows currently talks about "Vista / Server
2008" - which is related to the API of Windows, and this is not easy
to understand for the non-technical users. Additionally, glib sets the
_WIN32_WINNT macro to 0x0601 already, which indicates the Windows 7 API,
so QEMU effectively depends on the Windows 7 API, too.

Thus let's bump the _WIN32_WINNT setting in QEMU to the same level as
glib uses and adjust our support statement in the documentation to
something similar that we're using for Linux and the *BSD systems
(i.e. only the two most recent versions), which should hopefully be
easier to understand for the users now.

And since we're nowadays also compile-testing QEMU with MSYS2 on Windows
itself, I think we could mention this build environment here, too.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/880


Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarStefan Weil <sw@weilnetz.de>
Message-Id: <20220513063958.1181443-1-thuth@redhat.com>
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      0ce9b08c
  11. May 16, 2022
  13. May 14, 2022
  15. May 13, 2022
  17. May 12, 2022
    • Eric Blake's avatar
      nbd/server: Allow MULTI_CONN for shared writable exports · 58a6fdcc
      Eric Blake authored 
      
According to the NBD spec, a server that advertises
NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will
not see any cache inconsistencies: when properly separated by a single
flush, actions performed by one client will be visible to another
client, regardless of which client did the flush.

We always satisfy these conditions in qemu - even when we support
multiple clients, ALL clients go through a single point of reference
into the block layer, with no local caching.  The effect of one client
is instantly visible to the next client.  Even if our backend were a
network device, we argue that any multi-path caching effects that
would cause inconsistencies in back-to-back actions not seeing the
effect of previous actions would be a bug in that backend, and not the
fault of caching in qemu.  As such, it is safe to unconditionally
advertise CAN_MULTI_CONN for any qemu NBD server situation that
supports parallel clients.

Note, however, that we don't want to advertise CAN_MULTI_CONN when we
know that a second client cannot connect (for historical reasons,
qemu-nbd defaults to a single connection while nbd-server-add and QMP
commands default to unlimited connections; but we already have
existing means to let either style of NBD server creation alter those
defaults).  This is visible by no longer advertising MULTI_CONN for
'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation.

The harder part of this patch is setting up an iotest to demonstrate
behavior of multiple NBD clients to a single server.  It might be
possible with parallel qemu-io processes, but I found it easier to do
in python with the help of libnbd, and help from Nir and Vladimir in
writing the test.

Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Suggested-by: default avatarNir Soffer <nsoffer@redhat.com>
Suggested-by: default avatarVladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
Message-Id: <20220512004924.417153-3-eblake@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      58a6fdcc
  19. May 09, 2022
  21. May 07, 2022
  23. May 04, 2022
    • Kevin Wolf's avatar
      docs/vhost-user: Clarifications for VHOST_USER_ADD/REM_MEM_REG · 31009d13
      Kevin Wolf authored 
      
The specification for VHOST_USER_ADD/REM_MEM_REG messages is unclear
in several points, which has led to clients having incompatible
implementations. This changes the specification to be more explicit
about them:

* VHOST_USER_ADD_MEM_REG is not specified as receiving a file
  descriptor, though it obviously does need to do so. All
  implementations agree on this one, fix the specification.

* VHOST_USER_REM_MEM_REG is not specified as receiving a file
  descriptor either, and it also has no reason to do so. rust-vmm does
  not send file descriptors for removing a memory region (in agreement
  with the specification), libvhost-user and QEMU do (which is a bug),
  though libvhost-user doesn't actually make any use of it.

  Change the specification so that for compatibility QEMU's behaviour
  becomes legal, even if discouraged, but rust-vmm's behaviour becomes
  the explicitly recommended mode of operation.

* VHOST_USER_ADD_MEM_REG doesn't have a documented return value, which
  is the desired behaviour in the non-postcopy case. It also implemented
  like this in QEMU and rust-vmm, though libvhost-user is buggy and
  sometimes sends an unexpected reply. This will be fixed in a separate
  patch.

  However, in postcopy mode it does reply like VHOST_USER_SET_MEM_TABLE.
  This behaviour is shared between libvhost-user and QEMU; rust-vmm
  doesn't implement postcopy mode yet. Mention it explicitly in the
  spec.

* The specification doesn't mention how VHOST_USER_REM_MEM_REG
  identifies the memory region to be removed. Change it to describe the
  existing behaviour of libvhost-user (guest address, user address and
  size must match).

Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Message-Id: <20220407133657.155281-2-kwolf@redhat.com>
Reviewed-by: default avatarRaphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      31009d13