[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
On Tue, 2012-12-18 at 17:24 +0000, Razvan Cojocaru wrote: > Thanks for the reply! > > > Do you have a user in mind for this new functionality? > > Yes. An (userspace) application that needs to look at this information > to decide if a set of pages are interesting for monitoring. > > > This version seems to do a lot less than get_mtrr_type() in the > > hypervisor. Is that deliberate? Why isn't the fixed mtrr slot and > > overlap handling required here? > > It does do less. It's somewhat deliberate :), ideally it should have > done everything that get_mtrr_type() does. It did work with my initial > test addresses, but clearly more is required if it is to provide the > full functionality of get_mtrr_type(). The code currently only iterates > through the var_ranges, not the fixed array, etc. > > The overlap handling isn't there because there doesn't seem to be a > clear correspondence between struct mtrr_state and struct hvm_hw_mtrr. > I implemented as much of the get_mtrr_type() logic as was obvious using > what mapping was clear bewtween them. > > Is having the full functionality in libxc feasible? It would certainly be preferable to have libxc do it now rather than every application it or having to introduce cleverer versions of the API in the future. I don't know enough about MTRRs or how Xen represents them either internally or at the hypercall interface to have a sensible opinion about the feasibility but my gut feeling is that there's no reason it shouldn't be. >From a brief look it seems like hvm_hw_mtrr is a subset of mtrr_state, which makes sense since you would expect the internal state (struct mtrr_state) to cache or precompute some stuff for efficiency while emulating but you don't want to expose that in the architectural state (struct hvm_hw_mtrr). libxc can (and should) probably recompute anything it needs above what is in hvm_hw_mtrr on the fly (e.g. check for overlaps). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |