Re: [Qemu-devel] qemu-kvm: Role of flush_icache_range on PPC

[Alexander Graf]

Am 28.09.2011 um 16:49 schrieb Jan Kiszka <address@hidden>:

> On 2011-09-28 16:45, Jan Kiszka wrote:
>> On 2011-09-28 16:26, Alexander Graf wrote:
>>> 
>>> On 28.09.2011, at 16:23, Jan Kiszka wrote:
>>> 
>>>> Alex,
>>>> 
>>>> we have this diff in qemu-kvm:
>>>> 
>>>> diff --git a/exec.c b/exec.c
>>>> index c1e045d..f188549 100644
>>>> --- a/exec.c
>>>> +++ b/exec.c
>>>> @@ -3950,6 +3955,11 @@ void cpu_physical_memory_rw(target_phys_addr_t
>>>> addr, uint8_t *buf,
>>>> cpu_physical_memory_set_dirty_flags(
>>>> addr1, (0xff& ~CODE_DIRTY_FLAG));
>>>> }
>>>> + /* qemu doesn't execute guest code directly, but kvm does
>>>> + therefore flush instruction caches */
>>>> + if (kvm_enabled())
>>>> + flush_icache_range((unsigned long)ptr,
>>>> + ((unsigned long)ptr)+l);
>>>> qemu_put_ram_ptr(ptr);
>>>> }
>>>> } else {
>>>> 
>>>> 
>>>> flush_icache_range() is doing something only on PPC hosts. So do we need
>>>> this upstream?
>>> 
>>> This makes sure that when device emulation overwrites code that is
>>> already present in the cache of a CPU, it gets flushed from the
>>> icache. I'm fairly sure we want that :). But let's ask Ben and David
>>> as well.
>> 
>> /me wondered which write scenario precisely needs this. It could only be
>> something synchronous /wrt to some VCPU. Which operations could trigger
>> such a write? Does PPC inject software breakpoints in form of trap
>> operations or so?
>> 
>> Mmm, according to our ancient recordings, the hunk above was once
>> introduced for the sake of IA64: 9dc99a2823. I skipped it in my removal
>> patch as it has some non-IA64 effect, at least potentially.
> 
> Correction: It was introduced by 6d3295f7c8, but generalized with f067512c06. 
> That former commit talks about DMA operations on IA64 that also updates/drops 
> the icache in reality.

Yeah I remember discussions around the topic. IIUC DMA invalidates the cache 
lines of the CPUs in the system for the region it's writing to. At least 
potentially. But again, I'll leave this to the IBM guys to answer :). They know 
best how their hardware works.

Alex

>