qemu.git
14 months agoexec/ioport: Add portio_list_set_address()
Bernhard Beschow [Sun, 14 Jan 2024 12:39:05 +0000 (13:39 +0100)]
exec/ioport: Add portio_list_set_address()

Some SuperI/O devices such as the VIA south bridges or the PC87312 controller
are able to relocate their SuperI/O functions. Add a convenience function for
implementing this in the VIA south bridges.

This convenience function relies on previous simplifications in exec/ioport
which avoids some duplicate synchronization of I/O port base addresses. The
naming of the function is inspired by its memory_region_set_address() pendant.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-Id: <20240114123911.4877-6-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoexec/ioport: Resolve redundant .base attribute in struct MemoryRegionPortio
Bernhard Beschow [Sun, 14 Jan 2024 12:39:04 +0000 (13:39 +0100)]
exec/ioport: Resolve redundant .base attribute in struct MemoryRegionPortio

portio_list_add_1() creates a MemoryRegionPortioList instance which holds a
MemoryRegion `mr` and an array of MemoryRegionPortio elements named `ports`.
Each element in the array gets assigned the same value for its .base attribute.
The same value also ends up as the .addr attribute of `mr` due to the
memory_region_add_subregion() call. This means that all .base attributes are
the same as `mr.addr`.

The only usages of MemoryRegionPortio::base were in portio_read() and
portio_write(). Both functions get above MemoryRegionPortioList as their
opaque parameter. In both cases find_portio() can only return one of the
MemoryRegionPortio elements of the `ports` array. Due to above observation any
element will have the same .base value equal to `mr.addr` which is also
accessible.

Hence, `mrpio->mr.addr` is equivalent to `mrp->base` and
MemoryRegionPortio::base is redundant and can be removed.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-Id: <20240114123911.4877-5-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/char/parallel: Move portio_list from ParallelState to ISAParallelState
Bernhard Beschow [Sun, 14 Jan 2024 12:39:03 +0000 (13:39 +0100)]
hw/char/parallel: Move portio_list from ParallelState to ISAParallelState

ParallelState::portio_list isn't used inside ParallelState context but only
inside ISAParallelState context, so move it there.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <20240114123911.4877-4-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/block/fdc-sysbus: Move iomem from FDCtrl to FDCtrlSysBus
Bernhard Beschow [Sun, 14 Jan 2024 12:39:02 +0000 (13:39 +0100)]
hw/block/fdc-sysbus: Move iomem from FDCtrl to FDCtrlSysBus

FDCtrl::iomem isn't used inside FDCtrl context but only inside FDCtrlSysBus
context, so move it there.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <20240114123911.4877-3-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/block/fdc-isa: Move portio_list from FDCtrl to FDCtrlISABus
Bernhard Beschow [Sun, 14 Jan 2024 12:39:01 +0000 (13:39 +0100)]
hw/block/fdc-isa: Move portio_list from FDCtrl to FDCtrlISABus

FDCtrl::portio_list isn't used inside FDCtrl context but only inside
FDCtrlISABus context, so move it there.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <20240114123911.4877-2-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agotarget/i386/cpu: Fix typo in comment
Bernhard Beschow [Sat, 6 Jan 2024 13:25:46 +0000 (14:25 +0100)]
target/i386/cpu: Fix typo in comment

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240106132546.21248-4-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/i386/x86: Fix PIC interrupt handling if APIC is globally disabled
Bernhard Beschow [Sat, 6 Jan 2024 13:25:45 +0000 (14:25 +0100)]
hw/i386/x86: Fix PIC interrupt handling if APIC is globally disabled

QEMU populates the apic_state attribute of x86 CPUs if supported by real
hardware or if SMP is active. When handling interrupts, it just checks whether
apic_state is populated to route the interrupt to the PIC or to the APIC.
However, chapter 10.4.3 of [1] requires that:

  When IA32_APIC_BASE[11] is 0, the processor is functionally equivalent to an
  IA-32 processor without an on-chip APIC.

This means that when apic_state is populated, QEMU needs to check for the
MSR_IA32_APICBASE_ENABLE flag in addition. Implement this which fixes some
real-world BIOSes.

[1] Intel 64 and IA-32 Architectures Software Developer's Manual, Vol. 3A:
    System Programming Guide, Part 1

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-Id: <20240106132546.21248-3-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/i386/x86: Reverse if statement
Bernhard Beschow [Sat, 6 Jan 2024 13:25:44 +0000 (14:25 +0100)]
hw/i386/x86: Reverse if statement

The if statement currently uses double negation when executing the else branch.
So swap the branches and simplify the condition to make the code more
comprehensible.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-Id: <20240106132546.21248-2-shentey@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agotest: bios-tables-test: add IVRS changed binary
Bui Quang Minh [Thu, 11 Jan 2024 15:44:04 +0000 (22:44 +0700)]
test: bios-tables-test: add IVRS changed binary

Following the instructions in bios-tables-test, this adds the changed
IVRS.ivrs binary.

New IVRS differs in length, checksum, it enables EFRSup in Virtualization
Info and adds IVHD type 0x11 with the same device entries as in IVHD type
0x10.

ASL diff:

 /*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20230628 (64-bit version)
  * Copyright (c) 2000 - 2023 Intel Corporation
  *
- * Disassembly of tests/data/acpi/q35/IVRS.ivrs, Wed Nov  8 21:39:58 2023
+ * Disassembly of /tmp/aml-2ODND2, Wed Nov  8 21:39:58 2023
  *
  * ACPI Data Table [IVRS]
  *
  * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue (in hex)
  */

 [000h 0000 004h]                   Signature : "IVRS"    [I/O Virtualization Reporting Structure]
-[004h 0004 004h]                Table Length : 00000068
+[004h 0004 004h]                Table Length : 000000B0
 [008h 0008 001h]                    Revision : 01
-[009h 0009 001h]                    Checksum : 43
+[009h 0009 001h]                    Checksum : 74
 [00Ah 0010 006h]                      Oem ID : "BOCHS "
 [010h 0016 008h]                Oem Table ID : "BXPC    "
 [018h 0024 004h]                Oem Revision : 00000001
 [01Ch 0028 004h]             Asl Compiler ID : "BXPC"
 [020h 0032 004h]       Asl Compiler Revision : 00000001

-[024h 0036 004h]         Virtualization Info : 00002800
+[024h 0036 004h]         Virtualization Info : 00002801
 [028h 0040 008h]                    Reserved : 0000000000000000

 [030h 0048 001h]               Subtable Type : 10 [Hardware Definition Block (IVHD)]
 [031h 0049 001h]       Flags (decoded below) : D1
                                      HtTunEn : 1
                                       PassPW : 0
                                    ResPassPW : 0
                                 Isoc Control : 0
                                Iotlb Support : 1
                                     Coherent : 0
                             Prefetch Support : 1
                                  PPR Support : 1
 [032h 0050 002h]                      Length : 0038
 [034h 0052 002h]                    DeviceId : 0010
 [036h 0054 002h]           Capability Offset : 0040
 [038h 0056 008h]                Base Address : 00000000FED80000
@@ -108,25 +108,129 @@
                                   LINT1 Pass : 0

 [060h 0096 001h]               Subtable Type : 48 [Device Entry: Special Device]
 [061h 0097 002h]                   Device ID : 0000
 [063h 0099 001h] Data Setting (decoded below) : 00
                                     INITPass : 0
                                     EIntPass : 0
                                      NMIPass : 0
                                     Reserved : 0
                                  System MGMT : 0
                                   LINT0 Pass : 0
                                   LINT1 Pass : 0
 [064h 0100 001h]                      Handle : 00
 [065h 0101 002h]       Source Used Device ID : 00A0
 [067h 0103 001h]                     Variety : 01

