All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>
Subject: Re: [PATCH 3/6] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only
Date: Thu, 17 Dec 2020 19:54:51 +0000	[thread overview]
Message-ID: <fc78c235-f806-6120-25f0-182b4c08bdaa@citrix.com> (raw)
In-Reply-To: <15f41816-4814-bae5-e0bc-89e99d04a142@suse.com>

On 15/12/2020 16:26, Jan Beulich wrote:
> Extend a respective #ifdef from inside set_typed_p2m_entry() to around
> all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety
> check path.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

As the code currently stands, yes.  However, I'm not sure I agree
conceptually.

The p2m APIs are either a common interface to use, or HVM-specific.

PV guests don't actually have a p2m, but some of the APIs are used from
common code (e.g. copy_to/from_guest()), and some p2m concepts are
special cased as identity for PV (technically paging_mode_translate()),
while other concepts, such as foreign/mmio, which do exist for both PV
and HVM guests, are handled with totally different API sets for PV and HVM.

This is a broken mess of an abstraction.  I suspect some of it has to do
with PV autotranslate mode in the past, but that doesn't alter the fact
that we have a totally undocumented and error prone set of APIs here.

Either P2M's should (fully) be the common abstraction (despite not being
a real object for PV guests), or they should should be a different set
of APIs which is the common abstraction, and P2Ms should move being
exclusively for HVM guests.

(It's also very obvious by all the CONFIG_X86 ifdefary that we've got
arch specifics in our common code, and that is another aspect of the API
mess which needs handling.)

I'm honestly not sure which of these would be better, but I'm fairly
sure that either would be better than what we've currently got.  I
certainly think it would be better to have a plan for improvement, to
guide patches like this.

~Andrew


  reply	other threads:[~2020-12-17 19:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 16:24 [PATCH 0/6] x86/p2m: restrict more code to build just for HVM Jan Beulich
2020-12-15 16:25 ` [PATCH 1/6] x86/p2m: tidy p2m_add_foreign() a little Jan Beulich
2020-12-17 19:03   ` Andrew Cooper
2020-12-18  8:39     ` Jan Beulich
2020-12-15 16:26 ` [PATCH 2/6] x86/mm: p2m_add_foreign() is HVM-only Jan Beulich
2020-12-17 19:18   ` Andrew Cooper
2020-12-18  8:48     ` Jan Beulich
2020-12-21  8:10     ` Jan Beulich
2020-12-22 10:40       ` Andrew Cooper
2021-01-04 16:57         ` Oleksandr Tyshchenko
2021-01-05  8:48           ` Jan Beulich
2021-01-08 16:38             ` Oleksandr
2021-01-08 17:01               ` Jan Beulich
2021-01-08 17:37                 ` Oleksandr
2021-01-11  7:41                   ` Jan Beulich
2021-01-11  8:23                     ` Oleksandr
2021-01-12 11:58                       ` Jan Beulich
2021-01-13 15:06                         ` Oleksandr
2021-01-23 13:22                           ` Julien Grall
2021-01-25  9:10                             ` Jan Beulich
2021-01-25 10:33                             ` Jan Beulich
2020-12-15 16:26 ` [PATCH 3/6] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only Jan Beulich
2020-12-17 19:54   ` Andrew Cooper [this message]
2020-12-18  8:58     ` Jan Beulich
2020-12-15 16:26 ` [PATCH 4/6] x86/p2m: {,un}map_mmio_regions() " Jan Beulich
2020-12-15 16:27 ` [PATCH 5/6] x86/mm: the gva_to_gfn() hook is HVM-only Jan Beulich
2020-12-22 17:02   ` Jan Beulich
2020-12-15 16:28 ` [PATCH 6/6] x86/p2m: set_shared_p2m_entry() is MEM_SHARING-only Jan Beulich
2020-12-15 17:05   ` Tamas K Lengyel

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=fc78c235-f806-6120-25f0-182b4c08bdaa@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.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.