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

[Razvan Cojocaru <rzvncj@xxxxxxxxx>]

> 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 agree.

> 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.
Unfortunately I'm far from being an expert on MTRRs too, so maybe 
someone can tell us what the equivalent of this:
uint8_t get_mtrr_type(struct mtrr_state *m, paddr_t pa)
{
    [...]
    if ( unlikely(!(m->enabled & 0x2)) )
        return MTRR_TYPE_UNCACHABLE;
    [...]
}

whould be with libxc code using struct hvm_hw_mtrr? Or, more to the 
point, what the equivalent of m->enabled is in this:
struct hvm_hw_mtrr {
#define MTRR_VCNT 8
#define NUM_FIXED_MSR 11
    uint64_t msr_pat_cr;
    /* mtrr physbase & physmask msr pair*/
    uint64_t msr_mtrr_var[MTRR_VCNT*2];
    uint64_t msr_mtrr_fixed[NUM_FIXED_MSR];
    uint64_t msr_mtrr_cap;
    uint64_t msr_mtrr_def_type;
};

I'm also having a hard time figuring out how to map m->overlapped on the 
hvm_hw_mtrr members. It's also quite possible (to me, at least, at this 
stage) that they're not needed because at libxc level they're assumed to 
be set to some value (i.e. 'overlapped' is assumed to be 0, 'enabled' to 
be 1).
Any help is appreciated, if we clear this up I'll modify and re-submit 
the patch.
Thanks,
Razvan Cojocaru

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