-Raw Table Data: Length 104 (0x68)
+[068h 0104 001h]               Subtable Type : 11 [Hardware Definition Block (IVHD)]
+[069h 0105 001h]       Flags (decoded below) : 11
+                                     HtTunEn : 1
+                                      PassPW : 0
+                                   ResPassPW : 0
+                                Isoc Control : 0
+                               Iotlb Support : 1
+                                    Coherent : 0
+                            Prefetch Support : 0
+                                 PPR Support : 0
+[06Ah 0106 002h]                      Length : 0048
+[06Ch 0108 002h]                    DeviceId : 0010
+[06Eh 0110 002h]           Capability Offset : 0040
+[070h 0112 008h]                Base Address : 00000000FED80000
+[078h 0120 002h]           PCI Segment Group : 0000
+[07Ah 0122 002h]         Virtualization Info : 0000
+[07Ch 0124 004h]                  Attributes : 00000000
+[080h 0128 008h]                   EFR Image : 00000000000029D3
+[088h 0136 008h]                    Reserved : 0000000000000000
+
+[090h 0144 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[091h 0145 002h]                   Device ID : 0000
+[093h 0147 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[094h 0148 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[095h 0149 002h]                   Device ID : 0008
+[097h 0151 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[098h 0152 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[099h 0153 002h]                   Device ID : 0010
+[09Bh 0155 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[09Ch 0156 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[09Dh 0157 002h]                   Device ID : 00F8
+[09Fh 0159 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[0A0h 0160 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[0A1h 0161 002h]                   Device ID : 00FA
+[0A3h 0163 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[0A4h 0164 001h]               Subtable Type : 02 [Device Entry: Select One Device]
+[0A5h 0165 002h]                   Device ID : 00FB
+[0A7h 0167 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+
+[0A8h 0168 001h]               Subtable Type : 48 [Device Entry: Special Device]
+[0A9h 0169 002h]                   Device ID : 0000
+[0ABh 0171 001h] Data Setting (decoded below) : 00
+                                    INITPass : 0
+                                    EIntPass : 0
+                                     NMIPass : 0
+                                    Reserved : 0
+                                 System MGMT : 0
+                                  LINT0 Pass : 0
+                                  LINT1 Pass : 0
+[0ACh 0172 001h]                      Handle : 00
+[0ADh 0173 002h]       Source Used Device ID : 00A0
+[0AFh 0175 001h]                     Variety : 01
+
+Raw Table Data: Length 176 (0xB0)

-    0000: 49 56 52 53 68 00 00 00 01 43 42 4F 43 48 53 20  // IVRSh....CBOCHS
+    0000: 49 56 52 53 B0 00 00 00 01 74 42 4F 43 48 53 20  // IVRS.....tBOCHS
     0010: 42 58 50 43 20 20 20 20 01 00 00 00 42 58 50 43  // BXPC    ....BXPC
-    0020: 01 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00  // .....(..........
+    0020: 01 00 00 00 01 28 00 00 00 00 00 00 00 00 00 00  // .....(..........
     0030: 10 D1 38 00 10 00 40 00 00 00 D8 FE 00 00 00 00  // ..8...@.........
     0040: 00 00 00 00 44 00 00 00 02 00 00 00 02 08 00 00  // ....D...........
     0050: 02 10 00 00 02 F8 00 00 02 FA 00 00 02 FB 00 00  // ................
-    0060: 48 00 00 00 00 A0 00 01                          // H.......
+    0060: 48 00 00 00 00 A0 00 01 11 11 48 00 10 00 40 00  // H.........H...@.
+    0070: 00 00 D8 FE 00 00 00 00 00 00 00 00 00 00 00 00  // ................
+    0080: D3 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00  // .)..............
+    0090: 02 00 00 00 02 08 00 00 02 10 00 00 02 F8 00 00  // ................
+    00A0: 02 FA 00 00 02 FB 00 00 48 00 00 00 00 A0 00 01  // ........H.......

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-8-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoamd_iommu: report x2APIC support to the operating system
Bui Quang Minh [Thu, 11 Jan 2024 15:44:03 +0000 (22:44 +0700)]
amd_iommu: report x2APIC support to the operating system

This commit adds XTSup configuration to let user choose to whether enable
this feature or not. When XTSup is enabled, additional bytes in IRTE with
enabled guest virtual VAPIC are used to support 32-bit destination id.

Additionally, this commit exports IVHD type 0x11 besides the old IVHD type
0x10 in ACPI table. IVHD type 0x10 does not report full set of IOMMU
features only the legacy ones, so operating system (e.g. Linux) may only
detects x2APIC support if IVHD type 0x11 is available. The IVHD type 0x10
is kept so that old operating system that only parses type 0x10 can detect
the IOMMU device.

Besides, an amd_iommu-stub.c file is created to provide the definition for
amdvi_extended_feature_register when CONFIG_AMD_IOMMU=n. This function is
used by acpi-build.c to get the extended feature register value for
building the ACPI table. When CONFIG_AMD_IOMMU=y, this function is defined
in amd_iommu.c.

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-7-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agotest: bios-tables-test: prepare IVRS change in ACPI table
Bui Quang Minh [Thu, 11 Jan 2024 15:44:02 +0000 (22:44 +0700)]
test: bios-tables-test: prepare IVRS change in ACPI table

Following the instructions in bios-tables-test, this lists that IVRS.ivrs
in ACPI table will be changed to add new IVHD type 0x11.

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-6-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agointel_iommu: allow Extended Interrupt Mode when using userspace APIC
Bui Quang Minh [Thu, 11 Jan 2024 15:44:01 +0000 (22:44 +0700)]
intel_iommu: allow Extended Interrupt Mode when using userspace APIC

As userspace APIC now supports x2APIC, intel interrupt remapping
hardware can be set to EIM mode when userspace local APIC is used.

Suggested-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-5-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoapic, i386/tcg: add x2apic transitions
Bui Quang Minh [Thu, 11 Jan 2024 15:44:00 +0000 (22:44 +0700)]
apic, i386/tcg: add x2apic transitions

This commit adds support for x2APIC transitions when writing to
MSR_IA32_APICBASE register and finally adds CPUID_EXT_X2APIC to
TCG_EXT_FEATURES.

The set_base in APICCommonClass now returns an integer to indicate error in
execution. apic_set_base return -1 on invalid APIC state transition,
accelerator can use this to raise appropriate exception.

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-4-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoapic: add support for x2APIC mode
Bui Quang Minh [Thu, 11 Jan 2024 15:43:59 +0000 (22:43 +0700)]
apic: add support for x2APIC mode

This commit extends the APIC ID to 32-bit long and remove the 255 max APIC
ID limit in userspace APIC. The array that manages local APICs is now
dynamically allocated based on the max APIC ID of created x86 machine.
Also, new x2APIC IPI destination determination scheme, self IPI and x2APIC
mode register access are supported.

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-3-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoi386/tcg: implement x2APIC registers MSR access
Bui Quang Minh [Thu, 11 Jan 2024 15:43:58 +0000 (22:43 +0700)]
i386/tcg: implement x2APIC registers MSR access

This commit creates apic_register_read/write which are used by both
apic_mem_read/write for MMIO access and apic_msr_read/write for MSR access.

The apic_msr_read/write returns -1 on error, accelerator can use this to
raise the appropriate exception.

Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Message-Id: <20240111154404.5333-2-minhquangbui99@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: derive vhost-user-input from vhost-user-base
Leo Yan [Thu, 4 Jan 2024 21:09:45 +0000 (21:09 +0000)]
hw/virtio: derive vhost-user-input from vhost-user-base

This patch derives vhost-user-input from vhost-user-base class, so make
the input stub as a simpler boilerplate wrapper.

With the refactoring, vhost-user-input adds the property 'chardev', this
leads to conflict with the vhost-user-input-pci adds the same property.
To resolve the error, remove the duplicate property from
vhost-user-input-pci.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-Id: <20231120043721.50555-5-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-12-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: Move vhost-user-input into virtio folder
Leo Yan [Thu, 4 Jan 2024 21:09:44 +0000 (21:09 +0000)]
hw/virtio: Move vhost-user-input into virtio folder

vhost-user-input is in the input folder.  On the other hand, the folder
'hw/virtio' maintains other virtio stubs (e.g. I2C, RNG, GPIO, etc).

This patch moves vhost-user-input into the virtio folder for better code
organization.  No functionality change.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-Id: <20231120043721.50555-4-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-11-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agodocs/system: Add vhost-user-input documentation
Leo Yan [Thu, 4 Jan 2024 21:09:43 +0000 (21:09 +0000)]
docs/system: Add vhost-user-input documentation

This adds basic documentation for vhost-user-input.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Message-Id: <20231120043721.50555-3-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-10-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: Support set_config() callback in vhost-user-base
Leo Yan [Thu, 4 Jan 2024 21:09:42 +0000 (21:09 +0000)]
hw/virtio: Support set_config() callback in vhost-user-base

The Virtio input device invokes set_config() callback for retrieving
the event configuration info, but the callback is not supported in
vhost-user-base.

This patch adds support set_config() callback in vhost-user-base.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231120043721.50555-2-leo.yan@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-9-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agodocs/system: add a basic enumeration of vhost-user devices
Alex Bennée [Thu, 4 Jan 2024 21:09:41 +0000 (21:09 +0000)]
docs/system: add a basic enumeration of vhost-user devices

Make it clear the vhost-user-device is intended for expert use only.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-8-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: add vhost-user-snd and vhost-user-snd-pci devices
Manos Pitsidianakis [Thu, 4 Jan 2024 21:09:40 +0000 (21:09 +0000)]
hw/virtio: add vhost-user-snd and vhost-user-snd-pci devices

Tested with rust-vmm vhost-user-sound daemon:

    RUST_LOG=trace cargo run --bin vhost-user-sound -- --socket /tmp/snd.sock --backend null

Invocation:

    qemu-system-x86_64  \
            -qmp unix:./qmp-sock,server,wait=off  \
            -m 4096 \
            -numa node,memdev=mem \
            -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
            -D qemu.log \
            -d guest_errors,trace:\*snd\*,trace:\*sound\*,trace:\*vhost\* \
            -chardev socket,id=vsnd,path=/tmp/snd.sock \
            -device vhost-user-snd-pci,chardev=vsnd,id=snd \
            /path/to/disk

[AJB: imported from https://github.com/epilys/qemu-virtio-snd/commit/54ae1cdd15fef2d88e9e387a175f099a38c636f4.patch]

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-Id: <20240104210945.1223134-7-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: derive vhost-user-i2c from vhost-user-base
Alex Bennée [Thu, 4 Jan 2024 21:09:39 +0000 (21:09 +0000)]
hw/virtio: derive vhost-user-i2c from vhost-user-base

Now we can take advantage of the new base class and make
vhost-user-i2c a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.

Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-6-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: derive vhost-user-gpio from vhost-user-base
Alex Bennée [Thu, 4 Jan 2024 21:09:38 +0000 (21:09 +0000)]
hw/virtio: derive vhost-user-gpio from vhost-user-base

Now the new base class supports config handling we can take advantage
and make vhost-user-gpio a much simpler boilerplate wrapper. Also as
this doesn't require any target specific hacks we only need to build
the stubs once.

Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-5-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: derive vhost-user-rng from vhost-user-base
Alex Bennée [Thu, 4 Jan 2024 21:09:37 +0000 (21:09 +0000)]
hw/virtio: derive vhost-user-rng from vhost-user-base

Now we can take advantage of our new base class and make
vhost-user-rng a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.

Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-4-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agohw/virtio: convert vhost-user-base to async shutdown
Alex Bennée [Thu, 4 Jan 2024 21:09:36 +0000 (21:09 +0000)]
hw/virtio: convert vhost-user-base to async shutdown

We are about to convert at least one stubs which was using the async
teardown so lets use it for all the cases.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-3-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agovirtio: split into vhost-user-base and vhost-user-device
Alex Bennée [Thu, 4 Jan 2024 21:09:35 +0000 (21:09 +0000)]
virtio: split into vhost-user-base and vhost-user-device

Lets keep a cleaner split between the base class and the derived
vhost-user-device which we can use for generic vhost-user stubs. This
includes an update to introduce the vq_size property so the number of
entries in a virtq can be defined.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240104210945.1223134-2-alex.bennee@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
14 months agoMerge tag 'pull-riscv-to-apply-20240209' of https://github.com/alistair23/qemu into...
Peter Maydell [Fri, 9 Feb 2024 16:15:01 +0000 (16:15 +0000)]
Merge tag 'pull-riscv-to-apply-20240209' of https://github.com/alistair23/qemu into staging

RISC-V PR for 9.0

* Check for 'A' extension on all atomic instructions
* Add support for 'B' extension
* Internally deprecate riscv_cpu_options
* Implement optional CSR mcontext of debug Sdtrig extension
* Internally add cpu->cfg.vlenb and  remove cpu->cfg.vlen
* Support vlenb and vregs[] in KVM
* RISC-V gdbstub and TCG plugin improvements
* Remove vxrm and vxsat from FCSR
* Use RISCVException as return type for all csr ops
* Use g_autofree more and fix a memory leak
* Add support for Zaamo and Zalrsc
* Support new isa extension detection devicetree properties
* SMBIOS support for RISC-V virt machine
* Enable xtheadsync under user mode
* Add rv32i,rv32e and rv64e CPUs

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmXGBRAACgkQr3yVEwxT
# gBPqVA//etMiwP8+lQb2E4pw+QwBIzpm3qFyBlqgSCFrekj1u2kYNd4CH3CKurWE
# ysoQ6OAMeb0MUbRHdjrejjzD/wOg7JNA9h7ynM1VbupveBrJY3GWC6qQWSG+A1j/
# LSgmr/dDya74chDxjxa+7ld3xqloHi5OtdGaeORfdPXl7mjCCKKCoSKYCex1ykup
# uuB7bsjeWeWEbuUsntmeuHJLZJuhpnbuZJmp17tEo+3vWXqjxV00Lik+XMwh3gua
# KOLiAqHjGr2NEhA3Mg1JLcQ+6JLTDM9ugZpQeNGQwMkfuB/RAU7jO/1Di3flbadF
# 8l2xOHu3mydDbfdxTGZNJjcIrMTX/YEewAYZLRYpNsyPOMntgq8HEegwCdWGvK7C
# M5Tc59MNSuBt+zkZkHd21qLYusa2ThP4YT/schh7IA+2F1TSKdhlptEzi2oebIc7
# ilLSgZ9Of72QlAH2OPJNSAL9Nbc06MHEM0JiHIJa5u+XdcVRhZus5h1YIOKXisqF
# YPP22RnI5Jj5d5csa/0ONAZGFh5SRMTJtpjKoKSkzoYJWDjCQ2MiUAOmLscchMZd
# wbK0vjeRf6kRG4U4z7nTmHS9kzH8RXUZDecVcOITuMpKih9LhUiCZ+xPunFYPycJ
# WNFa9/pENcCXJweXvtk4NHwx933rX56678lF6KY2hwUwwaiBOv4=
# =yuRM
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 09 Feb 2024 10:57:20 GMT
# gpg:                using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65  9296 AF7C 9513 0C53 8013

* tag 'pull-riscv-to-apply-20240209' of https://github.com/alistair23/qemu: (61 commits)
  target/riscv: add rv32i, rv32e and rv64e CPUs
  target/riscv/cpu.c: add riscv_bare_cpu_init()
  target/riscv: Enable xtheadsync under user mode
  qemu-options: enable -smbios option on RISC-V
  target/riscv: SMBIOS support for RISC-V virt machine
  smbios: function to set default processor family
  smbios: add processor-family option
  target/riscv: support new isa extension detection devicetree properties
  target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS
  target/riscv: Expose Zaamo and Zalrsc extensions
  target/riscv: Check 'A' and split extensions for atomic instructions
  target/riscv: Add Zaamo and Zalrsc extension infrastructure
  hw/riscv/virt.c: use g_autofree in create_fdt_*
  hw/riscv/virt.c: use g_autofree in virt_machine_init()
  hw/riscv/virt.c: use g_autofree in create_fdt_virtio()
  hw/riscv/virt.c: use g_autofree in create_fdt_sockets()
  hw/riscv/virt.c: use g_autofree in create_fdt_socket_cpus()
  hw/riscv/numa.c: use g_autofree in socket_fdt_write_distance_matrix()
  hw/riscv/virt-acpi-build.c: fix leak in build_rhct()
  target/riscv: Use RISCVException as return type for all csr ops
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agoMerge tag 'migration-staging-pull-request' of https://gitlab.com/peterx/qemu into...
Peter Maydell [Fri, 9 Feb 2024 11:22:20 +0000 (11:22 +0000)]
Merge tag 'migration-staging-pull-request' of https://gitlab.com/peterx/qemu into staging

Migration pull

- William's fix on hwpoison migration which used to crash QEMU
- Peter's multifd cleanup + bugfix + optimizations
- Avihai's fix on multifd crash over non-socket channels
- Fabiano's multifd thread-race fix
- Peter's CI fix series

# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCZcREtRIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wacrwEAl2aeQkh51h/e+OKX7MG4/4Y6Edf6Oz7o
# IJLk/cyrUFQA/2exo2lOdv5zHNOJKwAYj8HYDraezrC/MK1eED4Wji0M
# =k53l
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Feb 2024 03:04:21 GMT
# gpg:                using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg:                issuer "peterx@redhat.com"
# gpg: Good signature from "Peter Xu <xzpeter@gmail.com>" [marginal]
# gpg:                 aka "Peter Xu <peterx@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D  D1A9 3B5F CCCD F3AB D706

* tag 'migration-staging-pull-request' of https://gitlab.com/peterx/qemu: (34 commits)
  ci: Update comment for migration-compat-aarch64
  ci: Remove tag dependency for build-previous-qemu
  tests/migration-test: Stick with gicv3 in aarch64 test
  migration/multifd: Add a synchronization point for channel creation
  migration/multifd: Unify multifd and TLS connection paths
  migration/multifd: Move multifd_send_setup into migration thread
  migration/multifd: Move multifd_send_setup error handling in to the function
  migration/multifd: Remove p->running
  migration/multifd: Join the TLS thread
  migration: Fix logic of channels and transport compatibility check
  migration/multifd: Optimize sender side to be lockless
  migration/multifd: Fix MultiFDSendParams.packet_num race
  migration/multifd: Stick with send/recv on function names
  migration/multifd: Cleanup multifd_load_cleanup()
  migration/multifd: Cleanup multifd_save_cleanup()
  migration/multifd: Rewrite multifd_queue_page()
  migration/multifd: Change retval of multifd_send_pages()
  migration/multifd: Change retval of multifd_queue_page()
  migration/multifd: Split multifd_send_terminate_threads()
  migration/multifd: Forbid spurious wakeups
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agotarget/riscv: add rv32i, rv32e and rv64e CPUs
Daniel Henrique Barboza [Mon, 22 Jan 2024 12:33:48 +0000 (09:33 -0300)]
target/riscv: add rv32i, rv32e and rv64e CPUs

A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a
full customized 32 bit CPU is desired, and users won't need to disable
defaults by hand as they would with the rv32 CPU. [1] has an example of
a situation that would be avoided with rv32i.

In fact, add bare bones CPUs for RVE as well. Trying to use RVE in QEMU
requires one to disable every single default extension, including RVI,
and then add the desirable extension set. Adding rv32e/rv64e makes it
more pleasant to use embedded CPUs in QEMU.

[1] https://lore.kernel.org/qemu-riscv/258be47f-97be-4308-bed5-dc34ef7ff954@Spark/

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122123348.973288-3-dbarboza@ventanamicro.com>
[ Changes by AF:
 - Rebase on latest changes
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.c: add riscv_bare_cpu_init()
Daniel Henrique Barboza [Mon, 22 Jan 2024 12:33:47 +0000 (09:33 -0300)]
target/riscv/cpu.c: add riscv_bare_cpu_init()

Next patch will add more bare CPUs. Their cpu_init() functions would be
glorified copy/pastes of rv64i_bare_cpu_init(), differing only by a
riscv_cpu_set_misa() call.

Add a new .instance_init for the TYPE_RISCV_BARE_CPU typ to avoid this
code repetition. While we're at it, add a better explanation on why
we're disabling the timing extensions for bare CPUs.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122123348.973288-2-dbarboza@ventanamicro.com>
[ Changes by AF:
 - Rebase on latest changes
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Enable xtheadsync under user mode
LIU Zhiwei [Sun, 4 Feb 2024 05:52:28 +0000 (13:52 +0800)]
target/riscv: Enable xtheadsync under user mode

According to xtheadsync[1][2] documentation, it can be used in user mode and
the behavior is same with other priviledges.

[1]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsync/sync.adoc
[2]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsync/sync_i.adoc

Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240204055228.900-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agoqemu-options: enable -smbios option on RISC-V
Heinrich Schuchardt [Tue, 23 Jan 2024 18:42:29 +0000 (19:42 +0100)]
qemu-options: enable -smbios option on RISC-V

With SMBIOS support added for RISC-V we also should enable the command line
option.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20240123184229.10415-5-heinrich.schuchardt@canonical.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: SMBIOS support for RISC-V virt machine
Heinrich Schuchardt [Tue, 23 Jan 2024 18:42:28 +0000 (19:42 +0100)]
target/riscv: SMBIOS support for RISC-V virt machine

Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
Set the default processor family in the type 4 table.

The implementation is based on the corresponding ARM and Loongson code.

With the patch the following firmware tables are provided:

    etc/smbios/smbios-anchor
    etc/smbios/smbios-tables

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20240123184229.10415-4-heinrich.schuchardt@canonical.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agosmbios: function to set default processor family
Heinrich Schuchardt [Tue, 23 Jan 2024 18:42:27 +0000 (19:42 +0100)]
smbios: function to set default processor family

Provide a function to set the default processor family.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20240123184229.10415-3-heinrich.schuchardt@canonical.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agosmbios: add processor-family option
Heinrich Schuchardt [Tue, 23 Jan 2024 18:42:26 +0000 (19:42 +0100)]
smbios: add processor-family option

For RISC-V the SMBIOS standard requires specific values of the processor
family value depending on the bitness of the CPU.

Add a processor-family option for SMBIOS table 4.

The value of processor-family may exceed 255 and therefore must be provided
in the Processor Family 2 field. Set the Processor Family field to 0xFE
which signals that the Processor Family 2 is used.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20240123184229.10415-2-heinrich.schuchardt@canonical.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: support new isa extension detection devicetree properties
Conor Dooley [Wed, 24 Jan 2024 12:55:50 +0000 (12:55 +0000)]
target/riscv: support new isa extension detection devicetree properties

A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "riscv,isa" with a new
set of properties that allowed for strictly defining the meaning of
various extensions, where "riscv,isa" was tied to whatever definitions
inflicted upon us by the ISA manual, which have seen some variance over
time.

Two new properties were introduced: "riscv,isa-base" and
"riscv,isa-extensions". The former is a simple string to communicate the
base ISA implemented by a hart and the latter an array of strings used
to communicate the set of ISA extensions supported, per the definitions
of each substring in extensions.yaml [1]. A beneficial side effect was
also the ability to define vendor extensions in a more "official" way,
as the ISA manual and other RVI specifications only covered the format
for vendor extensions in the ISA string, but not the meaning of vendor
extensions, for obvious reasons.

Add support for setting these two new properties in the devicetrees for
the various devicetree platforms supported by QEMU for RISC-V. The Linux
kernel already supports parsing ISA extensions from these new
properties, and documenting them in the dt-binding is a requirement for
new extension detection being added to the kernel.

A side effect of the implementation is that the meaning for elements in
"riscv,isa" and in "riscv,isa-extensions" are now tied together as they
are constructed from the same source. The same applies to the ISA string
provided in ACPI tables, but there does not appear to be any strict
definitions of meanings in ACPI land either.

Link: https://lore.kernel.org/qemu-riscv/20230702-eats-scorebook-c951f170d29f@spud/
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/riscv/extensions.yaml
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240124-unvarying-foothold-9dde2aaf95d4@spud>
[ Changes by AF:
 - Rebase on recent changes
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS
Conor Dooley [Wed, 24 Jan 2024 12:55:49 +0000 (12:55 +0000)]
target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS

A cpu may not have the same xlen as the compile time target, and
misa_mxl_max is the source of truth for what the hart supports.

The conversion from misa_mxl_max to xlen already has one user, so
introduce a helper and use that to populate the isa string.

Link: https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240124-swear-monthly-56c281f809a6@spud>
[ Changes by AF:
 - Convert to use RISCVCPUClass *mcc
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Expose Zaamo and Zalrsc extensions
Rob Bradford [Tue, 23 Jan 2024 11:10:30 +0000 (11:10 +0000)]
target/riscv: Expose Zaamo and Zalrsc extensions

Expose the newly added extensions to the guest and allow their control
through the CPU properties.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240123111030.15074-4-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Check 'A' and split extensions for atomic instructions
Rob Bradford [Tue, 23 Jan 2024 11:10:29 +0000 (11:10 +0000)]
target/riscv: Check 'A' and split extensions for atomic instructions

Following the pattern for 'M' and Zmmul check if either the 'A'
extension is enabled or the appropriate split extension for the
instruction.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240123111030.15074-3-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Add Zaamo and Zalrsc extension infrastructure
Rob Bradford [Tue, 23 Jan 2024 11:10:28 +0000 (11:10 +0000)]
target/riscv: Add Zaamo and Zalrsc extension infrastructure

These extensions represent the atomic operations from A (Zaamo) and the
Load-Reserved/Store-Conditional operations from A (Zalrsc)

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240123111030.15074-2-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt.c: use g_autofree in create_fdt_*
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:29 +0000 (19:15 -0300)]
hw/riscv/virt.c: use g_autofree in create_fdt_*

We have a lot of cases where a char or an uint32_t pointer is used once
to alloc a string/array, read/written during the function, and then
g_free() at the end. There's no pointer re-use - a single alloc, a
single g_free().

Use 'g_autofree' to avoid the g_free() calls.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122221529.86562-8-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt.c: use g_autofree in virt_machine_init()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:28 +0000 (19:15 -0300)]
hw/riscv/virt.c: use g_autofree in virt_machine_init()

Move 'soc_name' to the loop, and give it g_autofree, to avoid the manual
g_free().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240122221529.86562-7-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt.c: use g_autofree in create_fdt_virtio()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:27 +0000 (19:15 -0300)]
hw/riscv/virt.c: use g_autofree in create_fdt_virtio()

Put 'name' declaration inside the loop, with g_autofree, to avoid
manually doing g_free() in each iteration.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240122221529.86562-6-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt.c: use g_autofree in create_fdt_sockets()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:26 +0000 (19:15 -0300)]
hw/riscv/virt.c: use g_autofree in create_fdt_sockets()

Move 'clust_name' inside the loop, and g_autofree, to avoid having to
g_free() manually in each loop iteration.

'intc_phandles' is also g_autofreed to avoid another manual g_free().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122221529.86562-5-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt.c: use g_autofree in create_fdt_socket_cpus()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:25 +0000 (19:15 -0300)]
hw/riscv/virt.c: use g_autofree in create_fdt_socket_cpus()

Move all char pointers to the loop. Use g_autofree in all of them to
avoid the g_free() calls.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240122221529.86562-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/numa.c: use g_autofree in socket_fdt_write_distance_matrix()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:24 +0000 (19:15 -0300)]
hw/riscv/numa.c: use g_autofree in socket_fdt_write_distance_matrix()

Use g_autofree in 'dist_matrix' to avoid the manual g_free().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122221529.86562-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agohw/riscv/virt-acpi-build.c: fix leak in build_rhct()
Daniel Henrique Barboza [Mon, 22 Jan 2024 22:15:23 +0000 (19:15 -0300)]
hw/riscv/virt-acpi-build.c: fix leak in build_rhct()

The 'isa' char pointer isn't being freed after use.

Issue detected by Valgrind:

==38752== 128 bytes in 1 blocks are definitely lost in loss record 3,190 of 3,884
==38752==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==38752==    by 0x5189619: g_malloc (gmem.c:130)
==38752==    by 0x51A5BF2: g_strconcat (gstrfuncs.c:628)
==38752==    by 0x6C1E3E: riscv_isa_string_ext (cpu.c:2321)
==38752==    by 0x6C1E3E: riscv_isa_string (cpu.c:2343)
==38752==    by 0x6BD2EA: build_rhct (virt-acpi-build.c:232)
==38752==    by 0x6BD2EA: virt_acpi_build (virt-acpi-build.c:556)
==38752==    by 0x6BDC86: virt_acpi_setup (virt-acpi-build.c:662)
==38752==    by 0x9C8DC6: notifier_list_notify (notify.c:39)
==38752==    by 0x4A595A: qdev_machine_creation_done (machine.c:1589)
==38752==    by 0x61E052: qemu_machine_creation_done (vl.c:2680)
==38752==    by 0x61E052: qmp_x_exit_preconfig.part.0 (vl.c:2709)
==38752==    by 0x6220C6: qmp_x_exit_preconfig (vl.c:2702)
==38752==    by 0x6220C6: qemu_init (vl.c:3758)
==38752==    by 0x425858: main (main.c:47)

Fixes: ebfd392893 ("hw/riscv/virt: virt-acpi-build.c: Add RHCT Table")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122221529.86562-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Use RISCVException as return type for all csr ops
LIU Zhiwei [Tue, 30 Jan 2024 11:08:44 +0000 (19:08 +0800)]
target/riscv: Use RISCVException as return type for all csr ops

The real return value type has been converted to RISCVException,
but some function declarations still not. This patch makes all
csr operation declarations use RISCVExcetion.

Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240130110844.437-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: FCSR doesn't contain vxrm and vxsat
LIU Zhiwei [Tue, 30 Jan 2024 11:09:45 +0000 (19:09 +0800)]
target/riscv: FCSR doesn't contain vxrm and vxsat

vxrm and vxsat have been moved into a special register vcsr since
RVV v1.0. So remove them from FCSR for vector 1.0.

Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240130110945.486-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Validate misa_mxl_max only once
Akihiko Odaki [Sat, 3 Feb 2024 10:11:10 +0000 (19:11 +0900)]
target/riscv: Validate misa_mxl_max only once

misa_mxl_max is now a class member and initialized only once for each
class. This also moves the initialization of gdb_core_xml_file which
will be referenced before realization in the future.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240203-riscv-v11-3-a23f4848a628@daynix.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Move misa_mxl_max to class
Akihiko Odaki [Sat, 3 Feb 2024 10:11:09 +0000 (19:11 +0900)]
target/riscv: Move misa_mxl_max to class

misa_mxl_max is common for all instances of a RISC-V CPU class so they
are better put into class.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Remove misa_mxl validation
Akihiko Odaki [Sat, 3 Feb 2024 10:11:08 +0000 (19:11 +0900)]
target/riscv: Remove misa_mxl validation

It is initialized with a simple assignment and there is little room for
error. In fact, the validation is even more complex.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240203-riscv-v11-1-a23f4848a628@daynix.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/kvm: get/set vector vregs[]
Daniel Henrique Barboza [Tue, 23 Jan 2024 16:17:14 +0000 (13:17 -0300)]
target/riscv/kvm: get/set vector vregs[]

vregs[] have variable size that depends on the current vlenb set by the
host, meaning we can't use our regular kvm_riscv_reg_id() to retrieve
it.

Create a generic kvm_encode_reg_size_id() helper to encode any given
size in bytes into a given kvm reg id. kvm_riscv_vector_reg_id() will
use it to encode vlenb into a given vreg ID.

kvm_riscv_(get|set)_vector() can then get/set all 32 vregs.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240123161714.160149-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/kvm: initialize 'vlenb' via get-reg-list
Daniel Henrique Barboza [Tue, 23 Jan 2024 16:17:13 +0000 (13:17 -0300)]
target/riscv/kvm: initialize 'vlenb' via get-reg-list

KVM will check for the correct 'reg_size' when accessing the vector
registers, erroring with EINVAL if we encode the wrong size in reg ID.
Vector registers varies in size with the vector length in bytes, or
'vlenb'. This means that we need the current 'vlenb' being used by the
host, otherwise we won't be able to fetch all vector regs.

We'll deal with 'vlenb' first. Its support was added in Linux 6.8 as a
get-reg-list register. We'll read 'vlenb' via get-reg-list and mark the
register as 'supported'. All 'vlenb' ops via kvm_arch_get_registers()
and kvm_arch_put_registers() will only be done if the reg is supported,
i.e. we fetched it in get-reg-list during init.

If the user sets a new vlenb value using the 'vlen' property, throw an
error if the user value differs from the host.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240123161714.160149-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/kvm: change kvm_reg_id to uint64_t
Daniel Henrique Barboza [Tue, 23 Jan 2024 16:17:12 +0000 (13:17 -0300)]
target/riscv/kvm: change kvm_reg_id to uint64_t

The field isn't big enough to hold an uint64_t kvm register and Vector
registers will end up overflowing it.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240123161714.160149-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.c: remove cpu->cfg.vlen
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:07 +0000 (13:11 -0300)]
target/riscv/cpu.c: remove cpu->cfg.vlen

There is no need to keep both 'vlen' and 'vlenb'. All existing code
that requires 'vlen' is retrieving it via 'vlenb << 3'.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-14-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotrans_rvv.c.inc: use vext_get_vlmax() in trans_vrgather_v*()
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:06 +0000 (13:11 -0300)]
trans_rvv.c.inc: use vext_get_vlmax() in trans_vrgather_v*()

Use the helper instead of calculating vlmax by hand.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-13-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: change vext_get_vlmax() arguments
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:05 +0000 (13:11 -0300)]
target/riscv: change vext_get_vlmax() arguments

We'll re-use the logic froim vext_get_vlmax() in 2 other occurrences in
the next patch, but first we need to make it independent of both 'cpu'
and 'vtype'. To do that, add 'vlenb', 'vsew' and 'lmul' as parameters
instead.

Adapt the two existing callers. In cpu_get_tb_cpu_state(), rename 'sew'
to 'vsew' to be less ambiguous about what we're encoding into *pflags.

In HELPER(vsetvl) the following changes were made:

- add a 'vsew' var to store vsew. Use it in the shift to get 'sew';
- the existing 'lmul' var was renamed to 'vlmul';
- add a new 'lmul' var to store 'lmul' encoded like DisasContext:lmul.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-12-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.h: use 'vlenb' in vext_get_vlmax()
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:04 +0000 (13:11 -0300)]
target/riscv/cpu.h: use 'vlenb' in vext_get_vlmax()

Rename the existing 'sew' variable to 'vsew' for extra clarity.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-11-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb' in MAXSZ()
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:03 +0000 (13:11 -0300)]
target/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb' in MAXSZ()

Calculate the maximum vector size possible, 'max_sz', which is the size
in bytes 'vlenb' multiplied by the max value of LMUL (LMUL = 8, when
s->lmul = 3).

'max_sz' is then shifted right by 'scale', expressed as '3 - s->lmul',
which is clearer than doing 'scale = lmul - 3' and then using '-scale'
in the shift right.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-10-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/vector_helper.c: use vlenb in HELPER(vsetvl)
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:02 +0000 (13:11 -0300)]
target/riscv/vector_helper.c: use vlenb in HELPER(vsetvl)

Use the new 'vlenb' CPU config to validate fractional LMUL. The original
comparison is done with 'vlen' and 'sew', both in bits. Adjust the shift
to use vlenb.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-9-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/vector_helper.c: use 'vlenb'
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:01 +0000 (13:11 -0300)]
target/riscv/vector_helper.c: use 'vlenb'

Use 'cpu->cfg.vlenb' instead of 'cpu->cfg.vlen >> 3'.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-8-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/insn_trans/trans_rvvk.c.inc: use 'vlenb'
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:11:00 +0000 (13:11 -0300)]
target/riscv/insn_trans/trans_rvvk.c.inc: use 'vlenb'

Use s->cfg_ptr->vlenb instead of s->cfg_ptr->vlen / 8.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-7-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb'
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:10:59 +0000 (13:10 -0300)]
target/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb'

Use s->cfg_ptr->vlenb instead of "s->cfg_ptr->vlen / 8"  and
"s->cfg_ptr->vlen >> 3".

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-6-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/insn_trans/trans_rvbf16.c.inc: use cpu->cfg.vlenb
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:10:58 +0000 (13:10 -0300)]
target/riscv/insn_trans/trans_rvbf16.c.inc: use cpu->cfg.vlenb

