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. Jul 29, 2022
  3. Jul 20, 2022
  5. Jul 13, 2022
  7. 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
  9. Jun 28, 2022
  11. Jun 27, 2022
  13. Jun 21, 2022
  15. Jun 15, 2022
  17. Jun 09, 2022
  19. Jun 06, 2022
  21. Jun 03, 2022
  23. May 14, 2022
  25. 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
  27. May 12, 2022
  29. May 09, 2022
    • Gautam Agrawal's avatar
      Warn user if the vga flag is passed but no vga device is created · f9bcb2d6
      Gautam Agrawal authored 
      
A global boolean variable "vga_interface_created"(declared in softmmu/globals.c)
has been used to track the creation of vga interface. If the vga flag is passed
in the command line "default_vga"(declared in softmmu/vl.c) variable is set to 0.
To warn user, the condition checks if vga_interface_created is false
and default_vga is equal to 0. If "-vga none" is passed, this patch will not warn the
user regarding the creation of VGA device.

The warning "A -vga option was passed but this
machine type does not use that option; no VGA device has been created"
is logged if vga flag is passed but no vga device is created.

This patch has been tested for x86_64, i386, sparc, sparc64 and arm boards.

Signed-off-by: default avatarGautam Agrawal <gautamnagrawal@gmail.com>
Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/581


Message-Id: <20220501122505.29202-1-gautamnagrawal@gmail.com>
[thuth: Fix wrong warning with "-device" in some cases as reported by Paolo]
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      f9bcb2d6
    • Thomas Huth's avatar
      softmmu/vl: Fence 'xenfb' if Xen support is not compiled in · f07b3a83
      Thomas Huth authored 
      
The 'xenfb' parameter for the '-vga' command line option is currently
always enabled unconditionally (since the xenfb is not a proper QOM
device that could be tested via its class name). That means it also
shows up if Xen is not enabled at all, e.g. like this:

 $ ./qemu-system-sparc -vga help
 none                 no graphic card
 xenfb                Xen paravirtualized framebuffer
 tcx                  TCX framebuffer (default)
 cg3                  CG3 framebuffer

Let's avoid this situation by fencing the parameter with the
CONFIG_XEN_BACKEND switch.

Message-Id: <20220427123316.329312-1-thuth@redhat.com>
Acked-by: default avatarAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      f07b3a83
  31. Apr 28, 2022
    • Paolo Bonzini's avatar
      remove -writeconfig · e960a7ee
      Paolo Bonzini authored 
      
Like -set and -readconfig, it would not really be too hard to
extend -writeconfig to parsing mechanisms other than QemuOpts.
However, the uses of -writeconfig are substantially more
limited, as it is generally easier to write the configuration
by hand in the first place.  In addition, -writeconfig does
not even try to detect cases where it prints incorrect
syntax (for example if values have a quote in them, since
qemu_config_parse does not support any kind of escaping.
Just remove it.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220414145721.326866-1-pbonzini@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e960a7ee
  33. Apr 21, 2022
  35. Apr 20, 2022