[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 16/17] Handle PCIe ECAM space access from guests


  • To: Thierry Escande <thierry.escande@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 29 Apr 2026 14:42:19 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f3MR6OdHyhhxWywXl28gco0emvkAneOWoV5IZxL1xBQ=; b=AtmYUK4GScZBShEET6K1GzRH5yGW5hdUMab9az5ycdChwmfR914+lclsmUpMHrdy14M55tIwWW7+xjzDWeH9GU5Tu2J55G7vmqr05uJg5fapzUYLSUPySidjSMPGZ2FlKTTyR5cPbhUWl2jVNIiFILWoBnMPDxhHk0am755ZO3JDnLNN/AdiS7BOV0n8KkLlyDDLCBxiS0XxDoOZo5r1IWN3HjhogICNr9bkUH0OGDw6uZgcp/FB9Rbx7LwpfcEQ6J1GURhXYVlxRf6Bi6SoxPR6MPZwWnHT/L35ae7uv+9/jvOhUrkYYTHz/4nAD1C2nN8jVyCVCeIfR5VRb2w+Sg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ELo450mP+ZkF1nibXvhzYjcMT+4SmGEAePKXRejHLQBesVxeyXqJnLv4wnXLWrI4ILmdRtcZ6h7aGU5+fSBXCnA0grAM1e/rWsVACc586MJ438L+anO7UplSYiVNd5Sf9CJD5ZjWo5Qr1hFghXw0FQNBhjsrxPpoPhFfemV3w1dsVIaD6nXPe6BpCI5jCgseD73JuA5jwMWErqm7olCLA9MQItEjO6oie+ulOQZcRsZCbVLT4mCVdTJCDLPeIJfrVsWDmIt5eAtl87nqRduJW3NWaCbejX9MABOAIk5WsodHMj/CVjfonLtSvQaFUAqBxTrEv7SzfUtka4vLUkohPw==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Wed, 29 Apr 2026 12:43:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Mar 13, 2026 at 04:35:05PM +0000, Thierry Escande wrote:
> This patch adds the logic to decode MMIO-based PCIe ECAM accesses. If
> the IOREQ_TYPE_COPY request is within the ECAM address space configured
> by hvmloader, the ioreq type is set to XEN_DMOP_IO_RANGE_PCI and the
> sbdf decoded from the accessed address.
> 
> Signed-off-by: Thierry Escande <thierry.escande@xxxxxxxxxx>
> ---
>  xen/arch/x86/hvm/ioreq.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index a5fa97e149..022fe05222 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -268,6 +268,8 @@ bool arch_ioreq_server_get_type_addr(const struct domain 
> *d,
>                                       uint64_t *addr)
>  {
>      unsigned int cf8 = d->arch.hvm.pci_cf8;
> +    unsigned long mmio_start = (p->type == IOREQ_TYPE_COPY) ?
> +                                ioreq_mmio_first_byte(p) : 0;
>  
>      if ( p->type != IOREQ_TYPE_COPY && p->type != IOREQ_TYPE_PIO )
>          return false;
> @@ -298,6 +300,19 @@ bool arch_ioreq_server_get_type_addr(const struct domain 
> *d,
>                  *addr |= CF8_ADDR_HI(cf8);
>          }
>      }
> +    else if ( p->type == IOREQ_TYPE_COPY &&
> +              (mmio_start >= d->arch.ecam_addr &&
> +               mmio_start < (d->arch.ecam_addr + d->arch.ecam_size)) )
> +    {
> +        pci_sbdf_t sbdf;
> +        unsigned int reg = mmio_start & ~PAGE_MASK;
> +
> +        sbdf.bdf =  (((mmio_start - d->arch.ecam_addr) & 0x0ffff000) >> 12);
> +        sbdf.seg = 0;
> +
> +        *type = XEN_DMOP_IO_RANGE_PCI;
> +        *addr = ((uint64_t)sbdf.sbdf << 32) | reg;

The trapping & decoding here should better re-use the logic in the
vpci_mmcfg* handlers in x86/hvm/io.c.  You might want to gate the call
to register_mmio_handler() to the domain having vPCI, so that
otherwise it will be handled by the IOREQ catch-all.  It's a bit
hacky, but we already know that vPCI and IOREQs don't play well, and
it needs solving properly.  Again I don't want to force you having to
do that just to get q35 merged.  But we should at least aim to not
duplicate the data in the domain structures.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.