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: 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: Mon, 15 Dec 2025 04:52:03 +0900	[thread overview]
Message-ID: <20251215045203.13d96d09.alex@shazbot.org> (raw)
In-Reply-To: <CAHP4M8Uy7HLiKjnMCdNG+QG+0cizN82c_G87AuzDL6qDCBG5vg@mail.gmail.com>

On Sun, 14 Dec 2025 17:38:50 +0530
Ajay Garg <ajaygargnsit@gmail.com> wrote:

> Hi everyone.
> 
> Let's assume x86_64-linux host and guest, with full-virtualization and
> iommu hardware capabilities.
> 
> Before launching vm, qemu with the help vfio "installs" "dev1" on the
> virtual-pci-root-complex of guest.
> After bootup, the guest does the usual enumeration, finds "dev1" on
> the pci-bus, and programs the BARs in its domain.
> 
> However, there is no guarantee that guest-pci-mmio-physical-ranges
> would be identical to "what would have been"
> host-pci-mmio-physical-ranges.
> Then how does the EPT/SLAT tables get set up for correct mapping from
> GPA => HPA for dev1's-BARs-MMIO-regions ?

The guest doesn't get to program the device physical BARs, nor does it
require identity mapping in the guest.  The BAR programming is
virtualized.  QEMU mmaps the BAR and that mmap is the backing for the
mapping into the guest.  Thanks,

Alex

  reply	other threads:[~2025-12-14 19:52 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 [this message]
2025-12-15  3:50   ` Ajay Garg
2025-12-19  6:23     ` Ajay Garg
2025-12-20  0:06       ` Alex Williamson
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=20251215045203.13d96d09.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 \
    /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