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. Aug 07, 2023
  3. Jul 12, 2023
  5. Jun 07, 2023
  7. Jun 01, 2023
  9. May 18, 2023
  11. May 10, 2023
  13. Mar 07, 2023
  15. Feb 27, 2023
    • Philippe Mathieu-Daudé's avatar
      replay: Extract core API to 'exec/replay-core.h' · 5b5968c4
      Philippe Mathieu-Daudé authored 
      
replay API is used deeply within TCG common code (common to user
and system emulation). Unfortunately "sysemu/replay.h" requires
some QAPI headers for few system-specific declarations, example:

  void replay_input_event(QemuConsole *src, InputEvent *evt);

Since commit c2651c0e ("qapi/meson: Restrict UI module to system
emulation and tools") the QAPI header defining the InputEvent is
not generated anymore.
To keep it simple, extract the 'core' replay prototypes to a new
"exec/replay-core.h" header which we include in the TCG code that
doesn't need the rest of the replay API.

Reviewed-by: default avatarPavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <20221219170806.60580-5-philmd@linaro.org>
Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      5b5968c4
  17. Feb 23, 2023
    • Markus Armbruster's avatar
      hw/acpi: Move QMP command to hw/core/ · 36ebc7db
      Markus Armbruster authored 
      
The QERR_ macros are leftovers from the days of "rich" error objects.
We've been trying to reduce their remaining use.

qmp_query_vm_generation_id() in stubs/vmgenid.c is the last user of
QERR_UNSUPPORTED outside qga/.  Unlike the stubs we just dropped, it
is actually reachable, namely when CONFIG_ACPI_VMGENID is off.  It
always fails like

    (qemu) info vm-generation-id
    Error: this feature or command is not currently supported

Turns out the real qmp_query_vm_generation_id() doesn't actually
depend on CONFIG_ACPI_VMGENID, and fails safely when it's off.  Move
it to hw/core/machine-qmp-cmds.c, and drop the stub.  The error
message becomes

    Error: VM Generation ID device not found

Feels like an improvement to me.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Message-Id: <20230207075115.1525-8-armbru@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
      36ebc7db
  19. Dec 15, 2022
  21. Dec 14, 2022
    • Markus Armbruster's avatar
      qapi qdev qom: Elide redundant has_FOO in generated C · 047f2ca1
      Markus Armbruster authored 
      
The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/qdev.json and
qapi/qom.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Eduardo Habkost <eduardo@habkost.net>
Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-21-armbru@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      047f2ca1
  23. Nov 11, 2022
    • Thomas Huth's avatar
      qga: Allow building of the guest agent without system emulators or tools · e0091133
      Thomas Huth authored 
      
If configuring with "--disable-system --disable-user --enable-guest-agent"
the linking currently fails with:

qga/qemu-ga.p/commands.c.o: In function `qmp_command_info':
build/../../home/thuth/devel/qemu/qga/commands.c:70: undefined reference to `qmp_command_name'
build/../../home/thuth/devel/qemu/qga/commands.c:71: undefined reference to `qmp_command_is_enabled'
build/../../home/thuth/devel/qemu/qga/commands.c:72: undefined reference to `qmp_has_success_response'
qga/qemu-ga.p/commands.c.o: In function `qmp_guest_info':
build/../../home/thuth/devel/qemu/qga/commands.c:82: undefined reference to `qmp_for_each_command'
qga/qemu-ga.p/commands.c.o: In function `qmp_guest_exec':
build/../../home/thuth/devel/qemu/qga/commands.c:410: undefined reference to `qbase64_decode'
qga/qemu-ga.p/channel-posix.c.o: In function `ga_channel_open':
build/../../home/thuth/devel/qemu/qga/channel-posix.c:214: undefined reference to `unix_listen'
build/../../home/thuth/devel/qemu/qga/channel-posix.c:228: undefined reference to `socket_parse'
build/../../home/thuth/devel/qemu/qga/channel-posix.c:234: undefined reference to `socket_listen'
qga/qemu-ga.p/commands-posix.c.o: In function `qmp_guest_file_write':
build/../../home/thuth/devel/qemu/qga/commands-posix.c:527: undefined reference to `qbase64_decode'

Let's make sure that we also compile and link the required files if
the system emulators have not been enabled.

Message-Id: <20221110083626.31899-1-thuth@redhat.com>
Tested-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      e0091133
  25. Oct 26, 2022
    • Stefan Hajnoczi's avatar
      stubs: add qemu_ram_block_from_host() and qemu_ram_get_fd() · 701bff24
      Stefan Hajnoczi authored 
      
The blkio block driver will need to look up the file descriptor for a
given pointer. This is possible in softmmu builds where the RAMBlock API
is available for querying guest RAM.

Add stubs so tools like qemu-img that link the block layer still build
successfully. In this case there is no guest RAM but that is fine.
Bounce buffers and their file descriptors will be allocated with
libblkio's blkio_alloc_mem_region() so we won't rely on QEMU's
qemu_ram_get_fd() in that case.

Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-id: 20221013185908.1297568-12-stefanha@redhat.com
Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      701bff24
  27. Sep 29, 2022
  29. 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
  31. Jul 28, 2022
  33. Jun 28, 2022
  35. Jun 27, 2022
  37. Jun 15, 2022
  39. Jun 06, 2022
  41. Apr 21, 2022
  43. Apr 06, 2022
  45. Mar 04, 2022
    • Emanuele Giuseppe Esposito's avatar
      main-loop.h: introduce qemu_in_main_thread() · 6538692e
      Emanuele Giuseppe Esposito authored 
      
When invoked from the main loop, this function is the same
as qemu_mutex_iothread_locked, and returns true if the BQL is held.
When invoked from iothreads or tests, it returns true only
if the current AioContext is the Main Loop.

This essentially just extends qemu_mutex_iothread_locked to work
also in unit tests or other users like storage-daemon, that run
in the Main Loop but end up using the implementation in
stubs/iothread-lock.c.

Using qemu_mutex_iothread_locked in unit tests defaults to false
because they use the implementation in stubs/iothread-lock,
making all assertions added in next patches fail despite the
AioContext is still the main loop.

See the comment in the function header for more information.

Signed-off-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20220303151616.325444-2-eesposit@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      6538692e
  47. Jan 18, 2022
  49. Nov 04, 2021
  51. Nov 02, 2021
  53. Oct 14, 2021
  55. Sep 30, 2021
  57. Sep 04, 2021
  59. Aug 31, 2021
  61. Aug 26, 2021
  63. Jul 14, 2021
  65. Jul 09, 2021
  67. Jun 18, 2021
    • Paolo Bonzini's avatar
      async: the main AioContext is only "current" if under the BQL · 5f50be9b
      Paolo Bonzini authored 
      
If we want to wake up a coroutine from a worker thread, aio_co_wake()
currently does not work.  In that scenario, aio_co_wake() calls
aio_co_enter(), but there is no current AioContext and therefore
qemu_get_current_aio_context() returns the main thread.  aio_co_wake()
then attempts to call aio_context_acquire() instead of going through
aio_co_schedule().

The default case of qemu_get_current_aio_context() was added to cover
synchronous I/O started from the vCPU thread, but the main and vCPU
threads are quite different.  The main thread is an I/O thread itself,
only running a more complicated event loop; the vCPU thread instead
is essentially a worker thread that occasionally calls
qemu_mutex_lock_iothread().  It is only in those critical sections
that it acts as if it were the home thread of the main AioContext.

Therefore, this patch detaches qemu_get_current_aio_context() from
iothreads, which is a useless complication.  The AioContext pointer
is stored directly in the thread-local variable, including for the
main loop.  Worker threads (including vCPU threads) optionally behave
as temporary home threads if they have taken the big QEMU lock,
but if that is not the case they will always schedule coroutines
on remote threads via aio_co_schedule().

With this change, the stub qemu_mutex_iothread_locked() must be changed
from true to false.  The previous value of true was needed because the
main thread did not have an AioContext in the thread-local variable,
but now it does have one.

Reported-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210609122234.544153-1-pbonzini@redhat.com>
Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Tested-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[eblake: tweak commit message per Vladimir's review]
Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      5f50be9b
  69. Jun 15, 2021