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 04, 2021
    • Paolo Bonzini's avatar
      ratelimit: protect with a mutex · 4951967d
      Paolo Bonzini authored 
      
Right now, rate limiting is protected by the AioContext mutex, which is
taken for example both by the block jobs and by qmp_block_job_set_speed
(via find_block_job).

We would like to remove the dependency of block layer code on the
AioContext mutex, since most drivers and the core I/O code are already
not relying on it.  However, there is no existing lock that can easily
be taken by both ratelimit_set_speed and ratelimit_calculate_delay,
especially because the latter might run in coroutine context (and
therefore under a CoMutex) but the former will not.

Since concurrent calls to ratelimit_calculate_delay are not possible,
one idea could be to use a seqlock to get a snapshot of slice_ns and
slice_quota.  But for now keep it simple, and just add a mutex to the
RateLimit struct; block jobs are generally not performance critical to
the point of optimizing the clock cycles spent in synchronization.

This also requires the introduction of init/destroy functions, so
add them to the two users of ratelimit.h.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4951967d
    • Reinoud Zandijk's avatar
      Add NVMM accelerator: acceleration enlightenments · b9bc6169
      Reinoud Zandijk authored 
      
Signed-off-by: default avatarKamil Rytarowski <kamil@NetBSD.org>
Signed-off-by: default avatarReinoud Zandijk <reinoud@NetBSD.org>

Message-Id: <20210402202535.11550-4-reinoud@NetBSD.org>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b9bc6169
  3. May 01, 2021
    • Philippe Mathieu-Daudé's avatar
      exec: Remove accel/tcg/ from include paths · db647703
      Philippe Mathieu-Daudé authored 
      
When TCG is enabled, the accel/tcg/ include path is added to the
project global include search list. This accel/tcg/ directory
contains a header named "internal.h" which, while intented to
be internal to accel/tcg/, is accessible by all files compiled
when TCG is enabled. This might lead to problem with other
directories using the same "internal.h" header name:

  $ git ls-files | fgrep /internal.h
  accel/tcg/internal.h
  include/hw/ide/internal.h
  target/hexagon/internal.h
  target/mips/internal.h
  target/ppc/internal.h
  target/s390x/internal.h

As we don't need to expose accel/tcg/ internals to the rest of
the code base, simplify by removing it from the include search
list, and include the accel/tcg/ public headers relative to the
project root search path (which is already in the generic include
search path).

Signed-off-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: default avatarClaudio Fontana <cfontana@suse.de>
Message-Id: <20210413081008.3409459-1-f4bug@amsat.org>
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      db647703
  5. Apr 30, 2021
  7. Apr 23, 2021
  9. Apr 17, 2021
  11. Apr 12, 2021
  13. Apr 08, 2021
  15. Apr 07, 2021
    • Klaus Jensen's avatar
      hw/block/nvme: fix handling of private namespaces · e5489356
      Klaus Jensen authored 
      
