On Fri, Nov 11, 2016 at 12:15:48PM +0800, Jason Wang wrote: > > > On 2016年11月11日 11:39, Michael S. Tsirkin wrote: > > 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? > > I guess this may do the detection: > > 1) map iova A to be non-present. > 2) invalidate iova A > 3) map iova A to addr B > 4) access iova A > > A correct implemented CM may meet fault in step 4, but with this patch, we > never.
I think that IOTLB is free to invalidate entries at any point, so the fault is not guaranteed on bare metal. -- MST
