All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: "Aravindh Puthiyaparambil (aravindp)" <aravindp@cisco.com>
Cc: Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	"Andres Lagar-Cavilla (andreslc@gridcentric.ca)"
	<andreslc@gridcentric.ca>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH RFC 1/4] x86/mm: Shadow and p2m changes for PV mem_access
Date: Thu, 1 May 2014 16:18:35 +0200	[thread overview]
Message-ID: <20140501141835.GD77240@deinos.phlegethon.org> (raw)
In-Reply-To: <97A500D504438F4ABC02EBA81613CC63317E9527@xmb-aln-x02.cisco.com>

At 22:20 +0000 on 30 Apr (1398892838), Aravindh Puthiyaparambil (aravindp) wrot> >>>> @@ -2443,7 +2443,8 @@ int sh_remove_all_mappings(struct vcpu *v,
> >>>mfn_t gmfn)
> >>>>          if ( !(shadow_mode_external(v->domain)
> >>>>                 && (page->count_info & PGC_count_mask) <= 3
> >>>>                 && ((page->u.inuse.type_info & PGT_count_mask)
> >>>> -                   == !!is_xen_heap_page(page))) )
> >>>> +                       == !!is_xen_heap_page(page)))
> >>>> +                    && !(shadow_mode_mem_access(v->domain)) )
> >>>
> >>>You're breaking indentation, there are pointless parentheses again,
> >>>but most importantly - why?
> >>
> >> Sorry, I meant to ask a question about this in my patch message and
> >> mark this as a workaround. I am seeing the message on all
> >> sh_remove_all_mappings() and I was not able to figure out why this was
> >> happening. I just added this as a work around. I was hoping you or Tim
> >would shed more light on this.
> >
> >I'm afraid that without detail on which pages the triggers on, and you at least
> >having spent some time finding out where the stray/extra references may be
> >coming from it's going to be hard to help.
> 
> Here are some of the prints I saw. I typically saw it for every set_entry() call.
> 
> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn 33960: c=8000000000000002 t=7400000000000000 <most common>
>  (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn 134b8: c=8000000000000038 t=7400000000000001

This is because you are not in shadow_mode_refcounts() (i.e. the
page's refcount and typecount are based on the _guest_ pagetables
rather than the _shadow_ ones).  That means that sh_remove_all_mappings()
can't use the refcounts to figure out when it's removed the last
shadow mapping.

That also means that sh_remove_all_mappings() will have had to search
every sl1e in the system, which is expensive.  If there will be a lot
of these updates, you might consider batching them and using
shadow_blow_tables() after each batch instead.

Tim.

  parent reply	other threads:[~2014-05-01 14:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  4:45 [PATCH RFC 0/4] Add mem_access support for PV domains Aravindh Puthiyaparambil
2014-04-29  4:45 ` [PATCH RFC 1/4] x86/mm: Shadow and p2m changes for PV mem_access Aravindh Puthiyaparambil
2014-04-29  8:50   ` Jan Beulich
2014-04-29 23:10     ` Aravindh Puthiyaparambil (aravindp)
2014-04-30  6:32       ` Jan Beulich
2014-04-30 22:20         ` Aravindh Puthiyaparambil (aravindp)
2014-05-01  1:11           ` Andres Lagar-Cavilla
2014-05-01  3:18             ` Aravindh Puthiyaparambil (aravindp)
2014-05-01 14:18           ` Tim Deegan [this message]
2014-05-01 19:14             ` Aravindh Puthiyaparambil (aravindp)
2014-05-08 12:44               ` Tim Deegan
2014-05-02  8:26           ` Jan Beulich
2014-05-02 16:28             ` Aravindh Puthiyaparambil (aravindp)
2014-04-29 12:05   ` Tamas Lengyel
2014-04-29 23:36     ` Aravindh Puthiyaparambil (aravindp)
2014-05-01 14:39   ` Tim Deegan
2014-05-01 19:26     ` Aravindh Puthiyaparambil (aravindp)
2014-04-29  4:45 ` [PATCH RFC 2/4] x86/mem_access: mem_access and mem_event changes to support PV domains Aravindh Puthiyaparambil
2014-04-29  4:45 ` [PATCH RFC 3/4] tools/libxc: Add APIs to create and get the PV ring page Aravindh Puthiyaparambil
2014-05-02 12:41   ` Ian Campbell
2014-04-29  4:45 ` [PATCH RFC 4/4] tool/xen-access: Add support for PV domains Aravindh Puthiyaparambil
2014-05-02 12:43   ` Ian Campbell

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=20140501141835.GD77240@deinos.phlegethon.org \
    --to=tim@xen.org \
    --cc=JBeulich@suse.com \
    --cc=andreslc@gridcentric.ca \
    --cc=aravindp@cisco.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@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.