aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-05nbd/server: Support 64-bit block statusEric Blake
The NBD spec states that if the client negotiates extended headers, the server must avoid NBD_REPLY_TYPE_BLOCK_STATUS and instead use NBD_REPLY_TYPE_BLOCK_STATUS_EXT which supports 64-bit lengths, even if the reply does not need more than 32 bits. As of this patch, client->mode is still never NBD_MODE_EXTENDED, so the code added here does not take effect until the next patch enables negotiation. For now, all metacontexts that we know how to export never populate more than 32 bits of information, so we don't have to worry about NBD_REP_ERR_EXT_HEADER_REQD or filtering during handshake, and we always send all zeroes for the upper 32 bits of status during NBD_CMD_BLOCK_STATUS. Note that we previously had some interesting size-juggling on call chains, such as: nbd_co_send_block_status(uint32_t length) -> blockstatus_to_extents(uint32_t bytes) -> bdrv_block_status_above(bytes, &uint64_t num) -> nbd_extent_array_add(uint64_t num) -> store num in 32-bit length But we were lucky that it never overflowed: bdrv_block_status_above never sets num larger than bytes, and we had previously been capping 'bytes' at 32 bits (since the protocol does not allow sending a larger request without extended headers). This patch adds some assertions that ensure we continue to avoid overflowing 32 bits for a narrow client, while fully utilizing 64-bits all the way through when the client understands that. Even in 64-bit math, overflow is not an issue, because all lengths are coming from the block layer, and we know that the block layer does not support images larger than off_t (if lengths were coming from the network, the story would be different). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20230925192229.3186470-18-eblake@redhat.com>
2023-10-05nbd/server: Prepare to send extended header repliesEric Blake
Although extended mode is not yet enabled, once we do turn it on, we need to reply with extended headers to all messages. Update the low level entry points necessary so that all other callers automatically get the right header based on the current mode. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20230925192229.3186470-17-eblake@redhat.com>
2023-10-05nbd/server: Prepare to receive extended header requestsEric Blake
Although extended mode is not yet enabled, once we do turn it on, we need to accept extended requests for all messages. Previous patches have already taken care of supporting 64-bit lengths, now we just need to read it off the wire. Note that this implementation will block indefinitely on a buggy client that sends a non-extended payload (that is, we try to read a full packet before we ever check the magic number, but a client that mistakenly sends a simple request after negotiating extended headers doesn't send us enough bytes), but it's no different from any other client that stops talking to us partway through a packet and thus not worth coding around. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20230925192229.3186470-16-eblake@redhat.com>
2023-10-05nbd/server: Support a request payloadEric Blake
Upcoming additions to support NBD 64-bit effect lengths allow for the possibility to distinguish between payload length (capped at 32M) and effect length (64 bits, although we generally assume 63 bits because of off_t limitations). Without that extension, only the NBD_CMD_WRITE request has a payload; but with the extension, it makes sense to allow at least NBD_CMD_BLOCK_STATUS to have both a payload and effect length in a future patch (where the payload is a limited-size struct that in turn gives the real effect length as well as a subset of known ids for which status is requested). Other future NBD commands may also have a request payload, so the 64-bit extension introduces a new NBD_CMD_FLAG_PAYLOAD_LEN that distinguishes between whether the header length is a payload length or an effect length, rather than hard-coding the decision based on the command. According to the spec, a client should never send a command with a payload without the negotiation phase proving such extension is available. So in the unlikely event the bit is set or cleared incorrectly, the client is already at fault; if the client then provides the payload, we can gracefully consume it off the wire and fail the command with NBD_EINVAL (subsequent checks for magic numbers ensure we are still in sync), while if the client fails to send payload we block waiting for it (basically deadlocking our connection to the bad client, but not negatively impacting our ability to service other clients, so not a security risk). Note that we do not support the payload version of BLOCK_STATUS yet. This patch also fixes a latent bug introduced in b2578459: once request->len can be 64 bits, assigning it to a 32-bit payload_len can cause wraparound to 0 which then sets req->complete prematurely; thankfully, the bug was not possible back then (it takes this and later patches to even allow request->len larger than 32 bits; and since previously the only 'payload_len = request->len' assignment was in NBD_CMD_WRITE which also sets check_length, which in turn rejects lengths larger than 32M before relying on any possibly-truncated value stored in payload_len). Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20230925192229.3186470-15-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> [eblake: enhance comment on handling client error, fix type bug] Signed-off-by: Eric Blake <eblake@redhat.com>
2023-10-05mailmap: Fix BALATON Zoltan author emailEric Blake
This fixes authorship of commits 5cbd51a5 and friends, where the qemu-ppc mailing list rewrote the "From:" field in the corresponding patches. See commit 3bd2608db7 ("maint: Add .mailmap entries for patches claiming list authorship") for explanation. Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20230927143815.3397386-8-eblake@redhat.com>
2023-10-05maint: Tweak comments in mailmap regarding SPFEric Blake
Documenting that we should not add new lines to work around SPF rewrites sounds foreboding; the intent is instead that new lines here are okay, but indicate a second problem elsewhere in our build process that we should also consider fixing at the same time, to keep the section from growing without bounds. While we have been doing that for qemu-devel for a while, we jut recently fixed that for qemu-block: https://git.linaro.org/people/pmaydell/misc-scripts.git/commit/?id=f9a317392 Mentioning DMARC alongside SPF may also help people grep for this scenario, as well as documenting the 'git config' workaround that can be used by submitters to avoid the munging issue in the first place. Note the subtlety: 'git commit' sets authorship information based on user.name and user.email (where name is usually unquoted); while 'git send-email' includes a body 'From:' line only when sendemail.from is present but differs from authorship information. Hence the use of quotes in sendemail.from (not a semantic change to email, but enough of a difference to add the body 'From:'). Fixes: 3bd2608d ("maint: Add .mailmap entries for patches claiming list authorship") CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20230927143815.3397386-7-eblake@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-10-05mailmap: Fix Andrey Drobyshev author emailAndrey Drobyshev
This fixes authorship of commits 2848289168, 52b10c9c0c as the mailing list rewrote the "From:" field in the corresponding patches. See commit 3bd2608db7 ("maint: Add .mailmap entries for patches claiming list authorship") for explanation. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230926102801.512107-1-andrey.drobyshev@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Eric Blake <eblake@redhat.com>
2023-10-05Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Stefan Hajnoczi
into staging virtio,pci: features, cleanups vdpa: shadow vq vlan support net migration with cvq cxl: support emulating 4 HDM decoders serial number extended capability virtio: hared dma-buf Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (53 commits) libvhost-user: handle shared_object msg vhost-user: add shared_object msg hw/display: introduce virtio-dmabuf util/uuid: add a hash function virtio: remove unused next argument from virtqueue_split_read_next_desc() virtio: remove unnecessary thread fence while reading next descriptor virtio: use shadow_avail_idx while checking number of heads libvhost-user.c: add assertion to vu_message_read_default pcie_sriov: unregister_vfs(): fix error path hw/i386/pc: improve physical address space bound check for 32-bit x86 systems amd_iommu: Fix APIC address check vdpa net: follow VirtIO initialization properly at cvq isolation probing vdpa net: stop probing if cannot set features vdpa net: fix error message setting virtio status hw/pci-bridge/cxl-upstream: Add serial number extended capability support hw/cxl: Support 4 HDM decoders at all levels of topology hw/cxl: Fix and use same calculation for HDM decoder block size everywhere hw/cxl: Add utility functions decoder interleave ways and target count. hw/cxl: Push cxl_decoder_count_enc() and cxl_decode_ig() into .c vdpa net: zero vhost_vdpa iova_tree pointer at cleanup ... Conflicts: hw/core/machine.c Context conflict with commit 314e0a84cd5d ("hw/core: remove needless includes") because it removed an adjacent #include.
2023-10-05Merge tag 'pull-tcg-20231004' of https://gitlab.com/rth7680/qemu into stagingStefan Hajnoczi
accel: Introduce AccelClass::cpu_common_[un]realize accel: Target agnostic code movement accel/tcg: Cleanups to use CPUState instead of CPUArchState accel/tcg: Move CPUNegativeOffsetState into CPUState tcg: Split out tcg init functions to tcg/startup.h linux-user/hppa: Fix struct target_sigcontext layout build: Remove --enable-gprof # -----BEGIN PGP SIGNATURE----- # # iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmUdsL4dHHJpY2hhcmQu # aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/iYggAvDJEyMCAXSSH97BA # wZT/2D/MFIhOMk6xrQRnrXfrG70N0iVKz44jl9j7k1D+9BOHcso//DDJH3c96k9A # MgDb6W2bsWvC15/Qw6BALf5bb/II0MJuCcQvj3CNX5lNkXAWhwIOBhsZx7V9ST1+ # rihN4nowpRWdV5GeCjDGaJW455Y1gc96hICYHy6Eqw1cUgUFt9vm5aYU3FHlat29 # sYRaVYKUL2hRUPPNcPiPq0AaJ8wN6/s8gT+V1UvTzkhHqskoM4ZU89RchuXVoq1h # SvhKElyULMRzM7thWtpW8qYJPj4mxZsKArESvHjsunGD6KEz3Fh1sy6EKRcdmpG/ # II1vkg== # =k2Io # -----END PGP SIGNATURE----- # gpg: Signature made Wed 04 Oct 2023 14:36:46 EDT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * tag 'pull-tcg-20231004' of https://gitlab.com/rth7680/qemu: (47 commits) tcg/loongarch64: Fix buid error tests/avocado: Re-enable MIPS Malta tests (GitLab issue #1884 fixed) build: Remove --enable-gprof linux-user/hppa: Fix struct target_sigcontext layout tcg: Split out tcg init functions to tcg/startup.h tcg: Remove argument to tcg_prologue_init accel/tcg: Make cpu-exec-common.c a target agnostic unit accel/tcg: Make icount.o a target agnostic unit accel/tcg: Make monitor.c a target-agnostic unit accel/tcg: Rename target-specific 'internal.h' -> 'internal-target.h' exec: Rename target specific page-vary.c -> page-vary-target.c exec: Rename cpu.c -> cpu-target.c accel: Rename accel-common.c -> accel-target.c accel: Make accel-blocker.o target agnostic accel/tcg: Restrict dump_exec_info() declaration exec: Move cpu_loop_foo() target agnostic functions to 'cpu-common.h' exec: Make EXCP_FOO definitions target agnostic accel/tcg: move ld/st helpers to ldst_common.c.inc accel/tcg: Unify user and softmmu do_[st|ld]*_mmu() accel/tcg: Remove env_tlb() ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-04libvhost-user: handle shared_object msgAlbert Esteve
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the virtio shared objects hash table. Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-5-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vhost-user: add shared_object msgAlbert Esteve
Add three new vhost-user protocol `VHOST_USER_BACKEND_SHARED_OBJECT_* messages`. These new messages are sent from vhost-user back-ends to interact with the virtio-dmabuf table in order to add or remove themselves as virtio exporters, or lookup for virtio dma-buf shared objects. The action taken in the front-end depends on the type stored in the virtio shared object hash table. When the table holds a pointer to a vhost backend for a given UUID, the front-end sends a VHOST_USER_GET_SHARED_OBJECT to the backend holding the shared object. The messages can only be sent after successfully negotiating a new VHOST_USER_PROTOCOL_F_SHARED_OBJECT vhost-user protocol feature bit. Finally, refactor code to send response message so that all common parts both for the common REPLY_ACK case, and other data responses, can call it and avoid code repetition. Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-4-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/display: introduce virtio-dmabufAlbert Esteve
This API manages objects (in this iteration, dmabuf fds) that can be shared along different virtio devices, associated to a UUID. The API allows the different devices to add, remove and/or retrieve the objects by simply invoking the public functions that reside in the virtio-dmabuf file. For vhost backends, the API stores the pointer to the backend holding the object. Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-3-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04util/uuid: add a hash functionAlbert Esteve
Add hash function to uuid module using the djb2 hash algorithm. Add a couple simple unit tests for the hash function, checking collisions for similar UUIDs. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-2-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: remove unused next argument from virtqueue_split_read_next_desc()Ilya Maximets
The 'next' was converted from a local variable to an output parameter in commit: 412e0e81b174 ("virtio: handle virtqueue_read_next_desc() errors") But all the actual uses of the 'i/next' as an output were removed a few months prior in commit: aa570d6fb6bd ("virtio: combine the read of a descriptor") Remove the unused argument to simplify the code. Also, adding a comment to the function to describe what it is actually doing, as it is not obvious that the 'desc' is both an input and an output argument. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927140016.2317404-3-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: remove unnecessary thread fence while reading next descriptorIlya Maximets
It was supposed to be a compiler barrier and it was a compiler barrier initially called 'wmb' when virtio core support was introduced. Later all the instances of 'wmb' were switched to smp_wmb to fix memory ordering issues on non-x86 platforms. However, this one doesn't need to be an actual barrier, as its only purpose was to ensure that the value is not read twice. And since commit aa570d6fb6bd ("virtio: combine the read of a descriptor") there is no need for a barrier at all, since we're no longer reading guest memory here, but accessing a local structure. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927140016.2317404-2-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: use shadow_avail_idx while checking number of headsIlya Maximets
We do not need the most up to date number of heads, we only want to know if there is at least one. Use shadow variable as long as it is not equal to the last available index checked. This avoids expensive qatomic dereference of the RCU-protected memory region cache as well as the memory access itself. The change improves performance of the af-xdp network backend by 2-3%. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927135157.2316982-1-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04libvhost-user.c: add assertion to vu_message_read_defaultVladimir Sementsov-Ogievskiy
Explain Coverity that we are not going to overflow vmsg->fds. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230925194040.68592-5-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04pcie_sriov: unregister_vfs(): fix error pathVladimir Sementsov-Ogievskiy
local_err must be NULL before calling object_property_set_bool(), so we must clear it on each iteration. Let's also use more convenient error_reportf_err(). Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230925194040.68592-8-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/pc: improve physical address space bound check for 32-bit x86 systemsAni Sinha
32-bit x86 systems do not have a reserved memory for hole64. On those 32-bit systems without PSE36 or PAE CPU features, hotplugging memory devices are not supported by QEMU as QEMU always places hotplugged memory above 4 GiB boundary which is beyond the physical address space of the processor. Linux guests also does not support memory hotplug on those systems. Please see Linux kernel commit b59d02ed08690 ("mm/memory_hotplug: disable the functionality for 32b") for more details. Therefore, the maximum limit of the guest physical address in the absence of additional memory devices effectively coincides with the end of "above 4G memory space" region for 32-bit x86 without PAE/PSE36. When users configure additional memory devices, after properly accounting for the additional device memory region to find the maximum value of the guest physical address, the address will be outside the range of the processor's physical address space. This change adds improvements to take above into consideration. For example, previously this was allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G With this change now it is no longer allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G qemu-system-x86_64: Address space limit 0xffffffff < 0x2bfffffff phys-bits too low (32) However, the following are allowed since on both cases physical address space of the processor is 36 bits: $ ./qemu-system-x86_64 -cpu pentium2 -m size=10G $ ./qemu-system-x86_64 -cpu pentium,pse36=on -m size=10G For 32-bit, without PAE/PSE36, hotplugging additional memory is no longer allowed. $ ./qemu-system-i386 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) $ ./qemu-system-i386 -machine q35 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) A new compatibility flag is introduced to make sure pc_max_used_gpa() keeps returning the old value for machines 8.1 and older. Therefore, the above is still allowed for older machine types in order to support compatibility. Hence, the following still works: $ ./qemu-system-i386 -machine pc-i440fx-8.1 -m size=1G,maxmem=3G,slots=2 $ ./qemu-system-i386 -machine pc-q35-8.1 -m size=1G,maxmem=3G,slots=2 Further, following is also allowed as with PSE36, the processor has 36-bit address space: $ ./qemu-system-i386 -cpu 486,pse36=on -m size=1G,maxmem=3G,slots=2 After calling CPUID with EAX=0x80000001, all AMD64 compliant processors have the longmode-capable-bit turned on in the extended feature flags (bit 29) in EDX. The absence of CPUID longmode can be used to differentiate between 32-bit and 64-bit processors and is the recommended approach. QEMU takes this approach elsewhere (for example, please see x86_cpu_realizefn()), With this change, pc_max_used_gpa() also uses the same method to detect 32-bit processors. Unit tests are modified to not run 32-bit x86 tests that use memory hotplug. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20230922160413.165702-1-anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04amd_iommu: Fix APIC address checkAkihiko Odaki
An MSI from I/O APIC may not exactly equal to APIC_DEFAULT_ADDRESS. In fact, Windows 17763.3650 configures I/O APIC to set the dest_mode bit. Cover the range assigned to APIC. Fixes: 577c470f43 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230921114612.40671-1-akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa net: follow VirtIO initialization properly at cvq isolation probingEugenio Pérez
This patch solves a few issues. The most obvious is that the feature set was done previous to ACKNOWLEDGE | DRIVER status bit set. Current vdpa devices are permissive with this, but it is better to follow the standard. Fixes: 152128d646 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230915170836.3078172-4-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa net: stop probing if cannot set featuresEugenio Pérez
Otherwise it continues the CVQ isolation probing. Fixes: 152128d646 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230915170836.3078172-3-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-10-04vdpa net: fix error message setting virtio statusEugenio Pérez
It incorrectly prints "error setting features", probably because a copy paste miss. Fixes: 152128d646 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230915170836.3078172-2-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-10-04hw/pci-bridge/cxl-upstream: Add serial number extended capability supportJonathan Cameron
Will be needed so there is a defined serial number for information queries via the Switch CCI. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913133615.29876-1-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Support 4 HDM decoders at all levels of topologyJonathan Cameron
Support these decoders in CXL host bridges (pxb-cxl), CXL Switch USP and CXL Type 3 end points. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Fix and use same calculation for HDM decoder block size everywhereJonathan Cameron
In order to avoid having the size of the per HDM decoder register block repeated in lots of places, create the register definitions for HDM decoder 1 and use the offset between the first registers in HDM decoder 0 and HDM decoder 1 to establish the offset. Calculate in each function as this is more obvious and leads to shorter line lengths than a single #define which would need a long name to be specific enough. Note that the code currently only supports one decoder, so the bugs this fixes don't actually affect anything. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230913132523.29780-4-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Add utility functions decoder interleave ways and target count.Jonathan Cameron
As an encoded version of these key configuration parameters is available in a register, provide functions to extract it again so as to avoid the need for duplicating the storage. Whilst here update the _enc() function to include additional values as defined in the CXL 3.0 specification. Whilst they are not currently used in the emulation, they may be in future and it is easier to compare with the specification if all values are covered. Add a spec reference for cxl_interleave_ways_enc() for consistency with the target count equivalent (and because it's nice to know where the magic numbers come from). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Push cxl_decoder_count_enc() and cxl_decode_ig() into .cJonathan Cameron
There is no strong justification for keeping these in the header so push them down into the associated cxl-component-utils.c file. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa net: zero vhost_vdpa iova_tree pointer at cleanupEugenio Pérez
Not zeroing it causes a SIGSEGV if the live migration is cancelled, at net device restart. This is caused because CVQ tries to reuse the iova_tree that is present in the first vhost_vdpa device at the end of vhost_vdpa_net_cvq_start. As a consequence, it tries to access an iova_tree that has been already free. Fixes: 00ef422e9fbf ("vdpa net: move iova tree creation from init to start") Reported-by: Yanhui Ma <yama@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230913123408.2819185-1-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa: fix gcc cvq_isolated uninitialized variable warningStefan Hajnoczi
gcc 13.2.1 emits the following warning: net/vhost-vdpa.c: In function ‘net_vhost_vdpa_init.constprop’: net/vhost-vdpa.c:1394:25: error: ‘cvq_isolated’ may be used uninitialized [-Werror=maybe-uninitialized] 1394 | s->cvq_isolated = cvq_isolated; | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ net/vhost-vdpa.c:1355:9: note: ‘cvq_isolated’ was declared here 1355 | int cvq_isolated; | ^~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Eugenio Pérez <eperezma@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230911215435.4156314-1-stefanha@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/core: Trace enable and status registers of GPE separatelyBernhard Beschow
The bit positions of both registers are related. Tracing the registers independently results in the same offsets across these registers which eases debugging. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-9-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi: Trace GPE access in all device models, not just PIIX4Bernhard Beschow
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-8-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/acpi-build: Determine SMI command port just onceBernhard Beschow
The SMI command port is currently hardcoded by means of the ACPI_PORT_SMI_CMD macro. This hardcoding is Intel specific and doesn't match VIA, for example. There is already the AcpiFadtData::smi_cmd attribute which is used when building the FADT. Let's also use it when building the DSDT which confines SMI command port determination to just one place. This allows it to become a property later, thus resolving the Intel assumption. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386: Remove now redundant TYPE_ACPI_GED_X86Bernhard Beschow
Now that TYPE_ACPI_GED_X86 doesn't assign AcpiDeviceIfClass::madt_cpu any more it is the same as TYPE_ACPI_GED. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/acpi_dev_interface: Remove now unused #include "hw/boards.h"Bernhard Beschow
The "hw/boards.h" is unused since the previous commit. Since its removal requires include fixes in various unrelated files to keep the code compiling it has been split in a dedicated commit. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/acpi_dev_interface: Remove now unused madt_cpu virtual methodBernhard Beschow
This virtual method was always set to the x86-specific pc_madt_cpu_entry(), even in piix4 which is also used in MIPS. The previous changes use pc_madt_cpu_entry() otherwise, so madt_cpu can be dropped. Since pc_madt_cpu_entry() is now only used in x86-specific code, the stub in hw/acpi/acpi-x86-stub can be removed as well. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/cpu: Have build_cpus_aml() take a build_madt_cpu_fn callbackBernhard Beschow
build_cpus_aml() is architecture independent but needs to create architecture- specific CPU AML. So far this was achieved by using a virtual method from TYPE_ACPI_DEVICE_IF. However, build_cpus_aml() would resolve this interface from global (!) state. This makes it quite incomprehensible where this interface comes from (TYPE_PIIX4_PM?, TYPE_ICH9_LPC_DEVICE?, TYPE_ACPI_GED_X86?) an can lead to crashes when the generic code is ported to new architectures. So far, build_cpus_aml() is only called in architecture-specific code -- and only in x86. We can therefore simply pass pc_madt_cpu_entry() as callback to build_cpus_aml(). This is the same callback that would be used through TYPE_ACPI_DEVICE_IF. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/acpi-build: Use pc_madt_cpu_entry() directlyBernhard Beschow
This is x86-specific code, so there is no advantage in using pc_madt_cpu_entry() behind an architecture-agnostic interface. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04tcg/loongarch64: Fix buid errorgaosong
Fix: In file included from ../tcg/tcg.c:735: /home1/gaosong/bugfix/qemu/tcg/loongarch64/tcg-target.c.inc: In function ‘tcg_out_vec_op’: /home1/gaosong/bugfix/qemu/tcg/loongarch64/tcg-target.c.inc:1855:9: error: a label can only be part of a statement and a declaration is not a statement TCGCond cond = args[3]; ^~~~~~~ Signed-off-by: gaosong <gaosong@loongson.cn> Message-Id: <20230926075819.3602537-1-gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04tests/avocado: Re-enable MIPS Malta tests (GitLab issue #1884 fixed)Philippe Mathieu-Daudé
Commit 18a536f1f8 ("accel/tcg: Always require can_do_io") fixed the GitLab issue #1884: we can now re-enable those tests. This reverts commit f959c3d87ccfa585b105de6964a6261e368cc1da. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231003063808.66564-1-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04build: Remove --enable-gprofRichard Henderson
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF. Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04linux-user/hppa: Fix struct target_sigcontext layoutRichard Henderson
Use abi_ullong not uint64_t so that the alignment of the field and therefore the layout of the struct is correct. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04tcg: Split out tcg init functions to tcg/startup.hRichard Henderson
The tcg/tcg.h header is a big bucket, containing stuff related to the translators and the JIT backend. The places that initialize tcg or create new threads do not need all of that, so split out these three functions to a new header. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04tcg: Remove argument to tcg_prologue_initRichard Henderson
We can load tcg_ctx just as easily within the callee. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04accel/tcg: Make cpu-exec-common.c a target agnostic unitPhilippe Mathieu-Daudé
cpu_in_serial_context() is not target specific, move it declaration to "internal-common.h" (which we include in the 4 source files modified). Remove the unused "exec/exec-all.h" header from cpu-exec-common.c. There is no more target specific code in this file: make it target agnostic. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-12-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04accel/tcg: Make icount.o a target agnostic unitPhilippe Mathieu-Daudé
Remove the unused "exec/exec-all.h" header. There is no more target specific code in it: make it target agnostic (rename using the '-common' suffix). Since it is TCG specific, move it to accel/tcg, updating MAINTAINERS. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-11-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04accel/tcg: Make monitor.c a target-agnostic unitPhilippe Mathieu-Daudé
Move target-agnostic declarations from "internal-target.h" to a new "internal-common.h" header. monitor.c now don't include target specific headers and can be compiled once in system_ss[]. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-10-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04accel/tcg: Rename target-specific 'internal.h' -> 'internal-target.h'Philippe Mathieu-Daudé
accel/tcg/internal.h contains target specific declarations. Unit files including it become "target tainted": they can not be compiled as target agnostic. Rename using the '-target' suffix to make this explicit. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-9-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04exec: Rename target specific page-vary.c -> page-vary-target.cPhilippe Mathieu-Daudé
This matches the target agnostic 'page-vary-common.c' counterpart. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-8-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04exec: Rename cpu.c -> cpu-target.cPhilippe Mathieu-Daudé
We have exec/cpu code split in 2 files for target agnostic ("common") and specific. Rename 'cpu.c' which is target specific using the '-target' suffix. Update MAINTAINERS. Remove the 's from 'cpus-common.c' to match the API cpu_foo() functions. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Message-Id: <20230914185718.76241-7-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-01 06:45:17 +0000