linux-kernel - Re: [PATCH v2 3/7] KVM-HV: KVM Steal time implementation

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]

Message-ID: <4DFEE276.9020403@redhat.com>
Date:	Mon, 20 Jun 2011 09:02:30 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Glauber Costa <glommer@...hat.com>
CC:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Rik van Riel <riel@...hat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Anthony Liguori <aliguori@...ibm.com>,
	Eric B Munson <emunson@...bm.net>
Subject: Re: [PATCH v2 3/7] KVM-HV: KVM Steal time implementation

On 06/20/2011 05:53 AM, Glauber Costa wrote:
>
>>
>>> +static void record_steal_time(struct kvm_vcpu *vcpu)
>>> +{
>>> + u64 delta;
>>> +
>>> + if (vcpu->arch.st.stime&& vcpu->arch.st.this_time_out) {
>>
>> 0 is a valid value for stime.
>
>
> how exactly? stime is a guest physical address...

0 is a valid physical address.

>>>
>>> @@ -2158,6 +2206,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu,
>>> int cpu)
>>> kvm_migrate_timers(vcpu);
>>> vcpu->cpu = cpu;
>>> }
>>> +
>>> + record_steal_time(vcpu);
>>> }
>>
>> This records time spent in userspace in the vcpu thread as steal time.
>> Is this what we want? Or just time preempted away?
>
> There are arguments either way.
>
> Right now, the way it is, it does account our iothread as steal time, 
> which is not 100 % accurate if we think steal time as "whatever takes 
> time away from our VM". I tend to think it as "whatever takes time 
> away from this CPU", which includes other cpus in the same VM. So 
> thinking this way, in a 1-1 phys-to-virt cpu mapping, if the iothread 
> is taking 80 % cpu for whatever reason, we have 80 % steal time the 
> cpu that is sharing the physical cpu with the iothread.

I'm not talking about the iothread, rather the vcpu thread while running 
in userspace.

>
> Maybe we could account that as iotime ?
> Questions like that are one of the reasons behind me leaving extra 
> fields in the steal time structure. We could do a more fine grained 
> accounting and differentiate between the multiple entities that can do
> work (of various kinds) in our behalf.
>

What do other architectures do (xen, s390)?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/