[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.