On 2019/12/5 上午3:52, Peter Xu wrote:
On Wed, Dec 04, 2019 at 12:04:53PM +0100, Paolo Bonzini wrote:
On 04/12/19 11:38, Jason Wang wrote:
+ entry = &ring->dirty_gfns[ring->dirty_index & (ring->size - 1)];
+ entry->slot = slot;
+ entry->offset = offset;
Haven't gone through the whole series, sorry if it was a silly question
but I wonder things like this will suffer from similar issue on
virtually tagged archs as mentioned in [1].
There is no new infrastructure to track the dirty pages---it's just a
different way to pass them to userspace.
Is this better to allocate the ring from userspace and set to KVM
instead? Then we can use copy_to/from_user() friends (a little bit slow
on recent CPUs).
Yeah, I don't think that would be better than mmap.
Yeah I agree, because I didn't see how copy_to/from_user() helped to
do icache/dcache flushings...
It looks to me one advantage is that exact the same VA is used by both
userspace and kernel so there will be no alias.
Thanks
Some context here: Jason raised this question offlist first on whether
we should also need these flush_dcache_cache() helpers for operations
like kvm dirty ring accesses. I feel like it should, however I've got
two other questions, on:
- if we need to do flush_dcache_page() on kernel modified pages
(assuming the same page has mapped to userspace), then why don't
we need flush_cache_page() too on the page, where
flush_cache_page() is defined not-a-nop on those archs?
- assuming an arch has not-a-nop impl for flush_[d]cache_page(),
would atomic operations like cmpxchg really work for them
(assuming that ISAs like cmpxchg should depend on cache
consistency).
Sorry I think these are for sure a bit out of topic for kvm dirty ring
patchset, but since we're at it, I'm raising the questions up in case
there're answers..
Thanks,