Use ctx->cfg_ptr->vlenb instead of ctx->cfg_ptr->vlen / 8.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-5-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/gdbstub.c: use 'vlenb' instead of shifting 'vlen'
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:10:57 +0000 (13:10 -0300)]
target/riscv/gdbstub.c: use 'vlenb' instead of shifting 'vlen'

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/csr.c: use 'vlenb' instead of 'vlen'
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:10:56 +0000 (13:10 -0300)]
target/riscv/csr.c: use 'vlenb' instead of 'vlen'

As a bonus, we're being more idiomatic using cpu->cfg.vlenb when
reading CSR_VLENB.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: add 'vlenb' field in cpu->cfg
Daniel Henrique Barboza [Mon, 22 Jan 2024 16:10:55 +0000 (13:10 -0300)]
target/riscv: add 'vlenb' field in cpu->cfg

Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'.
We're using 'vlenb' most of the time, having to do 'vlen >> 3' or
'vlen / 8' in every instance.

In hindsight we would be better if the 'vlenb' property  was introduced
instead of 'vlen'. That's not what happened, and now we can't easily get
rid of it due to user scripts all around. What we can do, however, is to
change our internal representation to use 'vlenb'.

Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen'
property, i.e. setting 'vlen' will also set 'vlenb'.

We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with
the single instance we have in target/riscv/cpu.c.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240122161107.26737-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Implement optional CSR mcontext of debug Sdtrig extension
Alvin Chang [Tue, 19 Dec 2023 12:32:44 +0000 (20:32 +0800)]
target/riscv: Implement optional CSR mcontext of debug Sdtrig extension

