On 03/02/15 09:45, Jan Beulich wrote:
On 19.01.15 at 18:52, 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
>>> On 19.01.15 at 18:52, 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
> pur
>>> On 19.01.15 at 18:52, 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
> pur
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 specifi
... 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.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1767,7 +1767,7 @@ void pv_soft_rdtsc(struct vcpu *v, struc
if ( guest_