linux-kernel - Re: [PATCH] x86: kvm: reset the bootstrap processor when it gets an INIT

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: <513DDCC2.9070807@redhat.com>
Date:	Mon, 11 Mar 2013 14:31:46 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Gleb Natapov <gleb@...hat.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	mtosatti@...hat.com, jan.kiszka@...mens.com
Subject: Re: [PATCH] x86: kvm: reset the bootstrap processor when it gets
 an INIT

Il 11/03/2013 12:51, Gleb Natapov ha scritto:
>> > 
>> > Agreed, but we still have the problem of how to signal from userspace.
>> > For that do you have any other suggestion than mp_state?  And if we keep
>> > mp_state to signal from userspace, giving INIT_RECEIVED the
>> > "wait-for-SIPI" semantics would be wrong.
>> > 
> I don't see how can we use mp_state for signaling from userspace either.
> Currently soft reset always reset vcpus, so it is OK for userspace to
> generate reset vcpu state and put it into kernel, mp_state is just one
> of the updated states, but when INIT will be just another signal that
> may or may not reset cpu or have other side effects like #vmexit this
> will not longer work. We will have to have another interface for
> injecting INIT from userspace and userspace soft-reset will use it
> instead of doing reset by itself.

Setting the mp_state to INIT_RECEIVED is that interface, and it already
works, for APs at least.  This patch extends it to work for the BSP as well.

In the corresponding userspace patch, I don't need to touch the CPU
state at all.  I can just signal the kernel.  If I touch the CPU, I'll
break the nested case, no matter how it is implemented.  So far, the
userspace did not have to worry about nested, and that's something that
should be kept that way.

If we move away from the INIT_RECEIVED and SIPI_RECEIVED states for
in-kernel APIC -> VCPU communication, then the KVM_SET_MP_STATE ioctl
will have to convert them to the right bits in the requests field or in
the APIC state.  But I'm starting to see less benefit from moving away
from mp_state.

Paolo
--
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/