The debug Sdtrig extension defines an CSR "mcontext". This commit
implements its predicate and read/write operations into CSR table.
Its value is reset as 0 when the trigger module is reset.

Signed-off-by: Alvin Chang <alvinga@andestech.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20231219123244.290935-1-alvinga@andestech.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:02:01 +0000 (11:02 -0300)]
target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[].

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-9-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:02:00 +0000 (11:02 -0300)]
target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[].

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-8-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:59 +0000 (11:01 -0300)]
target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[].

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-7-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: remove riscv_cpu_options[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:58 +0000 (11:01 -0300)]
target/riscv: remove riscv_cpu_options[]

The array is empty and can be removed.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-6-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'cboz_blocksize' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:57 +0000 (11:01 -0300)]
target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[]

And remove the now unused kvm_cpu_set_cbomz_blksize() setter.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-5-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'cbop_blocksize' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:56 +0000 (11:01 -0300)]
target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[]

Do the same we did with 'cbom_blocksize' in the previous patch.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:55 +0000 (11:01 -0300)]
target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]

After adding a KVM finalize() implementation, turn cbom_blocksize into a
class property. Follow the same design we used with 'vlen' and 'elen'.

The duplicated 'cbom_blocksize' KVM property can be removed from
kvm_riscv_add_cpu_user_properties().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: create finalize_features() for KVM
Daniel Henrique Barboza [Fri, 12 Jan 2024 14:01:54 +0000 (11:01 -0300)]
target/riscv: create finalize_features() for KVM

