Re: [Xen-devel] [PATCH] libxc: Add xc_domain_hvm_get_mtrr_type() call

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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