All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Community Manager <community.manager@xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 2/2] x86/dom0: attempt to fixup p2m page-faults for PVH dom0
Date: Tue, 18 Feb 2025 16:44:35 +0100	[thread overview]
Message-ID: <Z7Sq4wXr3nqQpdMk@macbook.local> (raw)
In-Reply-To: <20250218143504.77638-3-roger.pau@citrix.com>

On Tue, Feb 18, 2025 at 03:35:04PM +0100, Roger Pau Monne wrote:
> When building a PVH dom0 Xen attempts to map all (relevant) MMIO regions
> into the p2m for dom0 access.  However the information Xen has about the
> host memory map is limited.  Xen doesn't have access to any resources
> described in ACPI dynamic tables, and hence the p2m mappings provided might
> not be complete.
> 
> PV doesn't suffer from this issue because a PV dom0 is capable of mapping
> into it's page-tables any address not explicitly banned in d->iomem_caps.
> 
> Introduce a new command line options that allows Xen to attempt to fixup
> the p2m page-faults, by creating p2m identity maps in response to p2m
> page-faults.
> 
> This is aimed as a workaround to small ACPI regions Xen doesn't know about.
> Note that missing large MMIO regions mapped in this way will lead to
> slowness due to the VM exit processing, plus the mappings will always use
> small pages.
> 
> The ultimate aim is to attempt to bring better parity with a classic PV
> dom0.
> 
> Note such fixup rely on the CPU doing the access to the unpopulated
> address.  If the access is attempted from a device instead there's no
> possible way to fixup, as IOMMU page-fault are asynchronous.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Only slightly tested on my local PVH dom0 deployment.
> ---
> Changes since v1:
>  - Make the fixup function static.
>  - Print message in case mapping already exists.
> ---
>  CHANGELOG.md                           | 10 ++++
>  docs/misc/xen-command-line.pandoc      | 16 +++++-
>  xen/arch/x86/dom0_build.c              |  5 ++
>  xen/arch/x86/hvm/emulate.c             | 74 +++++++++++++++++++++++++-
>  xen/arch/x86/include/asm/hvm/emulate.h |  3 ++
>  5 files changed, 105 insertions(+), 3 deletions(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 1de1d1eca17f..e5e6ab3a8902 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -4,6 +4,16 @@ Notable changes to Xen will be documented in this file.
>  
>  The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>  
> +## [4.21.0 UNRELEASED](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - TBD
> +
> +### Changed
> +
> +### Added
> + - On x86:
> +   - Option to attempt to fixup p2m page-faults on PVH dom0.
> +
> +### Removed
> +
>  ## [4.20.0 UNRELEASED](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - TBD
>  
>  ### Changed
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 9bbd00baef91..83bb69cfb852 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -822,7 +822,8 @@ Specify the bit width of the DMA heap.
>  
>  ### dom0
>      = List of [ pv | pvh, shadow=<bool>, verbose=<bool>,
> -                cpuid-faulting=<bool>, msr-relaxed=<bool> ] (x86)
> +                cpuid-faulting=<bool>, msr-relaxed=<bool>,
> +                pf-fixup=<bool> ] (x86)
>  
>      = List of [ sve=<integer> ] (Arm64)
>  
> @@ -883,6 +884,19 @@ Controls for how dom0 is constructed on x86 systems.
>  
>      If using this option is necessary to fix an issue, please report a bug.
>  
> +*   The `pf-fixup` boolean is only applicable when using a PVH dom0 and
> +    defaults to false.

I'm considering whether the default should instead be true, so that
PVH is closer to what which regions a classic PV dom0 gets access to.

Thanks, Roger.


  reply	other threads:[~2025-02-18 15:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 14:35 [PATCH v2 0/2] x86/pvh: workaround missing MMIO regions in dom0 p2m Roger Pau Monne
2025-02-18 14:35 ` [PATCH v2 1/2] x86/emul: dump unhandled memory accesses for PVH dom0 Roger Pau Monne
2025-02-18 14:35 ` [PATCH v2 2/2] x86/dom0: attempt to fixup p2m page-faults " Roger Pau Monne
2025-02-18 15:44   ` Roger Pau Monné [this message]
2025-02-18 15:58     ` Jan Beulich
2025-02-18 16:39       ` Roger Pau Monné
2025-02-18 15:57   ` Jan Beulich
2025-02-28 15:42   ` Oleksii Kurochko

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=Z7Sq4wXr3nqQpdMk@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=community.manager@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=sstabellini@kernel.org \
    --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.