To turn cbom_blocksize and cboz_blocksize into class properties we need
KVM specific changes.

KVM is creating its own version of these options with a customized
setter() that prevents users from picking an invalid value during init()
time. This comes at the cost of duplicating each option that KVM
supports. This will keep happening for each new shared option KVM
implements in the future.

We can avoid that by using the same property TCG uses and adding
specific KVM handling during finalize() time, like TCG already does with
riscv_tcg_cpu_finalize_features(). To do that, the common CPU property
offers a way of knowing if an option was user set or not, sparing us
from doing unneeded syscalls.

riscv_kvm_cpu_finalize_features() is then created using the same
KVMScratch CPU we already use during init() time, since finalize() time
is still too early to use the official KVM CPU for it. cbom_blocksize
and cboz_blocksize are then handled during finalize() in the same way
they're handled by their KVM specific setter.

With this change we can proceed with the blocksize changes in the common
code without breaking the KVM driver.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'elen' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:38 +0000 (20:05 -0300)]
target/riscv: move 'elen' to riscv_cpu_properties[]

Do the same thing we did with 'vlen' in the previous patch with 'elen'.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-10-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'vlen' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:37 +0000 (20:05 -0300)]
target/riscv: move 'vlen' to riscv_cpu_properties[]

Turning 'vlen' into a class property will allow its default value to be
overwritten by cpu_init() later on, solving the issue we have now where
CPU specific settings are getting overwritten by the default.

