Re: qemu-kvm: Role of flush_icache_range on PPC

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux