On 18.06.19 07:48, Pratyush Yadav wrote:
On 17/06/19 10:15 PM, Jan Kiszka wrote:
On 17.06.19 16:27, 'Pratyush Yadav' via Jailhouse wrote:
Hi,
I am writing a driver for a device that accesses some in-memory data structures.
Right now I'm using page_alloc(&mem_pool, ...) to allocate those structures,
but I suspect this memory is cacheable, and thus updates to the in-memory
structures won't necessarily be visible to the device.
I suspect you mean you write a driver inside Jailhouse, right? Why is that
driver needed in hypervisor space?
The driver is for the SMMU (an IOMMU for ARM systems). It is in hypervisor
space because the same SMMU can be responsible for multiple cells.
Yes, that makes sense, of course.
Yes, hypervisor memory, including that which comes from page_alloc, is mapped
cacheable. But why can't you evict the content from cache to RAM when that
device should see it? That's how we generally work.
That is what I'm doing right now. I call arch_paging_flush_cpu_caches()
whenever there is any update to those structures. But I thought it would be
better if the memory was not cacheable to begin with.
No, it's not. It's often slower, specifically if you have a read-modify-write
cycle or need to change multiple words in a cacheline at once. Therefore it's
not how such drivers are typically written. Just look at Linux. Or at our
x86/vtd.c, e.g. inv_queue_write().
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/d04a4f50-32ea-daf3-5238-7c416f3c95a9%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
