Re: [PATCH 19/38] KVM: PPC: Add cache flush on page map

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/15/2012 02:29 PM, Alexander Graf wrote:
> 
> On 15.08.2012, at 21:05, Scott Wood wrote:
> 
>> On 08/15/2012 01:58 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 20:56, Scott Wood wrote:
>>>
>>>> On 08/15/2012 01:51 PM, Alexander Graf wrote:
>>>>>
>>>>> On 15.08.2012, at 20:33, Scott Wood wrote:
>>>>>
>>>>>> On 08/15/2012 01:29 PM, Alexander Graf wrote:
>>>>>>> Ah, if I read Ben's comment correctly we only need it for rom loads, not always for cpu_physical_memory_rw.
>>>>>>
>>>>>> Why?
>>>>>
>>>>> Because guest Linux apparently assumes that DMA'd memory needs to be icache flushed.
>>>>
>>>> What about breakpoints and other debug modifications?
>>>
>>> The breakpoint code is arch specific. We can just put an icache flush in there.
>>
>> That doesn't cover other modifications that a debugger might do
>> (including manual poking at code done by a person at the command line).
> 
> Why not? This would go through gdbstub,

Not necessarily.  I could be poking at memory from the QEMU command
line.  If there isn't a command for that, there should be. :-)

> where we can always put in an icache flush.

If you want to cover every individual place where this function is
called for non-DMA, fine, though I'd feel more comfortable with
something that specifically identifies the access as for DMA.

>>>>>> And it's possible (if not necessarily likely) that other guests are
>>>> different.
>>>
>>> Does fsl hardware guarantee icache coherency from device DMA?
>>
>> I don't think so, but I don't know of any fsl hardware that leaves dirty
>> data in the dcache after DMA.  Even with stashing on our newer chips,
>> the data first goes to memory and then the core is told to prefetch it.
> 
> For Linux, I think we always flush the dcache when flushing the
> icache. However, that argument is reasonably valid. We probably want
> to flush the dache on DMA, so that a stale icache can fetch it from
> memory properly. But I don't see a reason why we would want to do so
> for the icache if hardware doesn't do it either.
> 
> But let's get Ben on board here :).

The only reason to invalidate the icache on DMA accesses would be to
avoid introducing a special case in the QEMU code, unless we find
hardware to emulate that does invalidate icache on DMA writes but isn't
icache-coherent in general (it's fairly plausable -- icache would act on
snoops it sees on the bus, but icache fills wouldn't issue snoops of
their own).

-Scott


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux