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

["Li, Liang Z" <liang.z.li@xxxxxxxxx>]

> -----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?



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