> >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"<address@hidden>
> > > > > > > >
> > > > > > > >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?