Re: [PATCH] libxc: Add xc_domain_hvm_get_mtrr_type() call

[Tim Deegan <tim@xen.org>]

At 16:57 +0200 on 19 Dec (1355936221), Razvan Cojocaru wrote:
> >>     m->overlapped = is_var_mtrr_overlapped(m);
> >>
> >>Looks like that function contains the necessary logic.
> >
> >You're right, but what happens there is that that function depends on
> >the get_mtrr_range() function, which in turn depends on the size_or_mask
> >global variable, which is initialized in hvm_mtrr_pat_init(), which then
> >depends on a global table, and so on. Putting that into libxc is pretty
> >much putting the whole mtrr.c file there.
> 
> This is where it gets tricky:
> 
> static void get_mtrr_range(uint64_t base_msr, uint64_t mask_msr,
>                            uint64_t *base, uint64_t *end)
> {
>     [...]
>     phys_addr = 36;
> 
>     if ( cpuid_eax(0x80000000) >= 0x80000008 )
>         phys_addr = (uint8_t)cpuid_eax(0x80000008);
> 
>     size_or_mask = ~((1 << (phys_addr - PAGE_SHIFT)) - 1);
>     [...]
> }
> 
> specifically, in the cpuid_eax() call, which doesn't make much sense in 
> dom0 userspace.

You can execute the CPUID instruction from dom0 userspace, and get
exactly the same result as Xen does.

(It may, separately, be a bug that Xen uses the host CPUID here and not
a well-defined guest width.  If that gets fixed, the guest address width
will be made available in the save record and you can extract it from
there.)

But also, you don't necessarily need to calculate 'overlapped' for each
MTRR in advance.  It may make sense to do so for speed, as Xen does, but
you could also just handle overlapping MTRRS in your lookup function, by
comparing the address to all MTRRs and handling the case where it
matches more than one.

Tim.