Common validation bits are moved from riscv_cpu_validate_v() to
prop_vlen_set() to be shared with KVM.

And, as done with every option we migrated to riscv_cpu_properties[],
vendor CPUs can't have their 'vlen' value changed.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: rework 'vext_spec'
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:36 +0000 (20:05 -0300)]
target/riscv: rework 'vext_spec'

The same rework did in 'priv_spec' is done for 'vext_spec'. This time is
simpler, since we only accept one value ("v1.0") and we'll always have
env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to
convert string to 'vext_ver' back and forth like we needed for
'priv_spec'.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: rework 'priv_spec'
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:35 +0000 (20:05 -0300)]
target/riscv: rework 'priv_spec'

'priv_spec' and 'vext_spec' are two string options used as a fancy way
of setting integers in the CPU state (cpu->env.priv_ver and
cpu->env.vext_ver). It requires us to deal with string parsing and to
store them in cpu_cfg.

We must support these string options, but we don't need to store them.
We have a precedence for this kind of arrangement in target/ppc/compat.c,
ppc_compat_prop_get|set, getters and setters used for the
'max-cpu-compat' class property of the pseries ppc64 machine. We'll do
the same with both 'priv_spec' and 'vext_spec'.

For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will
be done by the prop_priv_spec_set() setter, while also preventing it to
be changed for vendor CPUs. Add two helpers that converts env->priv_ver
back and forth to its string representation. These helpers allow us to
get a string and set 'env->priv_ver' and return a string giving the
current env->priv_ver value. In other words, make the cpu->cfg.priv_spec
string obsolete.

Last but not the least, move the reworked 'priv_spec' option to
riscv_cpu_properties[].

After all said and done, we don't need to store the 'priv_spec' string in
the CPU state, and we're now protecting vendor CPUs from priv_ver
changes:

$ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0"
qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0:
    CPU 'sifive-e51' does not allow changing the value of 'priv_spec'
Current 'priv_spec' val: v1.10.0
$

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'pmp' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:34 +0000 (20:05 -0300)]
target/riscv: move 'pmp' to riscv_cpu_properties[]

Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it
that forbids 'pmp' to be changed in vendor CPUs, like we did with the
'mmu' option.

We'll also have to manually set 'pmp = true' to generic CPUs that were
still relying on the previous default to set it.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'mmu' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:33 +0000 (20:05 -0300)]
target/riscv: move 'mmu' to riscv_cpu_properties[]

Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from
riscv_cpu_init()") already did some of the work by making some
cpu_init() functions to explictly enable their own 'mmu' default.

The generic CPUs didn't get update by that commit, so they are still
relying on the defaults set by the 'mmu' option. But having 'mmu' and
'pmp' being default=true will force CPUs that doesn't implement these
options to set them to 'false' in their cpu_init(), which isn't ideal.

We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e.
the default will be 'false'. Compensate it by manually setting 'mmu =
true' to the generic CPUs that requires it.

Implement a setter for it to forbid the 'mmu' setting to be changed for
vendor CPUs. This will allow the option to exist for all CPUs and, at
the same time, protect vendor CPUs from undesired changes:

$ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true
qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true:
   CPU 'sifive-e51' does not allow changing the value of 'mmu'

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[]
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:32 +0000 (20:05 -0300)]
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[]

Every property in riscv_cpu_options[] will be migrated to
riscv_cpu_properties[]. This will make their default values init
earlier, allowing cpu_init() functions to overwrite them. We'll also
implement common getters and setters that both accelerators will use,
allowing them to share validations that TCG is doing.

At the same time, some options (namely 'vlen', 'elen' and the cache
blocksizes) need a way of tracking if the user set a value for them.
This is benign for TCG since the cost of always validating these values
are small, but for KVM we need syscalls to read the host values to make
the validations, thus knowing whether the user didn't touch the values
makes a difference.

We'll track user setting for these properties using a hash, like we do
in the TCG driver. All riscv cpu options will update this hash in case
the user sets it. The KVM driver will use this hash to minimize the
amount of syscalls done.

For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor
CPUs. The existing setter for 'pmu-num' is changed to add this
restriction. New getters and setters are required for 'pmu-mask'

While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're
not exporting it.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: make riscv_cpu_is_vendor() public
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:31 +0000 (20:05 -0300)]
target/riscv: make riscv_cpu_is_vendor() public

We'll use this function in target/riscv/cpu.c to implement setters that
won't allow vendor CPU options to be changed.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv/cpu_cfg.h: remove unused fields
Daniel Henrique Barboza [Fri, 5 Jan 2024 23:05:30 +0000 (20:05 -0300)]
target/riscv/cpu_cfg.h: remove unused fields

user_spec, bext_spec and bext_ver aren't being used.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com>
Message-ID: <20240105230546.265053-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Add step to validate 'B' extension
Rob Bradford [Thu, 11 Jan 2024 16:16:44 +0000 (16:16 +0000)]
target/riscv: Add step to validate 'B' extension

If the B extension is enabled warn if the user has disabled any of the
required extensions that are part of the 'B' extension. Conversely
enable the extensions that make up the 'B' extension if it is enabled.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240111161644.33630-3-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Add infrastructure for 'B' MISA extension
Rob Bradford [Thu, 11 Jan 2024 16:16:43 +0000 (16:16 +0000)]
target/riscv: Add infrastructure for 'B' MISA extension

Add the infrastructure for the 'B' extension which is the union of the
Zba, Zbb and Zbs instructions.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240111161644.33630-2-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agotarget/riscv: Check for 'A' extension on all atomic instructions
Rob Bradford [Wed, 10 Jan 2024 16:39:59 +0000 (16:39 +0000)]
target/riscv: Check for 'A' extension on all atomic instructions

Add requirement that 'A' is enabled for all atomic instructions that
lack the check. This makes the 64-bit versions consistent with the
32-bit versions in the same file.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240110163959.31291-1-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
14 months agoMerge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Peter Maydell [Thu, 8 Feb 2024 20:08:44 +0000 (20:08 +0000)]
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging

Block layer patches

