| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
Logs changes to NV_PMC_BOOT_1 (0x4), the low PCFG alias, the BAR0 PCFG
block (0x880000/0x880080/0x880084/0x880088/0x88008c) and the VF-window
aliases. Observed during a CUDA run: the guest never writes any of them,
so the link-cap values we pre-set (0x103 / 0x01030000) are not clobbered.
Reads are not observable through the mmap'd BAR0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CUDA (cuInit) now reaches UVM's device create: libcuda opens nvidia-uvm,
UVM calls nvGpuOpsDeviceCreate/gpuGetGpuInfo, and the driver fails at
getPCIELinkRateMBps -> calculatePCIELinkRateMBps ("Unknown PCIe speed",
NV_ERR_INVALID_STATE) -> nv_open_device aborts -> cuInit returns
CUDA_ERROR_NOT_INITIALIZED (3).
Implemented along the way:
- FB_GET_INFO_V2 (0x20801303): echo the requested FB info indices and
answer TU104 values (256MB RAM/heap/BAR1, GDDR6, 8 LTCs, 4MB L2, ...).
Fixes the kern_mem_sys_ctrl.c:911 asserts and gives CUDA/UVM real
memory sizes.
- BUS_GET_INFO_V2 (0x20801823): echo indices; PCIe Gen3 x16 link caps /
GEN info / link status, SYSMEM_CONNECTION_TYPE=PCIE. UVM's
gpuGetSysmemLinkInfo reads SYSMEM_CONNECTION_TYPE and the nominal link
bandwidth from here.
- PCIe Link Capabilities in the emulated config space (0x8C/0x92) and in
the BAR0 PCFG mirror (gpuReadBusConfigReg -> NV_PCFG+0x84 = BAR0+
0x88084): MAX_SPEED=3 (8GT/s Gen3), MAX_WIDTH=0x10 (x16); link status
mirror at 0x88088. Also mirrored under the VF-window/low aliases.
- Temporary change-watch on PCFG[0x88084] to see if the guest overwrites
it (it does not - stays 0x103).
Verified: guest nvidia-smi -L still works and reports PCIe Generation
Max/Current = 3. cuInit still fails; the remaining question is which
address the driver's kbifGetGpuLinkCapabilities read sees as zero (the
PCFG shadow holds 0x103). Guest-side kprobe tracing of that function
panicked the VM (free_swap_cache page fault on a corrupted pointer) -
possible guest memory corruption to investigate separately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Root cause of the golden-image NV_ERR_NO_MEMORY: STATIC_KGR_GET_CONTEXT_
BUFFERS_INFO (0x20800a32) fell through to the generic zeroed reply, so
kgraphicsInitializeDeferredStaticData() stored a 0-byte main ctx buffer
size and kgrctxAllocMainCtxBuffer() did a 0-page allocation
(mem_desc.c:1353). Serve the TU104 per-engine ctx buffer table (26 engine
IDs x 8 GR engines; NV_U32_MAX = unsupported, which the client skips).
Second blocker after that: L2 cache-op and TLB-invalidate completion
registers. Turing reaches them through the virtual-register window
(GPU_VREG_* = BAR0 + sriovState.virtualRegPhysOffset + offset, 0xB80000
for a non-SRIOV virtual GPU): NV_VIRTUAL_FUNCTION_PRIV_MMU_INVALIDATE
(0xB830B0, TRIGGER bit31) and the L2 invalidate/dirty-flush set
(0x70000-0x70014 and 0xB80F00/0xB80F04). The driver soft-locked spinning
in osDevReadReg032 on 0xB830B4 (kgmmuCheckPendingInvalidates_TU102) and
timed out in kmemsysDoCacheOp_GM107; auto-clear all of them (both the
plain and windowed aliases).
Third: re-probe failed with GspStatusQueueInit msgqRxLink timeout because
gsp_rm_emu_reset() was not called before a fresh boot, leaving rm->parsed
set so the new libos args were never parsed. Reset GSP-RM state on the
fresh FWSEC kick.
Verified: guest nvidia-smi and nvidia-smi -L both exit 0 (full
unload/reload cycle), GPU enumerated as "NVIDIA GeForce RTX 2080 SUPER"
with 256MB, no NO_MEMORY / timeouts / soft lockups in the guest.
Also add tools/rmq/grctx_oracle.c documenting that the host RM does not
expose the ctx-buffer table to userspace (the real values are probed from
the ctxsw ucode by GSP-RM), so the emulation serves synthesized sizes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocator
Fixes the BAR2 verify test (kbusVerifyBar2_GM107):
1. Removed PRAMIN window sync from emulated BAR1 - the sync was overwriting
test data written by the driver through the vBar2 aperture. The shadow
BAR0 is already consistent (guest writes/reads hit the same shadow location).
2. Added contiguous page allocation for golden image (alloc_pages with order
for large allocations, falling back to individual pages).
3. Added vidmem VA allocator - ALLOC now returns GPU VAs within the emulated
GPU's vidmem range (0x100000 - fb_size) instead of default 4GB, so the
memmgr accepts them.
Verified: driver probes past RmInitNvDevice bus init, reaches golden image
channel allocation (progress from fn-10 FREE timeout).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the BAR2 verify test failure (kbusVerifyBar2_GM107):
- GSP emulation thread now watches NV_PBUS_BAR0_WINDOW (BAR0+0x1700) for
base/target changes and syncs the PRAMIN window (BAR0+0x700000) from the
emulated BAR1 (vidmem) at (base << 16). This makes PRAMIN reads return
correct vidmem content for the BAR2 verify test.
Fixes the fn-10 FREE timeout during driver cleanup:
- gsp_emu_clear_boot_state no longer resets the GSP-RM queue state on
Booter-unload kick. The driver sends cleanup FREEs AFTER the Booter-unload
kick; resetting the queue here caused those frees to time out.
- Queue state is now only reset on: ENGINE reset (full GPU reset) or
genuine queue death (insane writePtr). Both call gsp_rm_emu_reset
explicitly.
Also fixes rmq tool ioctl encoding:
- Use _IOWR('F', nr, type) encoding for NVIDIA ioctls (was raw numbers)
- Open /dev/nvidiactl (not /dev/nvidia0) for RM_ALLOC
- Add NVOS64_PARAMETERS (48 bytes) for device/subdevice allocs
Verified: BAR2 verify test passes, INSTLOC regkey read, driver probes
past RmInitNvDevice bus init, reaches fn-10 FREE timeout during cleanup
(same as handoff's characterized blocker).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- STATIC_KGR_GET_FLOORSWEEPING_MASKS(0x20800a26): TU104 gpcMask=0x3f
(6 GPCs), 4 TPC/GPC. numGpcs==0 killed krcWatchdogInit -> RmInitAdapter
bailed ('numGpcs > 0' assert at kernel_graphics_object.c:191).
- CPU interrupt tree (osVerifyInterrupts): driver accesses VF window at
virtualRegPhysOffset=NV_VIRTUAL_FUNCTION_FULL_PHYS_OFFSET(0xB80000)+off,
NOT 0x1640 (was watching wrong offset). On LEAF_TRIGGER write, set
LEAF/TOP pending bits + inject MSI-X so the sanity-test ISR runs -
osVerifySystemEnvironment now passes.
- WPR2 race: clear boot state BEFORE CPUCTL=HALTED on Booter-unload kick
so WPR2 is down when driver checks kgspIsWpr2Up ('WPR2 is still up').
- Dedicated GSP_RM_FREE(10) handler: echo NVOS00_PARAMETERS + status=NV_OK
(proper free_v03_00 form). fn-10 timeout persists despite this -
characterized as driver-side reply-matching issue, not content.
|
| |
|
|
|
|
|
|
|
| |
kgspHealthCheck runs on every RPC drain; if the GSP falcon's DEBUGINFO
register (BAR0+0x110094) holds a valid CrashCat wayfinder-L0 signature
(0xdead), crashcatEngineGetNextCrashReport reads 'reports' from garbage
and loops forever in nv_open_q (which then can't poll RPCs -> fn-10
timeouts). Force the wayfinder invalid - our emulated GSP has no
crashcat reports to offer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
logging
- NV_VIRTUAL_FUNCTION_PRIV_MMU_INVALIDATE (BAR0+0x30B0, TRIGGER=bit31):
driver sets TRIGGER then spins in kgmmuCheckPendingInvalidates_TU102
polling for it to clear. Our shadow held TRIGGER forever -> nv_open_q
hard-wedged in RmInitAdapter (TLB invalidate during dmaAllocMapping).
Auto-clear the trigger bit in gsp_emu_poll_boot (instant completion).
- fn-10/47 handler logs hObjectOld + cmd_read/stat_write/drv_rp/stat_seq.
Confirmed: drv_rp tracks stat_write 1:1 (driver drains cleanly, no
lapping); frees complete; stat_seq increments per record.
- Health-check/crashcat loop (kgspHealthCheck -> crashcatEngineGetNext
CrashReport never returns NULL) is a SECONDARY symptom triggered by an
RPC failure during RmInitAdapter - under investigation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- gsp_emu_poll_boot generic SEC2 kick path: clear SEC2_MAILBOX0=0
(success) - Booter Unload during GPU shutdown read a stale 0xff,
failing the unload and killing the subsequent re-init ('Booter failed
with non-zero error code: 0xff' -> RmInitAdapter 0x40). A SEC2 kick
after a completed boot is a GSP shutdown/reload: clear boot state.
Driver unload/reload cycle (last close -> RmShutdown, next open ->
RmInitAdapter) now works.
- STATIC_KGR_GET_GLOBAL_SM_ORDER(0x20800a22): TU104 topology 6 GPC x
4 TPC x 2 SM = 48 SMs/24 TPCs on GR0. kgrStaticInit is init-critical
(NV_CHECK_OK_OR_GOTO); zeros left numSm=0 and NVML spun on empty
topology.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISO fbRegion
- gsp_rm_handle_fifo_device_table: read baseIndex from the queue element
buffer (req_data + hdr), not past the local 24-byte header struct -
FORTIFY proved the old memcpy always overflows -> fortify_panic killed
gsp_emu_0 mid RmInitNvDevice (guest timed out on fn 76).
- gsp_emu_clear_boot_state: clear WPR2/RISCV/mailboxes/stage tracker and
reset GSP-RM queue state. Turing guests produce no observable BAR0
writes on unload, so the next probe's _kgspBootGspRm failed with
'unexpected WPR2 already up'. Trigger on ENGINE reset and on detected
queue death (insane writePtr jump / garbage element signature).
- GspStaticConfigInfo fbRegion[0].supportISO=1: memmgrCalcReservedFbSpace
asserts some region supports ISO 'even with no display'; without it
kdispStateInitLocked couldn't allocate clientChannelTable.
- .gitignore: scripts/git-push-vgpu.sh (local per-machine helper)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Root cause: when the gsp_emu thread crashes (e.g. fortify_panic in
gsp_rm_send), the kernel kills it. Later, gsp_emu_cleanup() calls
kthread_stop() on the dead thread, hitting refcount_warn_saturate
on the freed/saturated task_struct.
Fixes:
1. pid_alive() check before kthread_stop() - skip if thread already dead
2. get_task_struct() after kthread_run() - hold reference so the
task_struct stays valid even after a crash
3. put_task_struct() in cleanup - release the reference
This prevents the module from getting stuck in 'going' state during
mdev removal after a gsp_emu thread crash.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GSP_RM_CONTROL)
Implements the GSP-RM reply content layer for the msgq RPC channel:
- kernel/gsp_rm_emulation.c/h: GSP-RM msgq emulation engine
- Queue chain discovery (libos args → RMARGS → GSP_ARGUMENTS_CACHED)
- Status queue link + GSP_INIT_DONE emission
- Command queue polling + RPC dispatch
- SET_GUEST_SYSTEM_INFO version negotiation (VGX 41.12)
- GET_GSP_STATIC_INFO(65) with 1656-byte GspStaticConfigInfo
- GSP_RM_CONTROL(76) sub-command dispatch:
- FIFO_GET_DEVICE_INFO_TABLE (0x20801112)
- INTERNAL_INTR_GET_KERNEL_TABLE (0x20800a5c)
- GPU_GET_CONSTRUCTED_FALCON_INFO (0x208001b0)
- INTERNAL_GET_DEVICE_INFO_TABLE (0x20800a40)
- kernel/gsp_rm_tu104.h: TU104 hardware tables
- 12-entry FIFO engine table (GR0, CE0-4, NVDEC0-1, NVENC0, SEC2, NVJPG, SW)
- 8-entry interrupt table (from intr_phys_tu102.c)
- 1-entry constructed falcon table (FBFLCN)
- 11-entry internal device info table
- GspStaticConfigInfo layout (1656 bytes, ABI-verified offsets)
- Data from NVIDIA driver material (ext-tree) + hwref/turing/tu104
- tools/rmq/: Userspace RM API client (oracle for ground-truth tables)
KNOWN ISSUE: gsp_rm_send crashes (fortify_panic) on multi-element messages
when reply data exceeds one 4096-byte queue element. Affects cmd 0x20800a41
(paramsSize=8204). Multi-element splitting is the next fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VBIOS serving
Guest driver probe fixes (unmodified 570.144 open driver on physical path):
- kernel/main.c: add show_description to the mdev driver. Userspace mdev
management tools parse 'framebuffer=<n>M' from every mdev type's
description sysfs file before creating an mdev; the missing file made
such tools fail to create the vGPU. Also fix create_mdev.sh for the real
type dir name pci-nvidia-vgpu-* (mdev core names dirs
dev_driver_string(parent)-<sysfs_name>; the parent registers before
nvidia.ko binds so dev_driver_string == 'pci').
- kernel/bar_emulation.c: seed BAR0 shadow so guest sees a REAL, PHYSICAL,
non-virtual TU104 (user directive: no PV/VF vGPU paths, unmodified driver):
* PMC_BOOT_0/1/42 = physical TU104 values captured from host hardware
(0x164000a1 / 0x0 / 0x164a1000). Without these, halmgrGetHalForGpu()
fails and probe aborts with 'does not include the required GSP'.
* Serve a valid VBIOS at the PROM window (BAR0+0x300000) loaded from
/lib/firmware/tu104_vbios.bin (dump of host TU104 ROM). Guest's
kgspExtractVbiosFromRom_TU102 needs it for the mandatory FWSEC ucode
(kgspGetFrtsSize is hardwired to 1MB on Turing).
* Pre-set GSP secure-boot (GFW) completion state: PGC6 PLM (0x118128)=1,
GFW_BOOT progress (0x118234)=0xFF, GSP falcon CPUCTL HALTED (0x110100).
The driver's post-FLR GFW wait only *waits* (never kicks), so the
pre-set state satisfies it immediately.
- kernel/gsp_emulation.c/h: physical GSP boot emulation.
* Falcon boot-watch: poll GSP falcon/PGC6/WPR2/scratch registers and log
changes (guest BAR0 is mmap-based, otherwise invisible to host).
* gsp_emu_poll_boot: STARTCPU auto-complete state machine. Guest kicks
FWSEC then Booter Load via GSP falcon CPUCTL; detect each kick and
complete the stage (HALTED + FRTS err NONE + WPR2 + mailbox +
RISCV-active) so the guest believes its ucodes ran.
Diagnosis that led here (documented in Handoff-vGPU-IO.md):
- Open nvidia.ko can never be an SR-IOV VF vGPU guest: os_is_grid_supported()
is a stub returning FALSE in the open build (disassembled). PV path also
rejected per user directive. Only the physical path with a fully emulated
local GSP boot remains.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
docs suite + repo reorg
CRITICAL FIXES (guest driver bring-up):
- gsp_emulation.c: emulation engine bound to the WRONG BAR0 - it polled the
host physical BAR0 (bars[0].vaddr ioremap) for the doorbell and read RPCs
from a local dma_alloc_wc buffer, while the guest writes land in the
vzalloc'd bar0_shadow. The RPC path could never work; PBA writes even
corrupted the host GPU's physical BAR0+0x3000. gsp_emu_init now binds
exclusively to bar0_shadow (doorbell/mailbox/PBA aliases;
shared_mem_dma==0 marks the alias so cleanup never dma_free's it).
- main.c SET_IRQS: DATA_EVENTFD eventfds were DISCARDED ('TODO' + kfree) -
the guest never received MSI-X completions. Full wiring now:
eventfd_ctx_fdget per vector, fd -1 clears, dev_close releases refs.
gsp_emu_inject_completion_interrupt looks up vgpu->irqs[0].trigger LIVE
(init-time copy was permanently NULL since QEMU wires after gsp_emu_init).
- gsp_rpc_client.c: BAR_TRAP/MIGRATE in emulation mode called
gsp_rpc_submit_raw which rings the SAME doorbell the thread polls -
self-triggered RPC livelock + multi-second stalls. Now fail fast with
-ENOTSUPP + pr_warn_ratelimited (guest BAR access is direct MMIO).
MORE FIXES:
- main.c: nv_vgpu_config_write returned SIZE_MAX (while(count--) wrap) and
was dead code while the VFIO write handler did unfiltered byte copies
(guest could rewrite vendor ID/BARs). Return fixed; VFIO write handler
now routes through the per-register filter.
- kernel/Makefile: M=$(PWD) used the env var which is stale when invoked
via the top-level make (pointed at repo root -> kbuild silently built
NOTHING; explains every 'stale .ko' incident). Now M=$(CURDIR).
- Warnings sweep: header prototypes for mdev/type functions, format casts
in gsp_comm.c DRY-RUN logs, unused variable.
ROBUSTNESS (harness/tooling):
- vgpu_vm.py: run had no timeout (start could block forever);
guest_shell recv could block forever on a wedged guest. Both now bounded;
guest_shell pre-flights guest-ping and reports wedge diagnostics.
- stack_manager.sh: qemu/qemu-debug now launch via the vgpu_vm.py harness
(workflow rule: never raw QEMU).
REPO REORGANIZATION:
- driver/ (legacy guest-side gsp-vgpu.ko) moved to legacy-driver-guest/
(reference only, not built; README explains). 3 legacy un-buildable test
files moved to legacy-driver-guest/kernel-tests/. Top-level Makefile
cleaned of the dead DRIVER_DIR reference.
DOCUMENTATION SUITE (new):
- docs/GSP_EMULATION_ARCHITECTURE.md - emulator deep-dive: shadow BAR0
model, doorbell protocol, dispatch table, MSI-X path, lifecycle, memory-
model caveats
- docs/DEBUGGING.md - QEMU GDB stub workflow, serial console, QMP NMI,
failure taxonomy, full bring-up validation checklist, EPT-livelock case
study, version-matrix discipline
- docs/ONBOARDING.md - repo tour, coding standards (incl. virt_to_phys /
dma_addr_t / get-put rules), first build & test
- docs/VERSION_UPGRADE.md - end-to-end new-driver-version procedure
(firmware fetch, Ghidra analysis, configs, signatures, validation)
- docs/PERFORMANCE.md - bare-metal A/B methodology + targets
- README.md doc index; STATE.md refreshed; DEVELOPMENT_WORKFLOW.md corrected
(load order: open-iov-vfio BEFORE nvidia; stock-driver blacklist note)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove path
VFIO mmap (main.c): virt_to_phys() was used on vmalloc-family addresses
(vzalloc'd BAR0 shadow, ioremap'd BAR2/3), producing garbage PFNs. Guest
BAR0 access then hit a KVM make_spte reserved-bits WARN and an
EPT-violation livelock, hard-wedging the guest on every nvidia driver
probe (confirmed via QEMU GDB stub). BAR0 now maps per-page via
vmalloc_to_pfn(); BAR2/3/4/5 map bars[N].gpa directly (like BAR1);
config space uses new nv_vgpu_mmap_virt_to_pfn() helper.
mdev remove path (main.c): old path never list_del'd the device
(available_instances leaked), never ran cleanup (leaked gsp_emu kthread),
never unregistered VFIO (leaked /dev/vfio/N + iommu group), never put
pdev, never freed the struct. New kvmgt-style path: cancel init_work ->
wait fds -> vfio_unregister_group_dev -> cleanup work -> list_del ->
pci_dev_put -> vfio_put_device.
gsp_rpc_client.c: fix dma_map_page dma_addr_t->int truncation in
gsp_rpc_alloc_emul (corrupts >=4GB IOVAs); export gsp_client_init_emulation.
gsp_emulation.c: export gsp_emu_process_rpc and gsp_emu_get_stats.
main.c: remove wrong MODULE_SOFTDEP("pre: nvidia") - module has zero
nvidia imports, loads standalone, and must load BEFORE nvidia.ko
(it exports nvidia_vgpu_vfio_* for nvidia.ko to import).
nvidia-vgpu-vfio.h: NULL-safe nv_vgpu_{dbg,info,warn,err} macros.
tests/gsp_emulation_test.c: rewritten against current API - drives
gsp_emu_process_rpc() with crafted shared-memory messages (protocol
validation, SCHEDULE/YIELD/NOTIFY/DEBUG dispatch, stress). Builds with
KBUILD_EXTRA_SYMBOLS; depends: open-iov-vfio.
stack_manager.sh: vfio_mdev doesn't exist on >=6.4 (probe per-module);
load-nvidia detects foreign nvidia via /sys/module/nvidia/version and
errors with guidance instead of silently skipping.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Removed IOMMU group addition before vfio_register_emulated_iommu_dev() in nv_vgpu_mdev_create()
- Added IOMMUFD callbacks (bind_iommufd, unbind_iommufd, attach_ioas, detach_ioas) using kernel's vfio_iommufd_emulated_* functions
- Implemented VFIO ioctl handlers: GET_INFO, GET_REGION_INFO, GET_IRQ_INFO, SET_IRQS, MMAP
- Added config space read/write handlers at offset 0x70000000000
- Mmap handler for config space, BAR0 (emulation shadow), BAR1-5 (physical VRAM/registers)
- Interrupt handler for VFIO_DEVICE_SET_IRQS (DATA_EVENTFD, DATA_NONE, DATA_BOOL)
- Added udev rules for vfio group permissions
- Created stack_manager.sh unified tool
- Fixed mdev remove crash with deferred cleanup in vfio_device_release callback
- Kernel 6.8+ IOMMUFD compatibility
- QEMU launches successfully with vGPU passthrough
|
|
|
- New kernel/gsp_emulation.h: GSP emulation context and API
- New kernel/gsp_emulation.c: Per-mdev emulation thread with:
- Adaptive polling of doorbell at BAR0+0x110C00
- Shared memory RPC processing (4KB at BAR0+0x1000)
- Dispatch for all 12 RPC types via firmware-decompiled handlers
- MSI-X completion interrupt injection via eventfd
- Statistics tracking (processed/failed RPCs, latency)
- Modified kernel/main.c: Integrate gsp_emu_init/cleanup in device lifecycle
- Modified kernel/Makefile: Add gsp_emulation.o to build
- Modified kernel/gsp_rpc_client.h: Export gsp_rpc_emulation_set/is_enabled
|
