[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: re-order struct arch_domain fields



>>> On 19.01.15 at 18:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/01/15 15:41, Jan Beulich wrote:
>> ... to reduce padding holes. While doing this I noticed vtsc_usercount
>> is a PV-only thing, so it gets moved straight to struct pv_domain.
> 
> The vtsc_{user,kernel}count split is curious.  They are both for stats
> purposes alone, but there is nothing pv specific about the usercount. 
> It frankly looks as if it has been mis-implemented for HVM, despite the
> split appearing to be deliberate when it was introduced in c/s
> bf2c44f8b469.  I am really not sure what to make of it.

Since I didn't hear back on my earlier response, I looked at this again:
Considering especially the explicit callers of hvm_get_guest_tsc_fixed(),
I also wonder whether the accounting for HVM makes sense in the
first place - to me, these two numbers are meant to be _only_ counting
actual emulations. Hence I first of all would think this ought to be
moved into hvm_rdtsc_intercept() (and maybe mirrored in
hvm_msr_read_intercept(), perhaps by refactoring the former to be
usable by the latter).

In that case it would indeed make sense to keep the user count for
non-PV, as then it really makes sense to check for user/kernel mode
there.

Jan


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