From: "Michael S. Tsirkin" <mst@redhat.com>
To: Thierry Escande <thierry.escande@vates.tech>
Cc: qemu-devel@nongnu.org, Alexey Gerasimenko <x1917x@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Eduardo Habkost <eduardo@habkost.net>,
Anthony PERARD <anthony@xenproject.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/4] q35: Fix incorrect values for PCIEXBAR masks
Date: Sun, 24 May 2026 03:43:47 -0400 [thread overview]
Message-ID: <20260524034330-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260313164649.794591-4-thierry.escande@vates.tech>
On Fri, Mar 13, 2026 at 04:47:16PM +0000, Thierry Escande wrote:
> From: Alexey Gerasimenko <x1917x@gmail.com>
>
> There are two small issues in PCIEXBAR address mask handling:
> - wrong bit positions for address mask bits (see PCIEXBAR description
> in Q35 datasheet)
> - incorrect usage of 64ADR_MASK
>
> Due to this, attempting to write a valid PCIEXBAR address may cause it
> to shift to another address, causing memory layout corruption where
> emulated MMIO regions may overlap real (passed through) MMIO ranges. Fix
> this by providing correct values.
>
> Signed-off-by: Alexey Gerasimenko <x1917x@gmail.com>
> Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> hw/pci-host/q35.c | 6 +++---
> include/hw/pci-host/q35.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index e85e4227b3..7368e3c598 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -306,12 +306,12 @@ static void mch_update_pciexbar(MCHPCIState *mch)
> break;
> case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M:
> length = 128 * 1024 * 1024;
> - addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK |
> - MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
> + addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
> break;
> case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_64M:
> length = 64 * 1024 * 1024;
> - addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
> + addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK |
> + MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
> break;
> case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD:
> qemu_log_mask(LOG_GUEST_ERROR, "Q35: Reserved PCIEXBAR LENGTH\n");
> diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
> index ddafc3f2e3..f31a71010b 100644
> --- a/include/hw/pci-host/q35.h
> +++ b/include/hw/pci-host/q35.h
> @@ -100,8 +100,8 @@ struct Q35PCIHost {
> #define MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT 0xb0000000
> #define MCH_HOST_BRIDGE_PCIEXBAR_MAX (0x10000000) /* 256M */
> #define MCH_HOST_BRIDGE_PCIEXBAR_ADMSK Q35_MASK(64, 35, 28)
> -#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK ((uint64_t)(1 << 26))
> -#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK ((uint64_t)(1 << 25))
> +#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK ((uint64_t)(1 << 27))
> +#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK ((uint64_t)(1 << 26))
> #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_MASK ((uint64_t)(0x3 << 1))
> #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_256M ((uint64_t)(0x0 << 1))
> #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M ((uint64_t)(0x1 << 1))
> --
> 2.51.0
>
>
>
> --
> Thierry Escande | Vates XCP-ng Developer
>
> XCP-ng & Xen Orchestra - Vates solutions
>
> web: https://vates.tech
next prev parent reply other threads:[~2026-05-24 7:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 16:46 [PATCH 0/4] Xen: Add Q35 initial support for HVM guests Thierry Escande
2026-03-13 16:47 ` [PATCH 1/4] pc/xen: Xen Q35 support: provide IRQ handling for PCI devices Thierry Escande
2026-05-24 7:27 ` Michael S. Tsirkin
2026-03-13 16:47 ` [PATCH 2/4] q35/xen: Add Xen support for Q35 Thierry Escande
2026-03-13 16:47 ` Thierry Escande
2026-03-13 16:47 ` [PATCH 3/4] q35: Fix incorrect values for PCIEXBAR masks Thierry Escande
2026-05-24 7:43 ` Michael S. Tsirkin [this message]
2026-03-13 16:47 ` [PATCH 4/4] xen: Handle PCIe config space size in cpu_ioreq_config() Thierry Escande
2026-03-14 14:16 ` [PATCH 0/4] Xen: Add Q35 initial support for HVM guests Marek Marczykowski-Górecki
2026-03-24 9:28 ` Anthony PERARD
2026-03-24 9:59 ` Daniel P. Berrangé
2026-04-08 7:33 ` Thierry Escande
2026-05-24 7:15 ` Michael S. Tsirkin
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=20260524034330-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=anthony@xenproject.org \
--cc=eduardo@habkost.net \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thierry.escande@vates.tech \
--cc=x1917x@gmail.com \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.