- Allow concurrent BB context changes
- virtio: Re-enable notifications after drain
- virtio-blk: Fix missing use of irqfd
- scsi: Don't ignore most usb-storage properties
- blkio: Respect memory-alignment for bounce buffer allocations
- iotests tmpdir fixes
- virtio-blk: Code cleanups

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmXEkwgRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9Y3jA//TmSBVqHljauyImYOgCt8qCXACttV0xhQ
# Q5ldUNx/JmIFMoUR7OlpVAL2MtvdwE0jjY+sDlEmWtz4IFJcCsCTUCHZZb8blreb
# +mnMkqrQ6Nb3tPR2jeIknrXqNy1ffyjZItktjWXVcl6jaHB8YabHHqszs9DIaf4n
# lcKovBKxula8ckMgvm48wCwTtS7VEPeuC5FrOqUqTtuhg+QKp5ZVoyVFHtf6GKTD
# iuXzCd4yxu4fDKAthJJj4N1bQaOmCKU7K9N/665wj9P2TyfmwlBAfNwNAlYbdX1E
# Sv7eSioQs2+oUxmfD/PUsF7wTYtDCrSAUFn1kP/XdRyXPJR3dHGiBKV9w9CaWNrU
# y8rqOhxVcuoBLRljTF32BK4HniAREjRngtpT2FnQQIyedZrXIwyTAWjs+LW12T6O
# NMiU603Nl9ZYhO1et2+qspsVpNIfEpQWpK+OCon6E+ggj1ea+pfqU30VPx4JU05I
# VLiydluIbehSkRlTHgFcTgApmx843OGW7CvWfRyen86Cexgx3DEjJUQ4/bYqaCha
# yLIi91rToSDmtlzJrg9eYiMs5Y6vz+ORvvX5im1RlbUUb7Kx/LaA4BU/uArEbBt8
# xXm/grO4hFUGqtLgd2LIjWaHSsLoW4jKeEiExFUUfvH5DG9Zl5HmzFwu+DYxX+im
# MJLLetDJAWI=
# =8tc0
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Feb 2024 08:38:32 GMT
# gpg:                using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg:                issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* tag 'for-upstream' of https://repo.or.cz/qemu/kevin:
  virtio-blk: avoid using ioeventfd state in irqfd conditional
  virtio-blk: Use ioeventfd_attach in start_ioeventfd
  virtio: Re-enable notifications after drain
  virtio-scsi: Attach event vq notifier with no_poll
  blkio: Respect memory-alignment for bounce buffer allocations
  scsi: Don't ignore most usb-storage properties
  virtio-blk: do not use C99 mixed declarations
  iotests: give tempdir an identifying name
  iotests: fix leak of tmpdir in dry-run mode
  scsi: Await request purging
  block-backend: Allow concurrent context changes
  monitor: use aio_co_reschedule_self()
  virtio-blk: declare VirtIOBlock::rq with a type
  virtio-blk: add vq_rq[] bounds check in virtio_blk_dma_restart_cb()
  virtio-blk: clarify that there is at least 1 virtqueue
  virtio-blk: enforce iothread-vq-mapping validation

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agoMerge tag 'pull-tcg-20240205-2' of https://gitlab.com/rth7680/qemu into staging
Peter Maydell [Thu, 8 Feb 2024 16:08:42 +0000 (16:08 +0000)]
Merge tag 'pull-tcg-20240205-2' of https://gitlab.com/rth7680/qemu into staging

tcg: Introduce TCG_COND_TST{EQ,NE}
target/alpha: Use TCG_COND_TST{EQ,NE}
target/m68k: Use TCG_COND_TST{EQ,NE} in gen_fcc_cond
target/sparc: Use TCG_COND_TSTEQ in gen_op_mulscc
target/s390x: Use TCG_COND_TSTNE for CC_OP_{TM,ICM}
target/s390x: Improve general case of disas_jcc

# -----BEGIN PGP SIGNATURE-----
#
# iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmXBpTAdHHJpY2hhcmQu
# aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/p6gf9HAasTSRECk2cvjW9
# /mcJy0AIaespnI50fG8fm48OoFl0847CdrsJycpZ1spw3W3Wb0cVbMbq/teNMjXZ
# 0SGQJFk9Baq7wMhW7VzhSzJ96pcorpQprp7XBMdheLXqpT4zsM/EuwEAepBk8RUG
# 3kCeo38dswXE681ZafZkd/8pPzII19sQK8eiMpceeYkBsbbep+DDcnE18Ee4kISS
# u0SbuslKVahxd86LKuzrcz0pNFcmFuR5jRP9hmbQ0MfeAn0Pxlndi+ayZNghfgPf
# 3hDjskiionFwxb/OoRj45BssTWfDiluWl7IUsHfegPXCQ2Y+woT5Vq6TVGZn0GqS
# c6RLQQ==
# =TMiE
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 06 Feb 2024 03:19:12 GMT
# 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-20240205-2' of https://gitlab.com/rth7680/qemu: (39 commits)
  tcg/tci: Support TCG_COND_TST{EQ,NE}
  tcg/s390x: Support TCG_COND_TST{EQ,NE}
  tcg/s390x: Add TCG_CT_CONST_CMP
  tcg/s390x: Split constraint A into J+U
  tcg/ppc: Support TCG_COND_TST{EQ,NE}
  tcg/ppc: Add TCG_CT_CONST_CMP
  tcg/ppc: Tidy up tcg_target_const_match
  tcg/ppc: Use cr0 in tcg_to_bc and tcg_to_isel
  tcg/ppc: Sink tcg_to_bc usage into tcg_out_bc
  tcg/sparc64: Support TCG_COND_TST{EQ,NE}
  tcg/sparc64: Pass TCGCond to tcg_out_cmp
  tcg/sparc64: Hoist read of tcg_cond_to_rcond
  tcg/i386: Use TEST r,r to test 8/16/32 bits
  tcg/i386: Improve TSTNE/TESTEQ vs powers of two
  tcg/i386: Support TCG_COND_TST{EQ,NE}
  tcg/i386: Move tcg_cond_to_jcc[] into tcg_out_cmp
  tcg/i386: Pass x86 condition codes to tcg_out_cmov
  tcg/arm: Support TCG_COND_TST{EQ,NE}
  tcg/arm: Split out tcg_out_cmp()
  tcg/aarch64: Generate CBNZ for TSTNE of UINT32_MAX
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agoMerge tag 'pull-request-2024-02-06' of https://gitlab.com/thuth/qemu into staging
Peter Maydell [Thu, 8 Feb 2024 11:59:28 +0000 (11:59 +0000)]
Merge tag 'pull-request-2024-02-06' of https://gitlab.com/thuth/qemu into staging

* Emulate CVB, CVBY, CVBG and CVDG s390x instructions
* Fix bug in lsi53c895a reentrancy counter
* Deprecate the "power5+" and "power7+" CPU names
* Fix problems in the freebsd VM test

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmXCCXURHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbXtEA/9HKWMHbWqDAdlrpmfW8lCFaBHgV0+Fqsy
# GlxJykni2BxIWNoR7J6SdAqbgx3E2/7i8IMIUwYXlNBjEs/UQ0ZcnI5k6OfUS24p
# qfbdH717SgsaB9R1vCBhmOGGWYBfe/RqPGIcni/eg+jSxB5cn2XvEv3+ZBckvDsh
# KFuuAa6vvuBVhyXLbkP8Z+LEe27ttIYi5v1dvJ1an4UbFESqxVb0knyuFYpZpY8Y
# h7dZ0hyCid7YT03zVmSADK7anO+epBdzUU3SsKXj2dB9nebSjmkav6lQQBKYHHUg
# THojcWKwFPNK0AojhBuBCqFYgkGGt/9kjwlUt7jfm1TcSemN65XLNYHThRekPuAJ
# Jcze8dcEerbj1xsNWYh4hPvB92laEiyVR5BYFfUkJ9m2IAamPQLHvOT7jzhC3Y9k
# 4wvVcf9QKVtKW0QO54SQjD4A/qQu/4777oH5w83nGuxjUthmHDqZmjDlIRe6lKJt
# gsA+mKn+w9HrtiXOSkoMhK8PAyvCoAef/N7kvHZoHmp6TtfQAjPs4/v2uZMpnd60
# z7Cw50giHpo9lmiZ1Ey2fQvw9orYhNoXAc4XfYGHuYdQFWpCGz1PB2Km8uTPTEUe
# as364ULBqWoFBCRuRndy2+z2e3zhK5THTPCAyHf48M6teMEPa4KTsTCk7MzmfVfx
# C8RsLcmrFPI=
# =eQNc
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 06 Feb 2024 10:27:01 GMT
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2024-02-06' of https://gitlab.com/thuth/qemu:
  meson: Link with libinotify on FreeBSD
  test-util-filemonitor: Adapt to the FreeBSD inotify rename semantics
  tests/vm/freebsd: Reload the sshd configuration
  tests/vm: Set UseDNS=no in the sshd configuration
  target/s390x: Prefer fast cpu_env() over slower CPU QOM cast macro
  tests/tcg/s390x: Test CONVERT TO BINARY
  tests/tcg/s390x: Test CONVERT TO DECIMAL
  target/s390x: Emulate CVB, CVBY and CVBG
  target/s390x: Emulate CVDG
  docs/about: Deprecate the old "power5+" and "power7+" CPU names
  target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules
  hw/scsi/lsi53c895a: add missing decrement of reentrancy counter

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agoMerge tag 'mem-2024-02-06-v3' of https://github.com/davidhildenbrand/qemu into staging
Peter Maydell [Thu, 8 Feb 2024 11:59:13 +0000 (11:59 +0000)]
Merge tag 'mem-2024-02-06-v3' of https://github.com/davidhildenbrand/qemu into staging

Hi,

"Host Memory Backends" and "Memory devices" queue ("mem"):
- Reintroduce memory region size checks for memory devices; the removal
  lead to some undesired side effects
