xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tamas K Lengyel <tklengyel@sec.in.tum.de>
Subject: Re: [PATCH for-4.5 v8 15/19] xen/arm: Data abort exception (R/W) mem_events.
Date: Wed, 24 Sep 2014 18:17:14 +0200	[thread overview]
Message-ID: <CAErYnsijgsMf_9omHBugBS9zhtesx6ErQ86khccPROtnAyJJrQ@mail.gmail.com> (raw)
In-Reply-To: <1411570971.28127.63.camel@kazak.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 6119 bytes --]

On Wed, Sep 24, 2014 at 5:02 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Tue, 2014-09-23 at 15:14 +0200, Tamas K Lengyel wrote:
> > This patch enables to store, set, check and deliver LPAE R/W mem_events.
> > As the LPAE PTE's lack enough available software programmable bits,
> > we store the permissions in a Radix tree. A custom boolean,
> access_in_use,
> > specifies if the tree is in use to avoid uneccessary lookups on an empty
> tree.
>
> "unnecessary".
>

Ack.


>
> > @@ -414,12 +417,40 @@ static int p2m_create_table(struct domain *d,
> lpae_t *entry,
> >      return 0;
> >  }
> >
> > +static long p2m_mem_access_radix_set(struct p2m_domain *p2m, unsigned
> long pfn,
> > +                                     p2m_access_t a)
> > +{
> > +    long rc;
> > +    if ( p2m_access_rwx == a )
>
> I think I mentioned this before, but please write your conditionals the
> more conventional way around.
>

I guess my argument for this style was too much tin-foil-hat so Ack.


>
> > +    {
> > +        if ( p2m->access_in_use )
> > +            radix_tree_delete(&p2m->mem_access_settings, pfn);
> > +
> > +        return 0;
> > +    }
> > +
> > +    rc = radix_tree_insert(&p2m->mem_access_settings, pfn,
> > +                           radix_tree_int_to_ptr(a));
> > +    if ( -EEXIST == rc )
> > +    {
> > +        /* If a setting existed already, change it to the new one */
> > +        radix_tree_replace_slot(
> > +            radix_tree_lookup_slot(
> > +                &p2m->mem_access_settings, pfn),
> > +            radix_tree_int_to_ptr(a));
>
> What a shame that the API doesn't allow you to do an insert or replace
> in one go!
>

Could be extended I guess in the future.


>
> > @@ -591,9 +631,14 @@ static int apply_one_level(struct domain *d,
> >
> >      case INSERT:
> >          if ( is_mapping_aligned(*addr, end_gpaddr, *maddr, level_size)
> &&
> > -           /* We do not handle replacing an existing table with a
> superpage */
> > -             (level == 3 || !p2m_table(orig_pte)) )
> > +           /* We do not handle replacing an existing table with a
> superpage
> > +            * or when mem_access is in use. */
> > +             (level == 3 || (!p2m_table(orig_pte) &&
> !p2m->access_in_use)) )
> >          {
> > +            rc = p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), a);
> > +            if ( rc < 0 )
> > +                return rc;
>
> I expect the answer is yes, but just to check: It is desirable to be
> able to insert with a specific non-defualt access perms, as opposed to
> INSERT with defaults then MEMACCESS?
>

I would say yes for performance reasons. No need to go through the pages
once for INSERT then once for MEMACCESS.


>
> > @@ -753,6 +799,49 @@ static int apply_one_level(struct domain *d,
> >              *addr += PAGE_SIZE;
> >              return P2M_ONE_PROGRESS_NOP;
> >          }
> > +
> > +    case MEMACCESS:
> > +        if ( level < 3 )
> > +        {
> > +            if ( !p2m_valid(orig_pte) )
> > +            {
> > +                *addr += level_size;
> > +                return P2M_ONE_PROGRESS_NOP;
> > +            }
> > +
> > +            /* Shatter large pages as we descend */
> > +            if ( p2m_mapping(orig_pte) )
> > +            {
> > +                rc = p2m_shatter_page(d, entry, level, flush_cache);
> > +
> > +                if ( rc < 0 )
> > +                    return rc;
>
> I don't know if that matter for this specific sub op but what is
> supposed to happen on error? Should partial work be undone?
>

IMHO if a page cannot be shattered something must be pretty screwed already
(Xen running out of memory?) in which case un-doing the already shattered
pages is the least of our concern..


>
> > @@ -776,6 +865,8 @@ static int apply_p2m_changes(struct domain *d,
> >      unsigned int cur_root_table = ~0;
> >      unsigned int cur_offset[4] = { ~0, };
> >      unsigned int count = 0;
> > +    unsigned long start_gpfn = paddr_to_pfn(start_gpaddr),
> > +                  end_gpfn = paddr_to_pfn(end_gpaddr);
>
> You don't need to update end_gpaddr up, do you?
>

No, these two values are provided by the user and we only keep track of the
progress made in updating the PTEs that fall in-range.


>
> >      bool_t flush = false;
> >      bool_t flush_pt;
> >
> > @@ -821,6 +912,21 @@ static int apply_p2m_changes(struct domain *d,
> >              count = 0;
> >          }
> >
> > +        /*
> > +         * Preempt setting mem_access permissions as required by XSA-89,
> > +         * if it's not the last iteration.
> > +         */
> > +        if ( op == MEMACCESS && count )
> > +        {
> > +            int progress = paddr_to_pfn(addr) - start_gpfn + 1;
> > +            if ( (end_gpfn-start_gpfn) > progress && !(progress & mask)
>
> This differs from the x86 equivalent in that it is not "++progress".
> Doesn't that mean that we can fail to make any progress at all?
>

It is technically ++progress, just the style is different. Note the +1 when
declaring progress. Furthermore, the && count ensures that at least one
iteration is always done when calling with MEMACCESS.


>
> > +int p2m_get_mem_access(struct domain *d, unsigned long gpfn,
> > +                       xenmem_access_t *access)
> > +{
> > +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    void *i;
> > +    unsigned int index;
> > +
> > +    static const xenmem_access_t memaccess[] = {
> > +#define ACCESS(ac) [p2m_access_##ac] = XENMEM_access_##ac
> > +            ACCESS(n),
> > +            ACCESS(r),
> > +            ACCESS(w),
> > +            ACCESS(rw),
> > +            ACCESS(x),
> > +            ACCESS(rx),
> > +            ACCESS(wx),
> > +            ACCESS(rwx),
> > +            ACCESS(rx2rw),
> > +            ACCESS(n2rwx),
> > +#undef ACCESS
>
> Unlike x86 I think you have pretty much complete freedom to define
> p2m_access_*? Why not just make them 1:1?
>
> (one for a future cleanup if you prefer)
>

I moved p2m_access_t into common in this version of the series..


>
> > +        /* Seting was found in the Radix tree. */
>
> "Setting"
>

Ack.

Thanks,
Tamas

[-- Attachment #1.2: Type: text/html, Size: 8743 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-09-24 16:17 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23 13:14 [PATCH for-4.5 v8 00/19] Mem_event and mem_access for ARM Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 01/19] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 02/19] xen: Relocate struct npfec definition " Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 03/19] xen: Relocate p2m_access_t into common and swap the order Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 04/19] xen: Relocate p2m_mem_access_resume to mem_access common Tamas K Lengyel
2014-09-23 13:28   ` Jan Beulich
2014-09-23 14:04     ` Tamas K Lengyel
2014-09-23 14:08       ` Jan Beulich
2014-09-23 14:15         ` Tamas K Lengyel
2014-09-23 15:02           ` Jan Beulich
2014-09-23 13:14 ` [PATCH for-4.5 v8 05/19] xen: Relocate set_access_required domctl into common Tamas K Lengyel
2014-09-24 14:18   ` Julien Grall
2014-09-24 15:05     ` Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 06/19] xen: Relocate mem_event_op domctl and access_op memop " Tamas K Lengyel
2014-09-23 13:32   ` Jan Beulich
2014-09-23 14:00     ` Razvan Cojocaru
2014-09-23 14:07       ` Jan Beulich
2014-09-23 14:13         ` Tamas K Lengyel
2014-09-23 14:23           ` Razvan Cojocaru
2014-09-23 14:28             ` Tamas K Lengyel
2014-09-23 14:19         ` Razvan Cojocaru
2014-09-23 14:08       ` Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 07/19] x86/p2m: Typo fix for spelling ambiguous Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 08/19] xen/mem_event: Clean out superfluous white-spaces Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 09/19] xen/mem_event: Relax error condition on debug builds Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 10/19] xen/mem_event: Abstract architecture specific sanity checks Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 11/19] xen/mem_access: Abstract architecture specific sanity check Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 12/19] xen/arm: p2m changes for mem_access support Tamas K Lengyel
2014-09-24 14:40   ` Ian Campbell
2014-09-24 16:58     ` Tamas K Lengyel
2014-09-24 17:14       ` Razvan Cojocaru
2014-09-24 14:43   ` Julien Grall
2014-09-24 16:48     ` Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 13/19] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 14/19] xen/arm: Add p2m_set_permission and p2m_shatter_page helpers Tamas K Lengyel
2014-09-24 14:48   ` Julien Grall
2014-09-23 13:14 ` [PATCH for-4.5 v8 15/19] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-09-24 15:02   ` Ian Campbell
2014-09-24 16:17     ` Tamas K Lengyel [this message]
2014-09-24 15:35   ` Julien Grall
2014-09-24 16:27     ` Tamas K Lengyel
2014-09-24 16:51       ` Julien Grall
2014-09-24 17:13         ` Tamas K Lengyel
2014-09-24 20:52           ` Julien Grall
2014-09-24 21:24             ` Tamas K Lengyel
2014-09-24 22:07               ` Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 16/19] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-09-24 15:05   ` Ian Campbell
2014-09-24 17:04     ` Tamas K Lengyel
2014-09-24 15:41   ` Julien Grall
2014-09-24 17:08     ` Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 17/19] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-09-24 15:08   ` Ian Campbell
2014-09-24 15:42   ` Julien Grall
2014-09-23 13:14 ` [PATCH for-4.5 v8 18/19] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2014-09-23 13:14 ` [PATCH for-4.5 v8 19/19] tools/tests: Enable xen-access " Tamas K Lengyel
2014-09-24 15:12   ` Ian Campbell
2014-09-24 16: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=CAErYnsijgsMf_9omHBugBS9zhtesx6ErQ86khccPROtnAyJJrQ@mail.gmail.com \
    --to=tamas.lengyel@zentific.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=andres@lagarcavilla.org \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=tklengyel@sec.in.tum.de \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).