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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 03/02/15 09:45, Jan Beulich wrote:
>>>> 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
>

I agree with your analysis.  Now that you point it out, the current code
does look wrong.

~Andrew


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