[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 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |