[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] Simplify paging_invlpg when flush is notrequired.
>From: Tim Deegan >Sent: 2008年2月4日 19:05 > >At 08:55 +0000 on 03 Feb (1202028939), Keir Fraser wrote: >> Is there a significant advantage to doing this? One other >comment is that I >> don't like extra boolean 0/1 arguments to functions. I'd rather have >> something like paging_invlpg() and paging_invlpg_noflush() >and only have the >> boolean argument to paging.mode->invlpg(). > >As someone (probably Kevin) pointed out before, the entire guest-walk >in sh_invlpg is redundant because we maintain TLB flush discipline on >shadow l2es ourselves. Cleaning that up was on the list of >things to do >when the out-of-sync shadows are done. If we're going to change this >code now, the right thing to do is to kill off sh_invlpg >entirely, except >for the call to vtlb_flush(). Then there's no need for it to return a >value at all. > Well, I guess it should be Xin who since educated me about such redundancy before. :-) But I'm inclined to keep this interface for several reasons: * Shadow currently requires to intercept invlpg as what you mentioned about vtlb and also future fast_emulation I posted before. Call those vtlb-like invalidation inside sh_invlpg is cleaner * I'm not sure how future out-of-sync logic may be implemented, but I guess it may be a dynamic hook, and only active at some special points. If that's the case, sometimes TLB flush may be required and others may not But anyway, this is not important. We can also wait for out-of-sync feature ready and then see how this interface may be affected. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |