From: Paul Durrant <xadimgnik@gmail.com>
To: "'Roger Pau Monne'" <roger.pau@citrix.com>,
<xen-devel@lists.xenproject.org>
Cc: "'Jan Beulich'" <jbeulich@suse.com>,
"'Andrew Cooper'" <andrew.cooper3@citrix.com>,
"'Wei Liu'" <wl@xen.org>
Subject: RE: [PATCH] x86/mm: do not mark IO regions as Xen heap
Date: Thu, 10 Sep 2020 15:23:36 +0100 [thread overview]
Message-ID: <003201d6877d$f8e07650$eaa162f0$@xen.org> (raw)
In-Reply-To: <20200910133514.82155-1-roger.pau@citrix.com>
> -----Original Message-----
> From: Roger Pau Monne <roger.pau@citrix.com>
> Sent: 10 September 2020 14:35
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne <roger.pau@citrix.com>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>
> Subject: [PATCH] x86/mm: do not mark IO regions as Xen heap
>
> arch_init_memory will treat all the gaps on the physical memory map
> between RAM regions as MMIO and use share_xen_page_with_guest in order
> to assign them to dom_io. This has the side effect of setting the Xen
> heap flag on such pages, and thus is_special_page would then return
> true which is an issue in epte_get_entry_emt because such pages will
> be forced to use write-back cache attributes.
>
> Fix this by introducing a new helper to assign the MMIO regions to
> dom_io without setting the Xen heap flag on the pages, so that
> is_special_page will return false and the pages won't be forced to use
> write-back cache attributes.
>
> Fixes: 81fd0d3ca4b2cd ('x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()')
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Paul Durrant <paul@xen.org>
> ---
> xen/arch/x86/mm.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 35ec0e11f6..4daf4e038a 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -271,6 +271,18 @@ static l4_pgentry_t __read_mostly split_l4e;
> #define root_pgt_pv_xen_slots ROOT_PAGETABLE_PV_XEN_SLOTS
> #endif
>
> +static void __init assign_io_page(struct page_info *page)
> +{
> + set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), INVALID_M2P_ENTRY);
> +
> + /* The incremented type count pins as writable. */
> + page->u.inuse.type_info = PGT_writable_page | PGT_validated | 1;
> +
> + page_set_owner(page, dom_io);
> +
> + page->count_info |= PGC_allocated | 1;
> +}
> +
> void __init arch_init_memory(void)
> {
> unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn;
> @@ -291,7 +303,7 @@ void __init arch_init_memory(void)
> */
> BUG_ON(pvh_boot && trampoline_phys != 0x1000);
> for ( i = 0; i < 0x100; i++ )
> - share_xen_page_with_guest(mfn_to_page(_mfn(i)), dom_io, SHARE_rw);
> + assign_io_page(mfn_to_page(_mfn(i)));
>
> /* Any areas not specified as RAM by the e820 map are considered I/O. */
> for ( i = 0, pfn = 0; pfn < max_page; i++ )
> @@ -332,7 +344,7 @@ void __init arch_init_memory(void)
> if ( !mfn_valid(_mfn(pfn)) )
> continue;
>
> - share_xen_page_with_guest(mfn_to_page(_mfn(pfn)), dom_io, SHARE_rw);
> + assign_io_page(mfn_to_page(_mfn(pfn)));
Now these calls to share_xen_page_with_guest() are gone, can we change share_xen_page_with_guest() to ASSERT that PGC_xen_heap is already set, and avoid (needlessly) ORing it in?
Paul
> }
>
> /* Skip the RAM region. */
> --
> 2.28.0
next prev parent reply other threads:[~2020-09-10 14:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 13:35 [PATCH] x86/mm: do not mark IO regions as Xen heap Roger Pau Monne
2020-09-10 14:23 ` Paul Durrant [this message]
2020-09-10 14:36 ` Jan Beulich
2020-09-10 14:41 ` Jan Beulich
2020-09-10 17:27 ` Roger Pau Monné
2020-09-11 6:25 ` Jan Beulich
2020-09-11 11:55 ` Jan Beulich
2020-09-17 14:12 ` Jan Beulich
2020-09-17 14:28 ` Roger Pau Monné
2020-09-17 14:38 ` Jan Beulich
2020-09-21 14:22 ` Jan Beulich
2020-09-21 15:35 ` Roger Pau Monné
2020-09-21 15:49 ` Jan Beulich
2020-09-22 8:43 ` Roger Pau Monné
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='003201d6877d$f8e07650$eaa162f0$@xen.org' \
--to=xadimgnik@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=paul@xen.org \
--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.