Prior to this patch, if a private nvme-ns device (that is, a namespace
that is not linked to a subsystem) is wired up to an nvme-subsys linked
nvme controller device, the device fails to verify that the namespace id
is unique within the subsystem. NVM Express v1.4b, Section 6.1.6 ("NSID
and Namespace Usage") states that because the device supports Namespace
Management, "NSIDs *shall* be unique within the NVM subsystem".

Additionally, prior to this patch, private namespaces are not known to
the subsystem and the namespace is considered exclusive to the
controller with which it is initially wired up to. However, this is not
the definition of a private namespace; per Section 1.6.33 ("private
namespace"), a private namespace is just a namespace that does not
support multipath I/O or namespace sharing, which means "that it is only
able to be attached to one controller at a time".

Fix this by always allocating namespaces in the subsystem (if one is
linked to the controller), regardless of the shared/private status of
the namespace. Whether or not the namespace is shareable is controlled
by a new `shared` nvme-ns parameter.

Finally, this fix allows the nvme-ns `subsys` parameter to be removed,
since the `shared` parameter now serves the purpose of attaching the
namespace to all controllers in the subsystem upon device realization.
It is invalid to have an nvme-ns namespace device with a linked
subsystem without the parent nvme controller device also being linked to
one and since the nvme-ns devices will unconditionally be "attached" (in
QEMU terms that is) to an nvme controller device through an NvmeBus, the
nvme-ns namespace device can always get a reference to the subsystem of
the controller it is explicitly (using 'bus=' parameter) or implicitly
attaching to.

Fixes: e5707685 ("hw/block/nvme: support for shared namespace in subsystem")
Cc: Minwoo Im <minwoo.im.dev@gmail.com>
Signed-off-by: default avatarKlaus Jensen <k.jensen@samsung.com>
Reviewed-by: default avatarGollu Appalanaidu <anaidu.gollu@samsung.com>
Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
Reviewed-by: default avatarMinwoo Im <minwoo.im.dev@gmail.com>
      e5489356
  17. Apr 06, 2021
  19. Apr 04, 2021
  21. Apr 01, 2021
    • Lukas Straub's avatar
      chardev: Fix yank with the chardev-change case · feb774ca
      Lukas Straub authored 
      
When changing from chardev-socket (which supports yank) to
chardev-socket again, it fails, because the new chardev attempts
to register a new yank instance. This in turn fails, as there
still is the yank instance from the current chardev. Also,
the old chardev shouldn't unregister the yank instance when it
is freed.

To fix this, now the new chardev only registers a yank instance if
the current chardev doesn't support yank and thus hasn't registered
one already. Also, when the old chardev is freed, it now only
unregisters the yank instance if the new chardev doesn't need it.

If the initialization of the new chardev fails, it still has
chr->handover_yank_instance set and won't unregister the yank
instance when it is freed.

s->registered_yank is always true here, as chardev-change only works
on user-visible chardevs and those are guraranteed to register a
yank instance as they are initialized via
chardev_new()
 qemu_char_open()
  cc->open() (qmp_chardev_open_socket()).

Signed-off-by: default avatarLukas Straub <lukasstraub2@web.de>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: default avatarLi Zhang <li.zhang@cloud.ionos.com>
Message-Id: <9637888d7591d2971975188478bb707299a1dc04.1617127849.git.lukasstraub2@web.de>
      feb774ca
    • Lukas Straub's avatar
      yank: Remove dependency on qiochannel · 1a92d6d5
      Lukas Straub authored 
      
Remove dependency on qiochannel by removing yank_generic_iochannel and
letting migration and chardev use their own yank function for
iochannel.

Signed-off-by: default avatarLukas Straub <lukasstraub2@web.de>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20ff143fc2db23e27cd41d38043e481376c9cec1.1616521341.git.lukasstraub2@web.de>
      1a92d6d5
  23. Mar 31, 2021
    • Paolo Bonzini's avatar
      coroutine-lock: Reimplement CoRwlock to fix downgrade bug · 050de36b
      Paolo Bonzini authored 
      
An invariant of the current rwlock is that if multiple coroutines hold a
reader lock, all must be runnable. The unlock implementation relies on
this, choosing to wake a single coroutine when the final read lock
holder exits the critical section, assuming that it will wake a
coroutine attempting to acquire a write lock.

The downgrade implementation violates this assumption by creating a
read lock owning coroutine that is exclusively runnable - any other
coroutines that are waiting to acquire a read lock are *not* made
runnable when the write lock holder converts its ownership to read
only.

More in general, the old implementation had lots of other fairness bugs.
The root cause of the bugs was that CoQueue would wake up readers even
if there were pending writers, and would wake up writers even if there
were readers.  In that case, the coroutine would go back to sleep *at
the end* of the CoQueue, losing its place at the head of the line.

To fix this, keep the queue of waiters explicitly in the CoRwlock
instead of using CoQueue, and store for each whether it is a
potential reader or a writer.  This way, downgrade can look at the
first queued coroutines and wake it only if it is a reader, causing
all other readers in line to be released in turn.

Reported-by: default avatarDavid Edmondson <david.edmondson@oracle.com>
Reviewed-by: default avatarDavid Edmondson <david.edmondson@oracle.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Message-id: 20210325112941.365238-5-pbonzini@redhat.com
Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      050de36b
    • Alexey Kardashevskiy's avatar
      spapr: Fix typo in the patb_entry comment · a40888ba
      Alexey Kardashevskiy authored 
      
There is no H_REGISTER_PROCESS_TABLE, it is H_REGISTER_PROC_TBL handler
for which is still called h_register_process_table() though.

Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
Message-Id: <20210225032335.64245-1-aik@ozlabs.ru>
Reviewed-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      a40888ba
  25. Mar 26, 2021
  27. Mar 24, 2021
    • Laurent Vivier's avatar
      m68k: add the virtio devices aliases · 4c5806a5
      Laurent Vivier authored 
      
Similarly to 5f629d94 ("s390x: fix s390 virtio aliases"),
define the virtio aliases.

This allows to start machines with virtio devices without
knowledge of the implementation type.

For instance, we can use "-device virtio-scsi" on
m68k, s390x or PC, and the device will be respectively
"virtio-scsi-device", "virtio-scsi-ccw" or "virtio-scsi-pci".

This already exists for s390x and -ccw interfaces, add them
for m68k and MMIO (-device) interfaces.

Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
Message-Id: <20210319202335.2397060-3-laurent@vivier.eu>
Message-Id: <20210323165308.15244-18-alex.bennee@linaro.org>
      4c5806a5
    • Laurent Vivier's avatar
      qdev: define list of archs with virtio-pci or virtio-ccw · 203adb43
      Laurent Vivier authored 
      
This is used to define virtio-*-pci and virtio-*-ccw aliases
rather than substracting the CCW architecture from all the others.

Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
Message-Id: <20210319202335.2397060-2-laurent@vivier.eu>
Message-Id: <20210323165308.15244-17-alex.bennee@linaro.org>
      203adb43
    • Richard Henderson's avatar
      exec: Build page-vary-common.c with -fno-lto · 44b99a6d
      Richard Henderson authored 
      
In bbc17caf, we used an alias attribute to allow target_page
to be declared const, and yet be initialized late.

This fails when using LTO with several versions of gcc.
The compiler looks through the alias and decides that the const
variable is statically initialized to zero, then propagates that
zero to many uses of the variable.

This can be avoided by compiling one object file with -fno-lto.
In this way, any initializer cannot be seen, and the constant
propagation does not occur.

Since we are certain to have this separate compilation unit, we
can drop the alias attribute as well.  We simply have differing
declarations for target_page in different compilation units.
Drop the use of init_target_page, and drop the configure detection
for CONFIG_ATTRIBUTE_ALIAS.

In order to change the compilation flags for a file with meson,
we must use a static_library.  This runs into specific_ss, where
we would need to create many static_library instances.

Fix this by splitting page-vary.c: the page-vary-common.c part is
compiled once as a static_library, while the page-vary.c part is
left in specific_ss in order to handle the target-specific value
of TARGET_PAGE_BITS_MIN.

Reported-by: default avatarGavin Shan <gshan@redhat.com>
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-Id: <20210321211534.2101231-1-richard.henderson@linaro.org>
[PMD: Fix typo in subject, split original patch in 3]
Signed-off-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: default avatarGavin Shan <gshan@redhat.com>
Message-Id: <20210322112427.4045204-4-f4bug@amsat.org>
[rth: Update MAINTAINERS]
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      44b99a6d
    • Richard Henderson's avatar
      exec: Extract 'page-vary.h' header · 27eb9d65
      Richard Henderson authored 
      
In the next commit we will extract the generic code out of
page-vary.c, only keeping the target specific code. Both
files will use the same TargetPageBits structure, so make
its declaration in a shared header.

As the common header can not use target specific types,
use a uint64_t to hold the page mask value, and add a
cast back to target_long in the TARGET_PAGE_MASK definitions.

Signed-off-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210322112427.4045204-3-f4bug@amsat.org>
Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      27eb9d65
  29. Mar 23, 2021
    • Peter Maydell's avatar
      hw/core/loader: Add new function rom_ptr_for_as() · 1228c459
      Peter Maydell authored 
      
For accesses to rom blob data before or during reset, we have a
function rom_ptr() which looks for a rom blob that would be loaded to
the specified address, and returns a pointer into the rom blob data
corresponding to that address.  This allows board or CPU code to say
"what is the data that is going to be loaded to this address?".

However, this function does not take account of memory region
aliases.  If for instance a machine model has RAM at address
0x0000_0000 which is aliased to also appear at 0x1000_0000, a
rom_ptr() query for address 0x0000_0000 will only return a match if
the guest image provided by the user was loaded at 0x0000_0000 and
not if it was loaded at 0x1000_0000, even though they are the same
RAM and a run-time guest CPU read of 0x0000_0000 will read the data
loaded to 0x1000_0000.

Provide a new function rom_ptr_for_as() which takes an AddressSpace
argument, so that it can check whether the MemoryRegion corresponding
to the address is also mapped anywhere else in the AddressSpace and
look for rom blobs that loaded to that alias.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20210318174823.18066-5-peter.maydell@linaro.org
      1228c459