[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



There is a section in the Intel SDM (chapter 10.4 in my copy) which
explains the meanings etc of the registers, which are what is exposed in
hvm_hw_mtrr I think.

Thanks, I'll look that up.

xen/arch/x86/hvm/mtrr.c:mtrr_def_type_msr_set() seems to be where it is
written, and it is called with hw_mtrr.msr_mtrr_def_type so it looks
like it can be derived from that value in hvm_hw_mtrr.

Indeed it is, but this happens there:

uint8_t def_type = msr_content & 0xff;
uint8_t enabled = (msr_content >> 10) & 0x3;

So what ends up being put in def_type is only one byte of msr_content, whereas enabled is some bits from another byte of msr_content. To make matters worse, hw_mtrr.msr_mtrr_def_type is an uint64_t, so would that mean that hw_mtrr.msr_mtrr_def_type is actually the whole of msr_content?

I'm also having a hard time figuring out how to map m->overlapped on the
hvm_hw_mtrr members.

     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.

Is this amount of copy/paste code a good thing, and wouldn't it be less tedious and bug-prone to have that code in a single place, and just add overlapped and enabled to hw_mtrr before sending it out into userspace?

Thanks,
Razvan Cojocaru

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.