From: Julien Grall <julien.grall@linaro.org>
To: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
Cc: Tim Deegan <tim@xen.org>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH] xen: arm: invalidate caches after map_domain_page done
Date: Fri, 01 Aug 2014 15:01:07 +0100 [thread overview]
Message-ID: <53DB9DA3.2080109@linaro.org> (raw)
In-Reply-To: <CAH_mUMM6sAWEXPJfXEGhcHeQYCKmuagQd9mHQ5yXH3Qz2ABJBA@mail.gmail.com>
On 01/08/14 12:37, Andrii Tseglytskyi wrote:
>> The page you are trying to map belongs to a guest, right? When the guest
>> writes data in this page. Does it map with cacheable attribute or not? I
>> suspect no.
>
> Hard to say. This page is allocated using usual kernel API such as
> kmalloc(). Then its pfn is stored in MMU 1-st level translation
> pagetable.
If it's allocated from kmalloc then the page is allocated with cacheable
attribute.
> Before storing - kernel driver flush corresponding cache ranges.
Clean and invalidate the cache, right?
> After
> this - remoteproc_iommu framework translates pfns to mfns.
> So - I would expect that after map_domain_page() function call all
> data will be valid.
Actually with your explanation me too. :)
I'm run out of idea. Maybe Ian or Stefano have any clue.
>>
>> I think your current problem is the cache contains stall data. In this case
>> you have to only invalidate the cache.
>>
>
> May work. But it looks like new helper should be introduced in this
> case. I see that only clean_and_invalidate_xen_dcache_va_range API is
> present, no standalone API for invalidating only.
You can add a new helper. I suspect it will be necessary sooner or later
in other places.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-08-01 14:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 7:25 [PATCH] xen: arm: invalidate caches after map_domain_page done Andrii Tseglytskyi
2014-08-01 9:23 ` Julien Grall
2014-08-01 10:01 ` Andrii Tseglytskyi
2014-08-01 10:28 ` Julien Grall
2014-08-01 10:50 ` Andrii Tseglytskyi
2014-08-01 10:58 ` Julien Grall
2014-08-01 11:37 ` Andrii Tseglytskyi
2014-08-01 14:01 ` Julien Grall [this message]
2014-08-01 15:06 ` Andrii Tseglytskyi
2014-08-01 17:49 ` Julien Grall
2014-08-01 18:54 ` Andrii Tseglytskyi
2014-08-05 14:33 ` 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=53DB9DA3.2080109@linaro.org \
--to=julien.grall@linaro.org \
--cc=andrii.tseglytskyi@globallogic.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--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 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.