[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/vpmu: fix race-condition in vpmu_load
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Date: Tue, 20 Sep 2022 14:12:02 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AJVWN+mBKnd/AQd+ChLS2BbZczDfBTifMW2OcL4paNw=; b=mP2+LEp/dejAuUgJlks/bdCI6bz2WcZxa0CsBXb8w+UBZf9O7NtSGk9/PunRuuulKdqXgKYRgObx/osfQFOcMz4pRs/8PRaKBHbUEJTg5Dd1y3tk+41ncGJz2GhfqsIxDeQcoH6wAi6ExKyaG2FQLN8Yi8GyuFmufZLdjBNf91dHqoRWcPOzhtfEvSTm1OL9xziLShBXae0GYLga9Q6FTZ3/fcFKlyH5pFeXxkn7gtphybhb8WOXz4DWRGJ4QSseTEtpOp+lQU8AjPXbHANEO0ohaGihNvnYD5bFKrRZYJ+4rj/j2wjkYKzzxQxABjJeNPVFQ75jU/i4/VTBlsY92Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EGL4wGVGssrMvaNfKGodvF1cHLoN+DbMAogwIU+FIMAWit2TH7WuqLGVwppWhim3MfnZgiaAac1Zgq3iv0m1dOkUNqbSRmiLFos68Fp1hQ0gdWLlzYsO9hJ+Gw7UMJJnBZsxzRMqtqCxd6oC0V2epLuv1PQqa8LFQOZ6WCA1Ymx3+aapUv8ctQTUX1K/f6DtPFjH5nyitvFDVMmththyApXzxE7EE4OMURLJWdVNRDTwa2SWpDfOXs6EuQ54J0J9p8f7W8ZGV/ttPnuGguUZpVmPk1mFA2b9BFmI0mS52gr3dAO1Tas5wWe7rTJOps4HBUJb8pnwPMUtb3Pp7pGlLw==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>
- Delivery-date: Tue, 20 Sep 2022 18:12:24 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 9/20/22 10:54 AM, Jan Beulich wrote:
On 20.09.2022 16:26, Boris Ostrovsky wrote:
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @current:
vpmu_load()
...
prev = per_cpu(last_vcpu, pcpu);
vpmu_save_force(prev)
core2_vpmu_save()
__core2_vpmu_save()
vmx_read_guest_msr()
vmx_find_msr()
The call to vmx_find_msr() was introduced by 755087eb9b10c. I wonder though
whether
this call is needed when code path above is executed (i.e. when we are saving
remove vcpu)
How could it not be needed? We need to obtain the guest value. The
thing I don't understand is why this forced saving is necessary,
when context_switch() unconditionally calls vpmu_switch_from().
IIRC the logic is:
1. vcpuA runs on pcpu0
2. vcpuA is de-scheduled and is selected to run on pcpu1. It has not yet called
vpmu_load() from pcpu1
The calling of vpmu_load() shouldn't matter here. What does matter is
that vpmu_save() was necessarily called already.
I thought we don't always save MSRs on context switch because we optimize for
case when the same vcpu gets scheduled again. But I am not sure I see this now
that I am looking at the code.
-boris
Therefore I'm having
trouble seeing why ...
3. vcpuB is ready to run on pcpu0, calls vpmu_load()
4. vcpuB discovers that pcpu0's MSRs are still holding values from vcpuA
5. vcpuB calls vpmu_force_save(vcpuA) which stashes pcpu0's MSRs into vcpuA's
vpmu context.
... forced saving would be necessary here. What's necessary at this
point is only the loading of vcpuB's MSR values.
|
