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. Dec 22, 2023
    • Kevin Wolf's avatar
      vl: Improve error message for conflicting -incoming and -loadvm · 64537ff1
      Kevin Wolf authored 
      
Currently, the conflict between -incoming and -loadvm is only detected
when loading the snapshot fails because the image is still inactive for
the incoming migration. This results in a suboptimal error message:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots

Catch the situation already in qemu_validate_options() to improve the
message:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: 'incoming' and 'loadvm' options are mutually exclusive

Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-3-kwolf@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5a7f21efaf99c60614fe1967be1c0f9aa46c526e)
Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      64537ff1
  3. Dec 04, 2023
  5. Nov 24, 2023
  7. Nov 21, 2023
  9. Nov 17, 2023
  11. Nov 14, 2023
  13. Nov 07, 2023
  15. Nov 03, 2023
  17. Nov 02, 2023
  19. Oct 27, 2023
  21. Oct 25, 2023
  23. Oct 20, 2023
  25. Oct 19, 2023
  27. Oct 16, 2023
  29. Oct 12, 2023
    • David Hildenbrand's avatar
      memory,vhost: Allow for marking memory device memory regions unmergeable · 533f5d66
      David Hildenbrand authored 
      
Let's allow for marking memory regions unmergeable, to teach
flatview code and vhost to not merge adjacent aliases to the same memory
region into a larger memory section; instead, we want separate aliases to
stay separate such that we can atomically map/unmap aliases without
affecting other aliases.

This is desired for virtio-mem mapping device memory located on a RAM
memory region via multiple aliases into a memory region container,
resulting in separate memslots that can get (un)mapped atomically.

As an example with virtio-mem, the layout would look something like this:
  [...]
  0000000240000000-00000020bfffffff (prio 0, i/o): device-memory
    0000000240000000-000000043fffffff (prio 0, i/o): virtio-mem
      0000000240000000-000000027fffffff (prio 0, ram): alias memslot-0 @mem2 0000000000000000-000000003fffffff
      0000000280000000-00000002bfffffff (prio 0, ram): alias memslot-1 @mem2 0000000040000000-000000007fffffff
      00000002c0000000-00000002ffffffff (prio 0, ram): alias memslot-2 @mem2 0000000080000000-00000000bfffffff
  [...]

Without unmergable memory regions, all three memslots would get merged into
a single memory section. For example, when mapping another alias (e.g.,
virtio-mem-memslot-3) or when unmapping any of the mapped aliases,
memory listeners will first get notified about the removal of the big
memory section to then get notified about re-adding of the new
(differently merged) memory section(s).

In an ideal world, memory listeners would be able to deal with that
atomically, like KVM nowadays does. However, (a) supporting this for other
memory listeners (vhost-user, vfio) is fairly hard: temporary removal
can result in all kinds of issues on concurrent access to guest memory;
and (b) this handling is undesired, because temporarily removing+readding
can consume quite some time on bigger memslots and is not efficient
(e.g., vfio unpinning and repinning pages ...).

Let's allow for marking a memory region unmergeable, such that we
can atomically (un)map aliases to the same memory region, similar to
(un)mapping individual DIMMs.

Similarly, teach vhost code to not redo what flatview core stopped doing:
don't merge such sections. Merging in vhost code is really only relevant
for handling random holes in boot memory where; without this merging,
the vhost-user backend wouldn't be able to mmap() some boot memory
backed on hugetlb.

We'll use this for virtio-mem next.

Message-ID: <20230926185738.277351-18-david@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      533f5d66
    • David Hildenbrand's avatar
      memory: Clarify mapping requirements for RamDiscardManager · aa5317ef
      David Hildenbrand authored 
      
We really only care about the RAM memory region not being mapped into
an address space yet as long as we're still setting up the
RamDiscardManager. Once mapped into an address space, memory notifiers
would get notified about such a region and any attempts to modify the
RamDiscardManager would be wrong.

While "mapped into an address space" is easy to check for RAM regions that
are mapped directly (following the ->container links), it's harder to
check when such regions are mapped indirectly via aliases. For now, we can
only detect that a region is mapped through an alias (->mapped_via_alias),
but we don't have a handle on these aliases to follow all their ->container
links to test if they are eventually mapped into an address space.

So relax the assertion in memory_region_set_ram_discard_manager(),
remove the check in memory_region_get_ram_discard_manager() and clarify
the doc.

Message-ID: <20230926185738.277351-14-david@redhat.com>
Reviewed-by: default avatarMaciej S. Szmigiero <maciej.szmigiero@oracle.com>
Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      aa5317ef
    • David Hildenbrand's avatar
      softmmu/physmem: Fixup qemu_ram_block_from_host() documentation · 022f033b
      David Hildenbrand authored 
      
Let's fixup the documentation (e.g., removing traces of the ram_addr
parameter that no longer exists) and move it to the header file while at
it.

Message-ID: <20230926185738.277351-4-david@redhat.com>
Suggested-by: default avatarIgor Mammedov <imammedo@redhat.com>
Acked-by: default avatarIgor Mammedov <imammedo@redhat.com>
Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      022f033b
    • Clément Chigot's avatar
      softmmu: pass the main loop status to gdb "Wxx" packet · 66bbe3e9
      Clément Chigot authored 
      
gdb_exit function aims to close gdb sessions and sends the exit code of
the current execution. It's being called by qemu_cleanup once the main
loop is over.
Until now, the exit code sent was always 0. Now that hardware can
shutdown this main loop with custom exit codes, these codes must be
transfered to gdb as well.

Signed-off-by: default avatarClément Chigot <chigot@adacore.com>
Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
Message-ID: <20231003071427.188697-3-chigot@adacore.com>
Signed-off-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      66bbe3e9
    • Clément Chigot's avatar
      softmmu: add means to pass an exit code when requesting a shutdown · 0386f39b
      Clément Chigot authored 
      
As of now, the exit code was either EXIT_FAILURE when a panic shutdown
was requested or EXIT_SUCCESS otherwise.
However, some hardware could want to pass more complex exit codes. Thus,
introduce a new shutdown request function allowing that.

Signed-off-by: default avatarClément Chigot <chigot@adacore.com>
Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
Message-ID: <20231003071427.188697-2-chigot@adacore.com>
Signed-off-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      0386f39b
  31. Oct 08, 2023