From: Wei Liu <wei.liu2@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued
Date: Fri, 27 Jan 2017 15:54:41 +0000 [thread overview]
Message-ID: <20170127155441.euv4d2apsf67mkd6@citrix.com> (raw)
In-Reply-To: <CAErYnshPMX0a7_TpQEs2WNUGsr+i9AJNjGTijUGhhjXEgMG1Qw@mail.gmail.com>
On Fri, Jan 27, 2017 at 08:52:50AM -0700, Tamas K Lengyel wrote:
> On Jan 27, 2017 08:43, "Wei Liu" <wei.liu2@citrix.com> wrote:
>
> On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> > On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> > > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> > >> When the toolstack modifies memory of a running ARM VM it may happen
> > >> that the underlying memory of a current vCPU PC is changed. Without
> > >> flushing the icache the vCPU may continue executing stale instructions.
> > >>
> > >
> > > Why is this not an issue for x86? Is this because ARM handles coherency
> > > differently from x86?
> > >
> > >> In this patch we introduce VA-based icache flushing macros. Also expose
> > >> the xc_domain_cacheflush through xenctrl.h.
> > >>
> > >> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> > >> ---
> > >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >> Cc: Wei Liu <wei.liu2@citrix.com>
> > >> Cc: Stefano Stabellini <sstabellini@kernel.org>
> > >> Cc: Julien Grall <julien.grall@arm.com>
> > >>
> > >> Note: patch has been verified to solve stale icache issues on the
> > >> HiKey platform.
> > >> ---
> > >> tools/libxc/include/xenctrl.h | 6 ++++++
> > >> tools/libxc/xc_private.h | 3 ---
> > >> xen/arch/arm/mm.c | 1 +
> > >> xen/include/asm-arm/arm32/page.h | 3 +++
> > >> xen/include/asm-arm/arm64/page.h | 3 +++
> > >> xen/include/asm-arm/page.h | 31 +++++++++++++++++++++++++++++++
> > >> 6 files changed, 44 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> > >> index 63c616ff6a..cb80a2b07c 100644
> > >> --- a/tools/libxc/include/xenctrl.h
> > >> +++ b/tools/libxc/include/xenctrl.h
> > >> @@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char
> *name, uint32_t timeout);
> > >> int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t
> timeout);
> > >> int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t
> timeout);
> > >>
> > >> +/*
> > >> + * ARM only. Ensure cache coherency after memory modifications.
> > >> + */
> > >
> > > The existing code doesn't suggest this is ARM only. This function is
> > > used in xc_dom_unmap_one etc. This comment looks wrong.
> > >
> > > I don't object to making this function externally visible though.
> > >
> > > Wei.
> >
> > Hi Wei,
> > the comment is correct, this domctl is for ARM only. If you check the
> > code in xc_domain.c for the function, you will find this:
> >
> > #if defined (__i386__) || defined (__x86_64__)
> > /*
> > * The x86 architecture provides cache coherency guarantees which
> prevent
> > * the need for this hypercall. Avoid the overhead of making a
> hypercall
> > * just for Xen to return -ENOSYS.
> > */
> > errno = ENOSYS;
> > return -1;
> > #else
> >
> > I guess I could move this comment to xenctrl.h to avoid confusions like
> this.
> >
>
> Maybe it is just me: I read this comment differently. It suggests only
> ARM code can call this function. In reality x86 can call it too, but it
> has no effect.
>
> I would suggest either just drop the comment or make clear it only has
> effect on ARM.
>
>
> Well, yes, only ARM could _should_ call this function. The comment I think
> is important to tell the user don't expect it to do anything on x86.
> Doesn't mean they can't call it though - if that was the case it would be
> wrapped in an ifdef like all the other architecture specific bits in the
> header. I would think that's pretty straight forward. No objection to
> clarifing the comment though if it helps.
>
Clarifying would be good enough for me.
> Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-01-27 16:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 22:16 [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued Tamas K Lengyel
2017-01-27 14:49 ` Wei Liu
2017-01-27 15:37 ` Tamas K Lengyel
2017-01-27 15:43 ` Wei Liu
2017-01-27 15:52 ` Tamas K Lengyel
2017-01-27 15:54 ` Wei Liu [this message]
2017-01-27 16:15 ` Julien Grall
2017-01-27 16:23 ` Tamas K Lengyel
2017-01-27 16:29 ` Julien Grall
2017-01-27 16:32 ` Tamas K Lengyel
2017-01-27 16:35 ` Wei Liu
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=20170127155441.euv4d2apsf67mkd6@citrix.com \
--to=wei.liu2@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=tamas.lengyel@zentific.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.