From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Cc: kvm-devel@lists.sourceforge.net,
kvm-ppc-devel@lists.sourceforge.net, hollisb@us.ibm.com,
qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync icache for morearchitectures
Date: Fri, 14 Dec 2007 10:07:55 +0100 [thread overview]
Message-ID: <476247EB.9040003@linux.vnet.ibm.com> (raw)
In-Reply-To: <42DFA526FC41B1429CE7279EF83C6BDCAD01E3@pdsmsx415.ccr.corp.intel.com>
Zhang, Xiantao wrote:
>Christian Ehrhardt wrote:
<[...]
>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>> addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>> TARGET_PAGE_BITS] |= (0xff &
>> ~CODE_DIRTY_FLAG); }
>> -#ifdef __ia64__
>> - kvm_sync_icache((unsigned long)ptr, l);
>> +#ifdef USE_KVM
>> + flush_icache_range((unsigned long)ptr, ((unsigned
> long)ptr)+l);
>
> Are you sure ia64 implement this function for applications ? I didn't
> find it at my side, so I write it.
What do you mean with "implement it for applications" ?
Take a look at dyngen.h - it starts with the comment "dyngen helpers"
and contains a lot of static functions to use them where you need.
I don't see anything obvious that would prevent these functions from
being built and the file has no own include statements which may
change that. Therefor the include "dyngen.h" in the USE_KVM case
should be enough to have this function available for
cpu_physical_memory_rw in exec.c where we need it.
[...]
> Xiantao
---
Hollis Blanchard wrote:
> A comment to explain why the icache needs flushing only in the KVM case
> would be useful. Other than that I'm fine with it.
>
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
AFAIK Plain qemu does not directly execute guest code on the processor,
so the icache is not an issue for it.
Qemu itself has the flush_icache_range function only as helper for the
dynamic code generation.
But we may now write executable guest code with our intercepted mmio
handling that is directly executed when switching back to the guest
context, therefore we need that invalidation in the kvm case.
For the case that I'm overlooking something in plain qemu, so that it
might need it too I add qemu-devel@nongnu.org for comments from there,
but currently I think to have it in #ifdef USE_KVM is the right way.
P.S. Hollis did you mean you would like to see a comment in the code
where that call takes place?
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt@linux.vnet.ibm.com
Ehrhardt@de.ibm.com
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
next parent reply other threads:[~2007-12-14 9:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11975745782686-git-send-email-ehrhardt@linux.vnet.ibm.com>
[not found] ` <42DFA526FC41B1429CE7279EF83C6BDCAD01E3@pdsmsx415.ccr.corp.intel.com>
2007-12-14 9:07 ` Christian Ehrhardt [this message]
2007-12-14 10:18 ` [Qemu-devel] RE: [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync icache for morearchitectures Zhang, Xiantao
2007-12-18 1:56 ` [Qemu-devel] " Hollis Blanchard
2007-12-18 12:58 ` Christian Ehrhardt
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=476247EB.9040003@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=hollisb@us.ibm.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=kvm-ppc-devel@lists.sourceforge.net \
--cc=qemu-devel@nongnu.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).