linux-kernel - Re: A lingering doubt on PCI-MMIO region of PCI-passthrough-device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHP4M8WeHz-3VbzKb_54C5UuWW-jtqvE=X37CSssUa5gti41GQ@mail.gmail.com>
Date: Mon, 15 Dec 2025 09:20:17 +0530
From: Ajay Garg <ajaygargnsit@...il.com>
To: Alex Williamson <alex@...zbot.org>
Cc: iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A lingering doubt on PCI-MMIO region of PCI-passthrough-device

Thanks Alex.

So does something like the following happen :

i)
During bootup, guest starts pci-enumeration as usual.

ii)
Upon discovering the "passthrough-device", guest carves the physical
MMIO regions (as usual) in the guest's physical-address-space, and
starts-to/attempts to program the BARs with the
guest-physical-base-addresses carved out.

iii)
These attempts to program the BARs (lying in the
"passthrough-device"'s config-space), are intercepted by the
hypervisor instead (causing a VM-exit in the interim).

iv)
The hypervisor uses the above info to update the EPT, to ensure GPA =>
HPA conversions go fine when the guest tries to access the PCI-MMIO
regions later (once gurst is fully booted up). Also, the hypervisor
marks the operation as success (without "really" re-programming the
BARs).

v)
The VM-entry is called, and the guest resumes with the "impression"
that the BARs have been "programmed by guest".

Is the above sequencing correct at a bird's view level?

Once again, many thanks for the help !

Thanks and Regards,
Ajay