public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex@shazbot.org>
To: Ajay Garg <ajaygargnsit@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: A lingering doubt on PCI-MMIO region of PCI-passthrough-device
Date: Fri, 19 Dec 2025 17:06:37 -0700	[thread overview]
Message-ID: <20251219170637.2c161b7b.alex@shazbot.org> (raw)
In-Reply-To: <CAHP4M8X=e+dP-T_if5eA=gccdbxkkObYvcrwA3qUBONKWW3W_w@mail.gmail.com>

On Fri, 19 Dec 2025 11:53:56 +0530
Ajay Garg <ajaygargnsit@gmail.com> wrote:

> Hi Alex.
> Kindly help if the steps listed in the previous email are correct.
> 
> (Have added qemu mailing-list too, as it might be a qemu thing too as
> virtual-pci is in picture).
> 
> On Mon, Dec 15, 2025 at 9:20 AM Ajay Garg <ajaygargnsit@gmail.com> wrote:
> >
> > 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?

It's not far off.  The key is simply that we can create a host virtual
mapping to the device BARs, ie. an mmap.  The guest enumerates emulated
BARs, they're only used for sizing and locating the BARs in the guest
physical address space.  When the guest BAR is programmed and memory
enabled, the address space in QEMU is populated at the BAR indicated
GPA using the mmap backing.  KVM memory slots are used to fill the
mappings in the vCPU.  The same BAR mmap is also used to provide DMA
mapping of the BAR through the IOMMU in the legacy type1 IOMMU backend
case.  Barring a vIOMMU, the IOMMU IOVA space is the guest physical
address space.  Thanks,

Alex

  reply	other threads:[~2025-12-20  0:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-14 12:08 A lingering doubt on PCI-MMIO region of PCI-passthrough-device Ajay Garg
2025-12-14 19:52 ` Alex Williamson
2025-12-15  3:50   ` Ajay Garg
2025-12-19  6:23     ` Ajay Garg
2025-12-20  0:06       ` Alex Williamson [this message]
2025-12-20 12:52         ` Ajay Garg
2025-12-20 13:24           ` Ajay Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251219170637.2c161b7b.alex@shazbot.org \
    --to=alex@shazbot.org \
    --cc=ajaygargnsit@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox