aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-07acpi: pci: drop BSEL usage when deciding that device isn't hotpluggableIgor Mammedov
previous commit ("pci: fix 'hotplugglable' property behavior") fixed pcie root port's 'hotpluggable' property to behave consistently. So we don't need a BSEL crutch anymore to see of device is not hotpluggable, drop it from 'generic' PCI slots description handling. BSEL is still used to decide if hotplug part should be called but that will be moved out of generic code to hotplug one by followup patches. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-31-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pci: move acpi-index uniqueness check to generic PCI device codeIgor Mammedov
acpi-index is now working with non-hotpluggable buses (pci/q35 machine hostbridge), it can be used even if ACPI PCI hotplug is disabled and as result acpi-index uniqueness check will be omitted (since the check is done by ACPI PCI hotplug handler, which isn't wired when ACPI PCI hotplug is disabled). Move check and related code to generic PCIDevice so it would be independent of ACPI PCI hotplug. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-30-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
an extra devices at non-zero function address with static _DSM method get exposed, ex: + Device (S15) + { + Name (_ADR, 0x00020005) // _ADR: Address + Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method + { + Local0 = Package (0x01) + { + 0x66 + } + Return (EDSM (Arg0, Arg1, Arg2, Arg3, Local0)) + } + } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-29-imammedo@redhat.com>
2023-03-07tests: acpi: add non zero function device with acpi-index on non-hotpluggble busIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-28-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist DSDT before adding non-0 function device with ↵Igor Mammedov
acpi-index to testcases Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-27-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
in PC machine case piix3-ide and PIIX4_PM get exposed + Device (S09) + { + Name (_ADR, 0x00010001) // _ADR: Address + } + + Device (S0B) + { + Name (_ADR, 0x00010003) // _ADR: Address + } in q35 machine case ich9-ahci gets exposed + Device (SFA) + { + Name (_ADR, 0x001F0002) // _ADR: Address + } and addtional pci-testdev, virtio-balloon exposed in q35 multi-bridge test case + Device (S14) + { + Name (_ADR, 0x00020004) // _ADR: Address + } + ... + Device (S22) + { + Name (_ADR, 0x00040002) // _ADR: Address + } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-26-imammedo@redhat.com>
2023-03-07acpi: pci: describe all functions on populated slotsIgor Mammedov
describing all present devices on functions other than 0 was complicated when non hotplug and hotplug code was intermixed. So QEMU has been excluding non zero functions since they are not supported by hotplug code, then a condition to whitelist coldplugged bridges was added and later whitelisting of devices that advertise presence of their own AML description. With non hotplug and hotplug code separated, it is possible to relax rules and allow describing all non-hotpluggble functions and hence simplify conditions whether PCI device should be enumerated by generic (non-hotplug) code. Price of that simplification is an extra few Device() descriptors in DSDT exposing built-in chipset functions, which has no functional effect on guest side. Apart from that, the enumeration of non zero functions, allows to attach more NICs with acpi-index enabled directly on hostbridge (if hotplug is not required). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-25-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist DSDT before exposing non zero functionsIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-24-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
the only chenge is addition of _DSM- > EDSM method on non-hotpluggable devices with configured acpi-index. Something like: + Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method + { + Local0 = Package (0x01) + { + 0x65 + } + Return (EDSM (Arg0, Arg1, Arg2, Arg3, Local0)) + } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-23-imammedo@redhat.com>
2023-03-07acpi: pci: support acpi-index for non-hotpluggable devicesIgor Mammedov
Inject static _DSM (EDSM) if non-hotpluggable device has acpi-index configured on it. It lets use acpi-index non-hotpluggable devices / devices attached to non-hotpluggable bus. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-22-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: add device with acpi-index on non-hotpluggble busIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-21-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist DSDT before adding device with acpi-index to testcasesIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-20-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-19-imammedo@redhat.com>
2023-03-07acpi: pci: add EDSM method to DSDTIgor Mammedov
it's a helper method for acpi-index support on PCI buses that do no support or have disabled ACPI PCI hotplug or for non-hotpluggble endpoint devices. (like non-hotpluggble NICs, integrated endpoints and later for machines that do not support ACPI PCI hotplug) no functional change, commit adds only EDSM method in DSDT without any users. (the follow up patches will use it) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-18-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist DSDT before adding EDSM methodIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-17-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
only following context change: - Local1 = Zero If ((Arg0 != ToUUID ("e5c937d0-3553-4d7a-9117-ea4d19c3434d") /* Device Labeling Interface */)) { Return (Local0) ... Return (Local0) } + Local1 = Zero Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One] Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-16-imammedo@redhat.com>
2023-03-07pcihp: move PCI _DSM function 0 prolog into separate functionIgor Mammedov
it will be reused by follow up patches that will implement static _DSM for non-hotpluggable devices. no functional AML change, only context one, where 'cap' (Local1) initialization is moved after UUID/revision checks. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-15-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist DSDT blobs before isolating PCI _DSM func 0 prologIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-14-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pci: fix 'hotplugglable' property behaviorIgor Mammedov
Currently the property may flip its state during VM bring up or just doesn't work as the name implies. In particular with PCIE root port that has 'hotplug={on|off}' property, and when it's turned off, one would expect 'hotpluggable' == false for any devices attached to it. Which is not the case since qbus_is_hotpluggable() used by the property just checks for presence of any hotplug_handler set on bus. The problem is that name BusState::hotplug_handler from its inception is misnomer, as it handles not only hotplug but also in many cases coldplug as well (i.e. generic wiring interface), and it's fine to have hotplug_handler set on bus while it doesn't support hotplug (ex. pcie-slot with hotplug=off). Another case of root port flipping 'hotpluggable' state when ACPI PCI hotplug is enabled in this case root port with 'hotplug=off' starts as hotpluggable and then later on, pcihp hotplug_handler clears hotplug_handler explicitly after checking root port's 'hotplug' property. So root-port hotpluggablity check sort of works if pcihp is enabled but is broken if pcihp is disabled. One way to deal with the issue is to ask hotplug_handler if bus it controls is hotpluggable or not. To do that add is_hotpluggable_bus() hook to HotplugHandler interface and use it in 'hotpluggable' property + teach pcie-slot to actually look into 'hotplug' property state before deciding if bus is hotpluggable. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-13-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pcihp: piix4: do not redirect hotplug controller to piix4 when ACPI hotplug ↵Igor Mammedov
is disabled commit [1] added ability to disable ACPI PCI hotplug on hostbridge but forgot to take into account that it should disable all ACPI hotplug machinery in case both hostbridge and bridge hotplug are disabled. Commit [2] tried to fix that, however it forgot to remove hotplug_handler override which hands hotplug control over to piix4 hotplug controller (uninitialized after [2]). As result at the time bridge is plugged in, its default (SHPC) hotplug handler is replaced by piix4 one in acpi_pcihp_device_plug_cb() ... if (!s->legacy_piix && ... qbus_set_hotplug_handler(BUS(sec), OBJECT(hotplug_dev)); which is acting on uninitialized s->legacy_piix value (0 by default) that was supposed to be initialized by acpi_pcihp_init(), that is no longer called due to following condition being false: piix4_acpi_system_hot_add_init() if (s->use_acpi_hotplug_bridge || s->use_acpi_root_pci_hotplug) { and the bridge ends up with piix4 as hotplug handler instead of shpc one. Followup hotplug on that bridge as result yields piix4 specific error: Error: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set 1) 3d7e78aa777 (Introduce a new flag for i440fx to disable PCI hotplug on the root bus) 2) df4008c9c59 (piix4: don't reserve hw resources when hotplug is off globally) Fixes: df4008c9c59 (piix4: don't reserve hw resources when hotplug is off globally) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-12-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
BNUM numbering changes across DSDT due to addition of new bridges. Fixed missing PCI tree brunch (q35/DSDT.multi-bridge case): // -device pcie-root-port,id=rpnohp,chassis=8,addr=0xA.0,hotplug=off + Device (S50) + { + Name (_ADR, 0x000A0000) // _ADR: Address // -device pcie-root-port,id=rp3,chassis=9,bus=rpnohp + Device (S00) + { + Name (_ADR, Zero) // _ADR: Address + Name (BSEL, Zero) + Device (S00) + { + Name (_ADR, Zero) // _ADR: Address + Name (ASUN, Zero) + Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method + { + Local0 = Package (0x02) + { + BSEL, + ASUN + } + Return (PDSM (Arg0, Arg1, Arg2, Arg3, Local0)) + } + + Name (_SUN, Zero) // _SUN: Slot User Number + Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device + { + PCEJ (BSEL, _SUN) + } + } + + Method (DVNT, 2, NotSerialized) + { + If ((Arg0 & One)) + { + Notify (S00, Arg1) + } + } + } + } Fixed hotplug notification for leaf root port (hotplug=on) attached to intermediate root port (hotplug=off) (q35/DSDT.multi-bridge case) // -device pcie-root-port,id=rpnohp,chassis=8,addr=0xA.0,hotplug=off + Scope (S50) + { // -device pcie-root-port,id=rp3,chassis=9,bus=rpnohp + Scope (S00) + { + Method (PCNT, 0, NotSerialized) + { + BNUM = Zero + DVNT (PCIU, One) + DVNT (PCID, 0x03) + } + } + + Method (PCNT, 0, NotSerialized) + { + ^S00.PCNT () + } + } ... Method (PCNT, 0, NotSerialized) { + ^S50.PCNT () ^S13.PCNT () Populated slots being described on coldplugged bridges even if ACPI bridge hotplug is disabled. (pc/DSDT.hpbridge and pc/DSDT.hpbrroot) ... Device (S18) { Name (_ADR, 0x00030000) // _ADR: Address + Device (S08) + { + Name (_ADR, 0x00010000) // _ADR: Address + } + + Device (S10) + { + Name (_ADR, 0x00020000) // _ADR: Address + } } ... Device (S18) { Name (_ADR, 0x00030000) // _ADR: Address + Device (S00) + { + Name (_ADR, Zero) // _ADR: Address + } } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-11-imammedo@redhat.com>
2023-03-07x86: pcihp: fix missing bridge AML when intermediate root-port has ↵Igor Mammedov
'hotplug=off' set (I practice [1] hasn't broke anything since on hardware side we unset hotplug_handler on such intermediate port => hotplug behind it has never worked) When deciding if bridge should be described, the original condition was cold_plugged_bridge && pcihp_bridge_en which was replaced [1] by bridge has ACPI_PCIHP_PROP_BSEL the later however is not the same thing as the original and flips to false if intermediate bridge has hotplug turned off (root-port with 'hotplug=off' option). Since we already in build_pci_bridge_aml(), the question if it's bridge is answered. Use DeviceState::hotplugged to make decision if bridge should describe its slots. What's left out is pcihp_bridge_en, which tells us if ACPI bridge hotplug is enabled. With hotplug and non hotplug part now being mostly separated, omitting this check will only lead to colplugged bridges describe occupied slots in case when ACPI bridge hotplug is disabled. Which makes behavior consistent with occupied slots on hostbridge. Ex (pc/DSDT.hpbrroot diff): ... Device (S20) { Name (_ADR, 0x00040000) // _ADR: Address + Device (S08) + { + Name (_ADR, 0x00010000) // _ADR: Address + } + + Device (S10) + { + Name (_ADR, 0x00020000) // _ADR: Address + } } ... PS: testing shows that above doesn't affect adversely guest OS behavior: i.e. if ACPI bridge hotplug is enabled it's expected behaviour, and with ACPI bridge hotplug is disabled (a.k. native hotplug), it doesn't break slot enumeration nor native hotplug. (tested with RHEL9.0 and WS2022). 1) Fixes: 6c36ec46b0d ("pcihp: make bridge describe itself using AcpiDevAmlIfClass:build_dev_aml") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-10-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist pc/DSDT.hpbrroot and pc/DSDT.hpbridge testsIgor Mammedov
follow up fix for missing root-port AML will affect these tests by adding non-hotpluggable Device descriptors of colplugged bridges when bridge hotplug is disabled. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-9-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07x86: pcihp: fix missing PCNT callchain when intermediate root-port has ↵Igor Mammedov
'hotplug=off' set Beside BSEL numbers change (due to 2 extra root-ports in q35/miltibridge test), following change is expected: Scope (\_SB.PCI0) { ... + Scope (S50) + { + Scope (S00) + { + Method (PCNT, 0, NotSerialized) + { + BNUM = Zero + DVNT (PCIU, One) + DVNT (PCID, 0x03) + } + } + + Method (PCNT, 0, NotSerialized) + { + ^S00.PCNT + } + } ... Method (PCNT, 0, NotSerialized) { + ^S50.PCNT () ^S13.PCNT () ^S12.PCNT () ^S11.PCNT () I practice [1] hasn't broke anything since on hardware side we unset hotplug_handler on such intermediate port => hotplug behind it has not been properly wired and as result not worked. 1) Fixes: ddab4d3fae4e8 ("pcihp: compose PCNT callchain right before its user _GPE._E01") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-8-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: extend multi-bridge case with case ↵Igor Mammedov
'root-port,id=HOHP,hotplug=off root-port,bus=NOHP' Following corner case wasn't covered: -device pcie-root-port,id=NO_HOTPLUG,hotplug=off -device pcie-root-port,bus=NO_HOTPLUG when intermediate root-port has explicitly disabled hotplug, all hierarchy below it is not described anymore (used to be described in 7.2) So as result we see only NO_HOTPLUG root-port described + Device (S50) + { + Name (_ADR, 0x000A0000) // _ADR: Address + } and no children nor notification chain for them are being composed. Follow up patches will fix missing leaf root-port descriptor and notification chain that should accompany it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-7-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist q35/DSDT.multi-bridge before extending testcaseIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-6-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: update expected blobsIgor Mammedov
expected changes: Basically adds devices present on root bus in form: Device (SXX) { Name (_ADR, 0xYYYYYYYY) // _ADR: Address } On top of that For q35.noacpihp, all ACPI PCI hotplug AML is removed and _OSC get native hotplug enabled: CreateDWordField (Arg3, 0x04, CDW2) CreateDWordField (Arg3, 0x08, CDW3) Local0 = CDW3 /* \_SB_.PCI0._OSC.CDW3 */ - Local0 &= 0x1E + Local0 &= 0x1F If ((Arg1 != One)) { CDW1 |= 0x08 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-5-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: add test_acpi_q35_tcg_no_acpi_hotplug test and extend ↵Igor Mammedov
test_acpi_piix4_no_acpi_pci_hotplug test bridge AML generator with ACPI PCI hotplug disabled (i.e. with native hotplug enabled/disabled per bridge/root port) PS: while at make sure that devices on pci-bridge are starting from addr=1.0 as slot 0 is not available there and test passes only because of a bug in ACPI hotplug that will be fixed by follow up patch Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07tests: acpi: whitelist new q35.noacpihp test and pc.hpbrrootIgor Mammedov
for q35.noacpihp use plain default Q35 DSDT table as a starting point. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07Revert "tests/qtest: Check for devices in bios-tables-test"Igor Mammedov
This reverts commit c471eb4f40445908c1be7bb11a37ac676a0edae7. which broke acpi tables test and rebuild due to skipping some tests even thought none of devices tests depend on weren't disabled. As result it leads to some expected tables not being updated, merge conflicts and tests failure. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-2-imammedo@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: return VHOST_F_LOG_ALL in vhost-vdpa devicesEugenio Pérez
vhost-vdpa devices can return this feature now that blockers have been set in case some features are not met. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-15-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa net: allow VHOST_F_LOG_ALLEugenio Pérez
Since some actions move to the start function instead of init, the device features may not be the parent vdpa device's, but the one returned by vhost backend. If transition to SVQ is supported, the vhost backend will return _F_LOG_ALL to signal the device is migratable. Add VHOST_F_LOG_ALL. HW dirty page tracking can be added on top of this change if the device supports it in the future. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-14-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: block migration if SVQ does not admit a featureEugenio Pérez
Next patches enable devices to be migrated even if vdpa netdev has not been started with x-svq. However, not all devices are migratable, so we need to block migration if we detect that. Block migration if we detect the device expose a feature SVQ does not know how to work with. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-13-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: block migration if device has unsupported featuresEugenio Pérez
A vdpa net device must initialize with SVQ in order to be migratable at this moment, and initialization code verifies some conditions. If the device is not initialized with the x-svq parameter, it will not expose _F_LOG so the vhost subsystem will block VM migration from its initialization. Next patches change this, so we need to verify migration conditions differently. QEMU only supports a subset of net features in SVQ, and it cannot migrate state that cannot track or restore in the destination. Add a migration blocker if the device offers an unsupported feature. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-12-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa net: block migration if the device has CVQEugenio Pérez
Devices with CVQ need to migrate state beyond vq state. Leaving this to future series. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-11-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: disable RAM block discard only for the first deviceEugenio Pérez
Although it does not make a big difference, its more correct and simplifies the cleanup path in subsequent patches. Move ram_block_discard_disable(false) call to the top of vhost_vdpa_cleanup because: * We cannot use vhost_vdpa_first_dev after dev->opaque = NULL assignment. * Improve the stack order in cleanup: since it is the last action taken in init, it should be the first at cleanup. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-10-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: add vdpa net migration state notifierEugenio Pérez
This allows net to restart the device backend to configure SVQ on it. Ideally, these changes should not be net specific and they could be done in: * vhost_vdpa_set_features (with VHOST_F_LOG_ALL) * vhost_vdpa_set_vring_addr (with .enable_log) * vhost_vdpa_set_log_base. However, the vdpa net backend is the one with enough knowledge to configure everything because of some reasons: * Queues might need to be shadowed or not depending on its kind (control vs data). * Queues need to share the same map translations (iova tree). Also, there are other problems that may have solutions but complicates the implementation at this stage: * We're basically duplicating vhost_dev_start and vhost_dev_stop, and they could go out of sync. If we want to reuse them, we need a way to skip some function calls to avoid recursiveness (either vhost_ops -> vhost_set_features, vhost_set_vring_addr, ...). * We need to traverse all vhost_dev of a given net device twice: one to stop and get the vq state and another one after the reset to configure properties like address, fd, etc. Because of that it is cleaner to restart the whole net backend and configure again as expected, similar to how vhost-kernel moves between userspace and passthrough. If more kinds of devices need dynamic switching to SVQ we can: * Create a callback struct like VhostOps and move most of the code there. VhostOps cannot be reused since all vdpa backend share them, and to personalize just for networking would be too heavy. * Add a parent struct or link all the vhost_vdpa or vhost_dev structs so we can traverse them. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-9-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: move vhost reset after get vring baseEugenio Pérez
The function vhost.c:vhost_dev_stop calls vhost operation vhost_dev_start(false). In the case of vdpa it totally reset and wipes the device, making the fetching of the vring base (virtqueue state) totally useless. The kernel backend does not use vhost_dev_start vhost op callback, but vhost-user do. A patch to make vhost_user_dev_start more similar to vdpa is desirable, but it can be added on top. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-8-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: add vhost_vdpa_suspendEugenio Pérez
The function vhost.c:vhost_dev_stop fetches the vring base so the vq state can be migrated to other devices. However, this is unreliable in vdpa, since we didn't signal the device to suspend the queues, making the value fetched useless. Suspend the device if possible before fetching first and subsequent vring bases. Moreover, vdpa totally reset and wipes the device at the last device before fetch its vrings base, making that operation useless in the last device. This will be fixed in later patches of this series. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-7-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: add vhost_vdpa->suspended parameterEugenio Pérez
This allows vhost_vdpa to track if it is safe to get the vring base from the device or not. If it is not, vhost can fall back to fetch idx from the guest buffer again. No functional change intended in this patch, later patches will use this field. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-6-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: rewind at get_base, not set_baseEugenio Pérez
At this moment it is only possible to migrate to a vdpa device running with x-svq=on. As a protective measure, the rewind of the inflight descriptors was done at the destination. That way if the source sent a virtqueue with inuse descriptors they are always discarded. Since this series allows to migrate also to passthrough devices with no SVQ, the right thing to do is to rewind at the source so the base of vrings are correct. Support for inflight descriptors may be added in the future. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-5-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: Negotiate _F_SUSPEND featureEugenio Pérez
This is needed for qemu to know it can suspend the device to retrieve its status and enable SVQ with it, so all the process is transparent to the guest. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-4-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: Remember last call fd setEugenio Pérez
As SVQ can be enabled dynamically at any time, it needs to store call fd always. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-3-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa net: move iova tree creation from init to startEugenio Pérez
Only create iova_tree if and when it is needed. The cleanup keeps being responsible for the last VQ but this change allows it to merge both cleanup functions. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-2-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07MAINTAINERS: add myself as the maintainer for cryptodevzhenwei pi
I developed the akcipher service, QoS setting, QMP/HMP commands and statistics accounting for crypto device. Making myself as the maintainer for QEMU's cryptodev. Cc: Gonglei <arei.gonglei@huawei.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-13-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07cryptodev: Support query-stats QMP commandzhenwei pi
Now we can use "query-stats" QMP command to query statistics of crypto devices. (Originally this was designed to show statistics by '{"execute": "query-cryptodev"}'. Daniel Berrangé suggested that querying configuration info by "query-cryptodev", and querying runtime performance info by "query-stats". This makes sense!) Example: ~# virsh qemu-monitor-command vm '{"execute": "query-stats", \ "arguments": {"target": "cryptodev"} }' | jq { "return": [ { "provider": "cryptodev", "stats": [ { "name": "asym-verify-bytes", "value": 7680 }, ... { "name": "asym-decrypt-ops", "value": 32 }, { "name": "asym-encrypt-ops", "value": 48 } ], "qom-path": "/objects/cryptodev0" # support asym only }, { "provider": "cryptodev", "stats": [ { "name": "asym-verify-bytes", "value": 0 }, ... { "name": "sym-decrypt-bytes", "value": 5376 }, ... ], "qom-path": "/objects/cryptodev1" # support asym/sym } ], "id": "libvirt-422" } Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-12-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07cryptodev: support QoSzhenwei pi
Add 'throttle-bps' and 'throttle-ops' limitation to set QoS. The two arguments work with both QEMU command line and QMP command. Example of QEMU command line: -object cryptodev-backend-builtin,id=cryptodev1,throttle-bps=1600,\ throttle-ops=100 Example of QMP command: virsh qemu-monitor-command buster --hmp qom-set /objects/cryptodev1 \ throttle-ops 100 or cancel limitation: virsh qemu-monitor-command buster --hmp qom-set /objects/cryptodev1 \ throttle-ops 0 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-11-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07cryptodev: Account statisticszhenwei pi
Account OPS/BPS for crypto device, this will be used for 'query-stats' QEMU monitor command and QoS in the next step. Note that a crypto device may support symmetric mode, asymmetric mode, both symmetric and asymmetric mode. So we use two structure to describe the statistics of a crypto device. Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-10-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-03-07cryptodev: Use CryptoDevBackendOpInfo for operationzhenwei pi
Move queue_index, CryptoDevCompletionFunc and opaque into struct CryptoDevBackendOpInfo, then cryptodev_backend_crypto_operation() needs an argument CryptoDevBackendOpInfo *op_info only. And remove VirtIOCryptoReq from cryptodev. It's also possible to hide VirtIOCryptoReq into virtio-crypto.c in the next step. (In theory, VirtIOCryptoReq is a private structure used by virtio-crypto only) Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-9-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07hmp: add cryptodev info commandzhenwei pi
Example of this command: # virsh qemu-monitor-command vm --hmp info cryptodev cryptodev1: service=[akcipher|mac|hash|cipher] queue 0: type=builtin cryptodev0: service=[akcipher] queue 0: type=lkcf Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-8-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>