diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-11-09 14:05:39 -0500 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-11-09 14:05:39 -0500 |
| commit | 3701f985edb89224f6a5c1237b21ddb8e527e126 (patch) | |
| tree | 4843a6f76df8e05cd50088c888007fed0f99206f /userspace/examples/Makefile | |
| parent | a47a2124d4c8110e9cfb6fb500a108bcea7becb4 (diff) | |
| download | open-iov-3701f985edb89224f6a5c1237b21ddb8e527e126.tar.gz open-iov-3701f985edb89224f6a5c1237b21ddb8e527e126.zip | |
vgsp-sema: resolve the scrubber's finish words through the GPU page tables
The guest PMA scrubber's host-side completion (channel buffer + pbSize +
entries*8) was resolved through the learned VA->PA pair map first. When
the guest reused the scrubber's GPU VA for a new channel buffer, that map
still named the previous allocation's page, and the host authored the
finish payload there while the guest polled the new page through its
kernel VAS (h=0xc). r1667 live proof: walk_probe 0x12006c000 -> only
VAS[1] (h=0xc) resolves to PA 0x10812a000 (the page the guest's vmalloc
mapping of the channel buffer points at, and the value it polls); the
pair map returned 0x10526a000. Writing the finish value to the correct
page (via the guest scanner registration) immediately released Xorg from
the RM memory-manager wait and the queued GSP status records drained.
Changes:
- svc_scrub_pass(): resolve hsem/fin through svc_walk_vaspaces() first,
fall back to the pair map only when no VAS maps the VA.
- Struct svc_scrub gains authored_gen; a new pa_gen (fresh scanner
registration or a corrected derivation) forces one authoring pass even
when the scrubber's PUT did not advance, so an already-waiting guest
is released without a new submission.
Diffstat (limited to 'userspace/examples/Makefile')
0 files changed, 0 insertions, 0 deletions