- Preallocate memory of memory backends in selected configurations
  asynchronously (so we preallocate concurrently), to speed up QEMU
  startup time.

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmXB3LcRHGRhdmlkQHJl
# ZGhhdC5jb20ACgkQTd4Q9wD/g1plRA/+N8y4aJB+qEwacl5scIpiWShqeBA0aybS
# Rp3796djgjkqozkv7AFGHrOIGiLDtCh4W1JYuML7kLN7IvuJoHSY+AHzfhDiae1l
# eluX/Cs/5rgEninwT9M0yEkgvUybA8+kx+z96hBJgkfJOrdbETc7YVbU5iP/sOOF
# UtfEVWGwT1RJOun0qrgEhHiJCTMcHyJjSEy8D867ymC+knu3OZIz22+axcmpHz6i
# QJFgY40OCP1yxBvPVLR3K/Z0se/FkxG55LwM58j7N/m+VDv4IqZCTbkZb5BTJVla
# 5vKgIrZfZ+XFqrenyMsBnBLgQuyCmDJIDFfxM0A9gOvJbwtf8T4DhL9FoRvVZMDD
# SHBl/EZcViXFDDKVHjotBSA5JoNbjHac5J5jCFu7pRq+2DbzxWHmW6xV7sY9gkSO
# +SdW9hcmF/vF5MKHfoQR2kVLLJ2/EKHiN/xVVsha0+RQDctucrhg1Y9MS2obJV3u
# u2udaVk5UNcfNPuVPwkG8YQ0sIyuDYXOTThwNtsj0tyZ+tGVQmMIlou/GAsrc9PF
# xmqzkCXXyrILrPMQJrYBcdwasBLuEcJMW59BqgxHCVP9NiAQgsNVzXFg4mr3+mVF
# xTrt8wioTvAPoDvXe+BPoaH6AsIY2TqE8j7IqA1Q/IFNf+KLYkPcHknZfzfxSkdW
# woRHVtjrkMo=
# =lW5h
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 06 Feb 2024 07:16:07 GMT
# gpg:                using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A
# gpg:                issuer "david@redhat.com"
# gpg: Good signature from "David Hildenbrand <david@redhat.com>" [marginal]
# gpg:                 aka "David Hildenbrand <davidhildenbrand@gmail.com>" [full]
# gpg:                 aka "David Hildenbrand <hildenbr@in.tum.de>" [unknown]
# Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D  FCCA 4DDE 10F7 00FF 835A

* tag 'mem-2024-02-06-v3' of https://github.com/davidhildenbrand/qemu:
  oslib-posix: initialize backend memory objects in parallel
  memory-device: reintroduce memory region size check
  hv-balloon: use get_min_alignment() to express 32 GiB alignment

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
14 months agovirtio-blk: avoid using ioeventfd state in irqfd conditional
Stefan Hajnoczi [Mon, 22 Jan 2024 17:26:25 +0000 (12:26 -0500)]
virtio-blk: avoid using ioeventfd state in irqfd conditional

Requests that complete in an IOThread use irqfd to notify the guest
while requests that complete in the main loop thread use the traditional
qdev irq code path. The reason for this conditional is that the irq code
path requires the BQL:

  if (s->ioeventfd_started && !s->ioeventfd_disabled) {
      virtio_notify_irqfd(vdev, req->vq);
  } else {
      virtio_notify(vdev, req->vq);
  }

There is a corner case where the conditional invokes the irq code path
instead of the irqfd code path:

  static void virtio_blk_stop_ioeventfd(VirtIODevice *vdev)
  {
      ...
      /*
       * Set ->ioeventfd_started to false before draining so that host notifiers
       * are not detached/attached anymore.
       */
      s->ioeventfd_started = false;

      /* Wait for virtio_blk_dma_restart_bh() and in flight I/O to complete */
      blk_drain(s->conf.conf.blk);

During blk_drain() the conditional produces the wrong result because
ioeventfd_started is false.

Use qemu_in_iothread() instead of checking the ioeventfd state.

Cc: qemu-stable@nongnu.org
Buglink: https://issues.redhat.com/browse/RHEL-15394
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240122172625.415386-1-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agovirtio-blk: Use ioeventfd_attach in start_ioeventfd
Hanna Czenczek [Fri, 2 Feb 2024 15:31:58 +0000 (16:31 +0100)]
virtio-blk: Use ioeventfd_attach in start_ioeventfd

Commit d3f6f294aeadd5f88caf0155e4360808c95b3146 ("virtio-blk: always set
ioeventfd during startup") has made virtio_blk_start_ioeventfd() always
kick the virtqueue (set the ioeventfd), regardless of whether the BB is
drained.  That is no longer necessary, because attaching the host
notifier will now set the ioeventfd, too; this happens either
immediately right here in virtio_blk_start_ioeventfd(), or later when
the drain ends, in virtio_blk_ioeventfd_attach().

With event_notifier_set() removed, the code becomes the same as the one
in virtio_blk_ioeventfd_attach(), so we can reuse that function.

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-4-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agovirtio: Re-enable notifications after drain
Hanna Czenczek [Fri, 2 Feb 2024 15:31:57 +0000 (16:31 +0100)]
virtio: Re-enable notifications after drain

During drain, we do not care about virtqueue notifications, which is why
we remove the handlers on it.  When removing those handlers, whether vq
notifications are enabled or not depends on whether we were in polling
mode or not; if not, they are enabled (by default); if so, they have
been disabled by the io_poll_start callback.

Because we do not care about those notifications after removing the
handlers, this is fine.  However, we have to explicitly ensure they are
enabled when re-attaching the handlers, so we will resume receiving
notifications.  We do this in virtio_queue_aio_attach_host_notifier*().
If such a function is called while we are in a polling section,
attaching the notifiers will then invoke the io_poll_start callback,
re-disabling notifications.

Because we will always miss virtqueue updates in the drained section, we
also need to poll the virtqueue once after attaching the notifiers.

Buglink: https://issues.redhat.com/browse/RHEL-3934
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-3-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agovirtio-scsi: Attach event vq notifier with no_poll
Hanna Czenczek [Fri, 2 Feb 2024 15:31:56 +0000 (16:31 +0100)]
virtio-scsi: Attach event vq notifier with no_poll

As of commit 38738f7dbbda90fbc161757b7f4be35b52205552 ("virtio-scsi:
don't waste CPU polling the event virtqueue"), we only attach an io_read
notifier for the virtio-scsi event virtqueue instead, and no polling
notifiers.  During operation, the event virtqueue is typically
non-empty, but none of the buffers are intended to be used immediately.
Instead, they only get used when certain events occur.  Therefore, it
makes no sense to continuously poll it when non-empty, because it is
supposed to be and stay non-empty.

We do this by using virtio_queue_aio_attach_host_notifier_no_poll()
instead of virtio_queue_aio_attach_host_notifier() for the event
virtqueue.

Commit 766aa2de0f29b657148e04599320d771c36fd126 ("virtio-scsi: implement
BlockDevOps->drained_begin()") however has virtio_scsi_drained_end() use
virtio_queue_aio_attach_host_notifier() for all virtqueues, including
the event virtqueue.  This can lead to it being polled again, undoing
the benefit of commit 38738f7dbbda90fbc161757b7f4be35b52205552.

Fix it by using virtio_queue_aio_attach_host_notifier_no_poll() for the
event virtqueue.

Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Fixes: 766aa2de0f29b657148e04599320d771c36fd126
       ("virtio-scsi: implement BlockDevOps->drained_begin()")
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-2-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agoblkio: Respect memory-alignment for bounce buffer allocations
Kevin Wolf [Wed, 31 Jan 2024 17:31:40 +0000 (18:31 +0100)]
blkio: Respect memory-alignment for bounce buffer allocations

blkio_alloc_mem_region() requires that the requested buffer size is a
multiple of the memory-alignment property. If it isn't, the allocation
fails with a return value of -EINVAL.

Fix the call in blkio_resize_bounce_pool() to make sure the requested
size is properly aligned.

I observed this problem with vhost-vdpa, which requires page aligned
memory. As the virtio-blk device behind it still had 512 byte blocks, we
got bs->bl.request_alignment = 512, but actually any request that needed
a bounce buffer and was not aligned to 4k would fail without this fix.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240131173140.42398-1-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agoscsi: Don't ignore most usb-storage properties
Kevin Wolf [Wed, 31 Jan 2024 13:06:07 +0000 (14:06 +0100)]
scsi: Don't ignore most usb-storage properties

usb-storage is for the most part just a wrapper around an internally
created scsi-disk device. It uses DEFINE_BLOCK_PROPERTIES() to offer all
of the usual block device properties to the user, but then only forwards
a few select properties to the internal device while the rest is
silently ignored.

This changes scsi_bus_legacy_add_drive() to accept a whole BlockConf
instead of some individual values inside of it so that usb-storage can
now pass the whole configuration to the internal scsi-disk. This enables
the remaining block device properties, e.g. logical/physical_block_size
or discard_granularity.

Buglink: https://issues.redhat.com/browse/RHEL-22375
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240131130607.24117-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
14 months agovirtio-blk: do not use C99 mixed declarations
Stefan Hajnoczi [Tue, 6 Feb 2024 14:04:09 +0000 (09:04 -0500)]
virtio-blk: do not use C99 mixed declarations

QEMU's coding style generally forbids C99 mixed declarations.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206140410.65650-1-stefanha@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>