linux-kernel - Re: [Xen-devel] [PATCH] xen: add steal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2016 13:20:21 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Dario Faggioli <dario.faggioli@...rix.com>,
	Juergen Gross <jgross@...e.com>,
	xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Cc:	sstabellini@...nel.org, david.vrabel@...rix.com,
	Tony S <suokunstar@...il.com>
Subject: Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On 05/18/2016 12:10 PM, Dario Faggioli wrote:
> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>>  
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too? It is a
>> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
>> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
>>
> So, config options aside, if I understand this correctly, it looks like
> we were actually already doing steal time accounting, although in a
> non-standard way.
>
> And yet, people seem to have issues relating to lack of (proper?) steal
> time accounting (Cc-ing Tony).
>
> I guess this means that, either:
>  - the issue being reported is actually not caused by the lack of 
>    steal time accounting,
>  - our current (Xen specific) steal time accounting solution is flawed,
>  - the issue is caused by the lack of the bit of steal time accounting
>    that we do not support yet,

I believe it's this one.

Tony narrowed the problem down to update_curr() where vruntime is
calculated, based on runqueue's clock_task value. That value is computed
in update_rq_clock_task(), which needs paravirt_steal_rq_enabled.

-boris

>  - other ideas? Tony?
>
> Dario