Re: [Xen-devel] about the funtion call memory_type_changed()

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Li, Liang Z
> Sent: Thursday, January 22, 2015 12:29 PM
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > Sent: Wednesday, January 21, 2015 7:22 PM
> > To: Li, Liang Z
> > Cc: Andrew Cooper; Dong, Eddie; Tian, Kevin; Zhang, Yang Z; xen-
> > devel@xxxxxxxxxxxxx; keir@xxxxxxx; Tim Deegan
> > Subject: RE: [Xen-devel] about the funtion call memory_type_changed()
> >
> > >>> On 21.01.15 at 12:14, <liang.z.li@xxxxxxxxx> wrote:
> > >> > I have write a patch according to your suggestions. But there is
> > >> > still a lot of flush_all when the guest booting, and this prolong
> > >> > the guest booting time about 600ms
> > >>
> > >> Without you telling us where those remaining ones come from, I don't
> > >> think we can easily help you.
> > >
> > > When the guest booting, it will initialize the MTRR, and the MSR write
> > > will intercepted by Xen.
> > > Because there are dozens of MSR MTRR operation in the guest, so the
> > > 'mtrr_fix_range_msr_set', 'mtrr_def_type_msr_set'  and
> > > 'mtrr_var_range_msr_set ' will be called many times. And all of them
> > > will eventually call the flush_all, it's similar to '
> > > hvm_load_mtrr_msr '.  It seems not easy to use a batching mechanism in
> > > this case.
> >
> > Indeed - I don't think we can avoid the flushes in that case, except maybe
> > detect cases where the values actually don't change. One question though:
> > Iirc Linux updates the MTRRs only when it finds some problems with them -
> is
> > it Linux that you're seeing this with (in which case investigating _why_ the
> > updates are happening might be worthwhile).
> >
> > > Each Flush_all will consume  5~8 ms,  it is a big problem if a
> > > malicious guest frequently change  the MTRR.
> >
> > A guest doing so can only harm itself, i.e. the word "malicious" is a 
> > little odd
> > to be used here.
> >
> 
> But the flush_all function will exec wbinvd instruction to invalidate the 
> cache,
> this will
> heavily  impact  the system's performance, is that right?
> 

guest can invalidate cache anyway. You can't prevent it (though mitigated by
cache qos feature).

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel