On Fri, Nov 11, 2016 at 10:32:42AM +0800, Jason Wang wrote: > > > On 2016年11月10日 06:00, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 03:28:02PM +0800, Jason Wang wrote: > > > > > > > > > > > >On 2016年11月08日 19:04, Aviv B.D wrote: > > > > > >From: "Aviv Ben-David"<bd.a...@gmail.com> > > > > > > > > > > > >This capability asks the guest to invalidate cache before each map > > > > > >operation. > > > > > >We can use this invalidation to trap map operations in the > > > > > >hypervisor. > > > > > > > >Hi: > > > > > > > >Like I've asked twice in the past, I want to know why don't you cache > > > >translation faults as what spec required (especially this is a guest > > > >visible > > > >behavior)? > > > > > > > >Btw, please cc me on posting future versions. > > > > > > > >Thanks > > Caching isn't guest visible. > > Seems not, if one fault mapping were cached by IOTLB. Guest can notice this > behavior.
Sorry, I don't get what you are saying. > > Spec just says you*can* cache, > > not that you must. > > > > Yes, but what did in this patch is "don't". What I suggest is just a "can", > since anyway the IOTLB entries were limited and could be replaced by other. > > Thanks Have trouble understanding this. Can you given an example of a guest visible difference?
