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. Sep 23, 2022
  3. Sep 19, 2022
  5. Sep 13, 2022
    • Peter Maydell's avatar
      semihosting: Allow optional use of semihosting from userspace · 5202861b
      Peter Maydell authored 
      
Currently our semihosting implementations generally prohibit use of
semihosting calls in system emulation from the guest userspace.  This
is a very long standing behaviour justified originally "to provide
some semblance of security" (since code with access to the
semihosting ABI can do things like read and write arbitrary files on
the host system).  However, it is sometimes useful to be able to run
trusted guest code which performs semihosting calls from guest
userspace, notably for test code.  Add a command line suboption to
the existing semihosting-config option group so that you can
explicitly opt in to semihosting from guest userspace with
 -semihosting-config userspace=on

(There is no equivalent option for the user-mode emulator, because
there by definition all code runs in userspace and has access to
semihosting already.)

This commit adds the infrastructure for the command line option and
adds a bool 'is_user' parameter to the function
semihosting_userspace_enabled() that target code can use to check
whether it should be permitting the semihosting call for userspace.
It mechanically makes all the callsites pass 'false', so they
continue checking "is semihosting enabled in general".  Subsequent
commits will make each target that implements semihosting honour the
userspace=on option by passing the correct value and removing
whatever "don't do this for userspace" checking they were doing by
hand.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Acked-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-Id: <20220822141230.3658237-2-peter.maydell@linaro.org>
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      5202861b
  7. Sep 06, 2022
  9. Sep 02, 2022
  11. Aug 26, 2022
  13. Aug 08, 2022
    • Paolo Bonzini's avatar
      vl: remove dead code in parse_memory_options() · 69c05a23
      Paolo Bonzini authored 
      
mem_str will never be an empty string, because qemu_opt_get_size() fails
if it encounters one:

   $ ./qemu-system-x86_64 -m size=
   qemu-system-x86_64: -m size=: Parameter size expects a non-negative number below 2^64
   Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta-
   and exabytes, respectively.

Suggested-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      69c05a23
    • Paolo Bonzini's avatar
      vl: fix [memory] section with -readconfig · e12f0685
      Paolo Bonzini authored 
      
The -M memory.* options do not have magic applied to them like the -m
option, namely no "M" (for mebibytes) is tacked at the end of a suffixless
value for "-M memory.size".

This magic is performed by parse_memory_options, and we have to do it for
both "-m" and the [memory] section of a config file.  Storing [memory]
sections directly to machine_opts_dict changed the meaning of

    [memory]
      size = "1024"

in a -readconfig file from 1024MiB to 8KiB (1024 Bytes rounded up to
8KiB silently).  To avoid this, the [memory] section has to be changed
back to QemuOpts (combining [memory] and "-m" will work fine thanks to
.merge_lists being true).

Change parse_memory_options() so that, similar to the older function
set_memory_options(), it operates after command line parsing is done;
and also call it where set_memory_options() used to be.

Note, the parsing code uses exit(1) instead of exit(EXIT_FAILURE) to
match neighboring code.

Reported-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
Fixes: ce9d03fb ("machine: add mem compound property", 2022-05-12)
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e12f0685
  15. Jul 29, 2022
  17. Jul 20, 2022
  19. Jul 13, 2022
  21. Jul 12, 2022
    • Hanna Reitz's avatar
      vl: Unlink absolute PID file path · 85c4bf8a
      Hanna Reitz authored 
      
After writing the PID file, we register an exit notifier to unlink it
when the process terminates.  However, if the process has changed its
working directory in the meantime (e.g. in os_setup_post() when
daemonizing), this will not work when the PID file path was relative.
Therefore, pass the absolute path (created with realpath()) to the
unlink() call in the exit notifier.

(realpath() needs a path pointing to an existing file, so we cannot use
it before qemu_write_pidfile().)

Reproducer:
$ cd /tmp
$ qemu-system-x86_64 --daemonize --pidfile qemu.pid
$ file qemu.pid
qemu.pid: ASCII text
$ kill $(cat qemu.pid)
$ file qemu.pid
qemu.pid: ASCII text

(qemu.pid should be gone after the process has terminated.)

Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
Message-Id: <20220609122701.17172-4-hreitz@redhat.com>
Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      85c4bf8a
    • Hanna Reitz's avatar
      vl: Conditionally register PID file unlink notifier · eed29d49
      Hanna Reitz authored 
      
Currently, the exit notifier for unlinking the PID file is registered
unconditionally.  Limit it to only when we actually do create a PID
file.

Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
Message-Id: <20220609122701.17172-3-hreitz@redhat.com>
Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      eed29d49
  23. Jun 28, 2022
  25. Jun 27, 2022
  27. Jun 21, 2022
  29. Jun 15, 2022
  31. Jun 09, 2022
  33. Jun 06, 2022
  35. Jun 03, 2022
  37. May 14, 2022
  39. May 13, 2022
    • Jonathan Cameron's avatar
      hw/cxl/host: Add support for CXL Fixed Memory Windows. · aadfe320
      Jonathan Cameron authored 
      
The concept of these is introduced in [1] in terms of the
description the CEDT ACPI table. The principal is more general.
Unlike once traffic hits the CXL root bridges, the host system
memory address routing is implementation defined and effectively
static once observable by standard / generic system software.
Each CXL Fixed Memory Windows (CFMW) is a region of PA space
which has fixed system dependent routing configured so that
accesses can be routed to the CXL devices below a set of target
root bridges. The accesses may be interleaved across multiple
root bridges.

For QEMU we could have fully specified these regions in terms
of a base PA + size, but as the absolute address does not matter
it is simpler to let individual platforms place the memory regions.

ExampleS:
-cxl-fixed-memory-window targets.0=cxl.0,size=128G
-cxl-fixed-memory-window targets.0=cxl.1,size=128G
-cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k

Specifies
* 2x 128G regions not interleaved across root bridges, one for each of
  the root bridges with ids cxl.0 and cxl.1
* 256G region interleaved across root bridges with ids cxl.0 and cxl.1
with a 2k interleave granularity.

When system software enumerates the devices below a given root bridge
it can then decide which CFMW to use. If non interleave is desired
(or possible) it can use the appropriate CFMW for the root bridge in
question.  If there are suitable devices to interleave across the
two root bridges then it may use the 3rd CFMS.

A number of other designs were considered but the following constraints
made it hard to adapt existing QEMU approaches to this particular problem.
1) The size must be known before a specific architecture / board brings
   up it's PA memory map.  We need to set up an appropriate region.
2) Using links to the host bridges provides a clean command line interface
   but these links cannot be established until command line devices have
   been added.

Hence the two step process used here of first establishing the size,
interleave-ways and granularity + caching the ids of the host bridges
and then, once available finding the actual host bridges so they can
be used later to support interleave decoding.

[1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications)

Signed-off-by: default avatarJonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema
Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com>
Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      aadfe320
  41. May 12, 2022