[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 18:29 +0200 on 19 Dec (1355941750), Razvan Cojocaru wrote:
> >>Ah - I see your concern.  Yes - it might well be different.  Is this
> >>information passed in an HVM save record?  It does not appear to be
> >>associated with the MTRR HVM save record.
> >
> >No , this is the internal state not the save record but Razvan is
> >implementing the same logic in libxc which must necessarily be based on
> >the hvm saved state only and not the internal emulation state.
> 
> Exactly, and all I need extra an extra variable in the save record (or 
> simply a single bit in a safe place in one of the existing ones), 
> telling me if the MTRRs are overlapped or not. The CPUID code is just a 
> part of the logic that finds this out in the hypervisor; and 
> specifically it is a part that's better _left_in_ the hypervisor. That 
> is in fact what I was trying to say a few messages ago, when I called 
> the cpuid_eax() function the tricky part. :)
> 
> Do we agree that a bool_t overlapped should be added to struct 
> hvm_hw_mtrr for this case?

Sorry, no.  The 'overlapped' bit is a piece of xen implementation, and
not an architectural state of the VM, so it doesn't belong in the save
record.  It's trivial to recalculate in a user-space tool, and the
result can be cached (since you can also get a mem-event on MSR writes,
you don't have to pull all this MTRR state out of the giuest except when
the MTRRs have been changed).

I'll take a proper look at this thread tomorrow and see if I can suggest
anything more helpful. 

Tim.

_______________________________________________
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®.