All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	george.dunlap@citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-4.12 v2 2/7] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries
Date: Thu, 14 Feb 2019 14:59:10 +0100	[thread overview]
Message-ID: <20190214135910.egdaixdbv6zogwfx@mac> (raw)
In-Reply-To: <5C643D6A020000780021661A@prv1-mh.provo.novell.com>

On Wed, Feb 13, 2019 at 08:53:14AM -0700, Jan Beulich wrote:
> >>> On 11.02.19 at 18:46, <roger.pau@citrix.com> wrote:
> > The assert was originally added to make sure that higher order
> > regions (> PAGE_ORDER_4K) could not be used to bypass the
> > mmio_ro_ranges check performed by p2m_type_to_flags.
> > 
> > This however is already checked in set_mmio_p2m_entry, which makes
> > sure that higher order mappings don't overlap with mmio_ro_ranges,
> > thus allowing the creation of high order MMIO mappings safely.
> > 
> > Replace the assert to allow 2M/1G entries to be created for MMIO
> > regions and add some extra asserts as a replacement to make sure
> > there's no overlapping with MMIO read-only ranges.
> > 
> > Note that 1G MMIO entries will not be created unless mmio_order is
> > changed to allow it.
> > 
> > Suggested-by: George Dunlap <george.dunlap@citrix.com>
> 
> Is this still the case? Iirc the original suggestion was to remove
> the assertion altogether?

Right, should I instead add your suggested-by tag?

> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -576,7 +576,15 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t mfn,
> >          }
> >  
> >          ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
> > -        ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
> > +        if ( p2mt == p2m_mmio_direct )
> > +            ASSERT(!mfn_eq(mfn, INVALID_MFN) &&
> > +                   !rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
> > +                                            mfn_x(mfn) + PFN_DOWN(MB(2))));
> > +        else if ( p2m_allows_invalid_mfn(p2mt) || p2mt == p2m_invalid ||
> > +                  p2mt == p2m_mmio_dm )
> > +            ASSERT(mfn_valid(mfn) || mfn_eq(mfn, INVALID_MFN));
> > +        else
> > +            ASSERT(mfn_valid(mfn));
> >          l3e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
> >              ? p2m_l3e_from_pfn(mfn_x(mfn),
> >                                 p2m_type_to_flags(p2m, p2mt, mfn, 2))
> > @@ -668,7 +676,15 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t mfn,
> >          }
> >  
> >          ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
> > -        ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
> > +        if ( p2mt == p2m_mmio_direct )
> > +            ASSERT(!mfn_eq(mfn, INVALID_MFN) &&
> > +                   !rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
> > +                                            mfn_x(mfn) + PFN_DOWN(MB(2))));
> > +        else if ( p2m_allows_invalid_mfn(p2mt) || p2mt == p2m_invalid ||
> > +                  p2mt == p2m_mmio_dm )
> > +            ASSERT(mfn_valid(mfn) || mfn_eq(mfn, INVALID_MFN));
> > +        else
> > +            ASSERT(mfn_valid(mfn));
> 
> Seeing this supposedly almost the same (but actually entirely the same,
> due to the wrong MB(2) in the first hunk) code I wonder whether this
> wouldn't better be put in a helper (macro or function), together with
> adjacent assertion in context, immediately ahead of the line you alter.

Thanks, I've placed this into a helper function named check_entry,
which is the best name I could come up with.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-02-14 13:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 17:46 [PATCH for-4.12 v2 0/7] pvh/dom0/shadow/amd fixes Roger Pau Monne
2019-02-11 17:46 ` [PATCH for-4.12 v2 1/7] dom0/pvh: align allocation and mapping order to start address Roger Pau Monne
2019-02-12 10:52   ` Wei Liu
2019-02-13 15:32   ` Jan Beulich
2019-02-11 17:46 ` [PATCH for-4.12 v2 2/7] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries Roger Pau Monne
2019-02-13 15:53   ` Jan Beulich
2019-02-14 13:59     ` Roger Pau Monné [this message]
2019-02-14 14:48       ` Jan Beulich
2019-02-11 17:46 ` [PATCH for-4.12 v2 3/7] x86/pvh: reorder PVH dom0 iommu initialization Roger Pau Monne
2019-02-13 15:58   ` Jan Beulich
2019-02-11 17:46 ` [PATCH for-4.12 v2 4/7] pvh/dom0: warn when dom0_mem is not set Roger Pau Monne
2019-02-12 10:52   ` Wei Liu
2019-02-13 16:01   ` Jan Beulich
2019-02-13 17:13     ` Roger Pau Monné
2019-02-14  8:09       ` Jan Beulich
2019-02-11 17:46 ` [PATCH v2 5/7] x86/mm: split p2m ioreq server pages special handling into helper Roger Pau Monne
2019-02-13 10:23   ` Paul Durrant
2019-02-11 17:46 ` [PATCH v2 6/7] x86/mm: handle foreign mappings in p2m_entry_modify Roger Pau Monne
2019-02-14 11:25   ` Jan Beulich
2019-02-14 12:12     ` Roger Pau Monné
2019-02-14 12:25       ` Jan Beulich
2019-02-11 17:46 ` [PATCH v2 7/7] npt/shadow: allow getting foreign page table entries Roger Pau Monne
2019-02-14 11:38   ` Jan Beulich
2019-02-14 12:16     ` Roger Pau Monné
2019-02-14 12:30       ` Jan Beulich
2019-02-11 19:50 ` [PATCH for-4.12 v2 0/7] pvh/dom0/shadow/amd fixes Sander Eikelenboom

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=20190214135910.egdaixdbv6zogwfx@mac \
    --to=roger.pau@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jgross@suse.com \
    --cc=wei.liu2@citrix.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.