From: Avi Kivity <avi@redhat.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kvm-ia64@vger.kernel.org" <kvm-ia64@vger.kernel.org>,
Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [PATCH] qemu-kvm: Flush icache after dma operations for ia64
Date: Mon, 11 May 2009 14:11:24 +0300 [thread overview]
Message-ID: <4A0807DC.6080109@redhat.com> (raw)
In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC236B1935F@pdsmsx503.ccr.corp.intel.com>
Zhang, Xiantao wrote:
> Avi
> This is the new patch for icache flush after DMA emualtion for ia64, and it should address Hollis's comments.
> Xiantao
>
> From 60a27e2ea9758c97e974aa5bb1925ad4ed045c5f Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <xiantao.zhang@intel.com>
> Date: Mon, 11 May 2009 18:04:15 +0800
> Subject: [PATCH] qemu-kvm: Flush icache after dma operations for ia64
>
> ia64 system depends on that platform issues snoop cycle to flush
> icache for memory touched by DMA write operations, but virtual DMA
> operations is emulated by memcpy, so use explict instrustions to flush
> the related icache, otherwise, guest may use obsolete icache.
>
>
> +#elif defined(__ia64__)
> +static inline void flush_icache_range(unsigned long start, unsigned long stop)
> +{
> + while (start < stop) {
> + asm volatile ("fc %0" :: "r"(start));
> + start += 32;
> + }
> + asm volatile (";;sync.i;;srlz.i;;");
> +}
> +#define qemu_cache_utils_init(envp) do { (void) (envp); } while (0)
> #else
> #define qemu_cache_utils_init(envp) do { (void) (envp); } while (0)
> #endif
> diff --git a/cutils.c b/cutils.c
> index a1652ab..6b7d506 100644
> --- a/cutils.c
> +++ b/cutils.c
> @@ -25,6 +25,10 @@
> #include "host-utils.h"
> #include <assert.h>
>
> +#ifdef __ia64__
> +#include "cache-utils.h"
> +#endif
>
#includes should be unconditional.
> +
> void pstrcpy(char *buf, int buf_size, const char *str)
> {
> int c;
> @@ -176,6 +180,16 @@ void qemu_iovec_from_buffer(QEMUIOVector *qiov, const void *buf, size_t count)
> if (copy > qiov->iov[i].iov_len)
> copy = qiov->iov[i].iov_len;
> memcpy(qiov->iov[i].iov_base, p, copy);
> +
> + /*ia64 system depends on that platform issues snoop cycle to flush
> + * icache for memory touched by DMA write operations, but virtual DMA
> + * operations is emulated by memcpy, so use explict instrustions to flush
> + * the related icache, otherwise, guest may use obsolete icache. */
> +#ifdef __ia64__
> + flush_icache_range((unsigned long)qiov->iov[i].iov_base,
> + (unsigned long)(qiov->iov[i].iov_base + copy));
> +#endif
>
Instead of the #ifdef, please add a flush_icache_range_after_dma()
function which does flush_icache_range() for ia64 and nothing for other
architectures. This avoids the #ifdef everywhere, and you will only
need one copy of the comment.
I don't think you need to flush here. Instead, put the flush in
cpu_physical_memory_unmap(). Every dma access should invoke that. If
you find a path which doesn't, it should be fixed.
>
> +#ifdef __ia64__
> +#include "cache-utils.h"
> +#endif
>
Unconditional #include.
> +
> static AIOPool dma_aio_pool;
>
> void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint)
> @@ -149,6 +153,23 @@ static BlockDriverAIOCB *dma_bdrv_io(
> dbs->bh = NULL;
> qemu_iovec_init(&dbs->iov, sg->nsg);
> dma_bdrv_cb(dbs, 0);
> +
> + /*ia64 system depends on that platform issues snoop cycle to flush
> + * icache for memory touched by DMA write operations, but virtual DMA
> + * operations is emulated by memcpy, so use explict instrustions to flush
> + * the related icache, otherwise, guest may use obsolete icache. */
> +#ifdef __ia64__
> + int i;
> + QEMUIOVector *qiov;
> + if (!is_write) {
> + qiov = &dbs->iov;
> + for (i = 0; i < qiov->niov; ++i) {
> + flush_icache_range((unsigned long)qiov->iov[i].iov_base,
> + (unsigned long)(qiov->iov[i].iov_base + qiov->iov[i].iov_len));
> + }
> + }
> +#endif
>
If you move the flush to cpu_physical_memory_unmap(), this can go away.
> +
> if (!dbs->acb) {
> qemu_aio_release(dbs);
> return NULL;
> diff --git a/exec.c b/exec.c
> index 29c91fb..170ede1 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -35,6 +35,7 @@
> #include "cpu.h"
> #include "exec-all.h"
> #include "qemu-common.h"
> +#include "cache-utils.h"
>
> #if !defined(TARGET_IA64)
> #include "tcg.h"
> @@ -3402,8 +3403,12 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
> }
> addr1 += l;
> access_len -= l;
> - }
> - }
> + }
> +#ifdef TARGET_IA64
> + flush_icache_range((unsigned long)buffer,
> + (unsigned long)buffer + access_len);
> +#endif
> + }
>
Whitespace damage.
access_len here is zero, so this does nothing.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-05-11 11:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 10:20 [PATCH] qemu-kvm: Flush icache after dma operations for ia64 Zhang, Xiantao
2009-05-11 11:11 ` Avi Kivity [this message]
2009-05-25 10:55 ` Jes Sorensen
2009-05-25 10:56 ` Jes Sorensen
2009-05-25 11:25 ` Avi Kivity
2009-05-25 13:12 ` Jes Sorensen
2009-05-26 12:30 ` Avi Kivity
2009-06-01 5:40 ` Zhang, Xiantao
2009-06-01 7:45 ` Avi Kivity
2009-06-02 10:56 ` Jes Sorensen
2009-06-02 15:20 ` Zhang, Xiantao
2009-06-04 13:09 ` Jes Sorensen
2009-06-05 1:38 ` Zhang, Xiantao
2009-06-05 11:13 ` Jes Sorensen
2009-06-07 6:28 ` Avi Kivity
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=4A0807DC.6080109@redhat.com \
--to=avi@redhat.com \
--cc=hollisb@us.ibm.com \
--cc=kvm-ia64@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=xiantao.zhang@intel.com \
/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).