[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] libxc: Add xc_domain_hvm_get_mtrr_type() call
At 18:29 +0200 on 19 Dec (1355941750), Razvan Cojocaru wrote: > >>Ah - I see your concern. Yes - it might well be different. Is this > >>information passed in an HVM save record? It does not appear to be > >>associated with the MTRR HVM save record. > > > >No , this is the internal state not the save record but Razvan is > >implementing the same logic in libxc which must necessarily be based on > >the hvm saved state only and not the internal emulation state. > > Exactly, and all I need extra an extra variable in the save record (or > simply a single bit in a safe place in one of the existing ones), > telling me if the MTRRs are overlapped or not. The CPUID code is just a > part of the logic that finds this out in the hypervisor; and > specifically it is a part that's better _left_in_ the hypervisor. That > is in fact what I was trying to say a few messages ago, when I called > the cpuid_eax() function the tricky part. :) > > Do we agree that a bool_t overlapped should be added to struct > hvm_hw_mtrr for this case? Sorry, no. The 'overlapped' bit is a piece of xen implementation, and not an architectural state of the VM, so it doesn't belong in the save record. It's trivial to recalculate in a user-space tool, and the result can be cached (since you can also get a mem-event on MSR writes, you don't have to pull all this MTRR state out of the giuest except when the MTRRs have been changed). I'll take a proper look at this thread tomorrow and see if I can suggest anything more helpful. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |