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] [day] [month] [year] [list]
Date:   Wed, 9 Feb 2022 15:59:51 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     kvm@...r.kernel.org, pbonzini@...hat.com, kevin.tian@...el.com,
        tglx@...utronix.de, John Garry <john.garry@...wei.com>,
        Will Deacon <will@...nel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Shaokun Zhang <zhangshaokun@...ilicon.com>,
        Thomas Richter <tmricht@...ux.ibm.com>,
        Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/4] KVM: Rename and move CPUHP_AP_KVM_STARTING to
 ONLINE section

On Wed, Feb 09, 2022 at 12:29:57AM +0000, Sean Christopherson wrote:
>On Tue, Jan 18, 2022, Chao Gao wrote:
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 148f7169b431..528741601122 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -4856,13 +4856,25 @@ static void hardware_enable_nolock(void *junk)
>>  	}
>>  }
>>  
>> -static int kvm_starting_cpu(unsigned int cpu)
>> +static int kvm_online_cpu(unsigned int cpu)
>>  {
>> +	int ret = 0;
>> +
>>  	raw_spin_lock(&kvm_count_lock);
>> -	if (kvm_usage_count)
>> +	/*
>> +	 * Abort the CPU online process if hardware virtualization cannot
>> +	 * be enabled. Otherwise running VMs would encounter unrecoverable
>> +	 * errors when scheduled to this CPU.
>> +	 */
>> +	if (kvm_usage_count) {
>
>
>>  		hardware_enable_nolock(NULL);
>> +		if (atomic_read(&hardware_enable_failed)) {
>
>This needs:
>
>		atomic_set(&hardware_enable_failed, 0);
>
>otherwise failure to online one CPU will prevent onlining other non-broken CPUs.
>It's probably worth adding a WARN_ON_ONCE above this too, e.g.

Thanks. All your comments to this series make sense. I just post a revised
version.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