On Tue, Mar 12, 2013 at 10:25:35AM +0100, Jan Kiszka wrote:
> On 2013-03-11 20:30, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 19:51, Gleb Natapov wrote:
> > On Intel:
> > CPU 1 CPU 2 in a guest mode
>
On 2013-03-11 20:30, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 19:51, Gleb Natapov wrote:
> On Intel:
> CPU 1 CPU 2 in a guest mode
> send INIT
> send SIPI
> INIT
On 2013-03-11 20:30, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:51, Gleb Natapov wrote:
On Intel:
CPU 1 CPU 2 in a guest mode
send INIT
send SIPI
INIT vmexit
On Tue, Mar 12, 2013 at 10:25:35AM +0100, Jan Kiszka wrote:
On 2013-03-11 20:30, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:51, Gleb Natapov wrote:
On Intel:
CPU 1 CPU 2 in a guest mode
send INIT
send SIPI
On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
> On 2013-03-11 19:51, Gleb Natapov wrote:
> >>> On Intel:
> >>> CPU 1 CPU 2 in a guest mode
> >>> send INIT
> >>> send SIPI
> >>> INIT vmexit
> >>>
On 2013-03-11 19:51, Gleb Natapov wrote:
>>> On Intel:
>>> CPU 1 CPU 2 in a guest mode
>>> send INIT
>>> send SIPI
>>> INIT vmexit
>>> vmxoff
>>> reset and start from SIPI
On Mon, Mar 11, 2013 at 07:47:03PM +0100, Jan Kiszka wrote:
> On 2013-03-11 19:39, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 19:13, Gleb Natapov wrote:
> >>> On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
> On
On 2013-03-11 19:39, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 19:13, Gleb Natapov wrote:
>>> On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 06:34:03PM
On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
> On 2013-03-11 19:13, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 18:41, Gleb Natapov wrote:
> >>> On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
> On
On 2013-03-11 19:13, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 18:41, Gleb Natapov wrote:
>>> On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 04:36:33PM
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
> On 2013-03-11 18:41, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 18:23, Gleb Natapov wrote:
> >>> On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
> On
On 2013-03-11 18:41, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 18:23, Gleb Natapov wrote:
>>> On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
> Il 11/03/2013 15:05, Gleb Natapov
On Mon, Mar 11, 2013 at 06:39:44PM +0100, Paolo Bonzini wrote:
> Il 11/03/2013 18:20, Gleb Natapov ha scritto:
> > On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
> >> Il 11/03/2013 14:54, Gleb Natapov ha scritto:
> Setting the mp_state to INIT_RECEIVED is that interface, and
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
> On 2013-03-11 18:23, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 15:23, Paolo Bonzini wrote:
> >>> Il 11/03/2013 15:05, Gleb Natapov ha scritto:
> On Mon, Mar 11, 2013 at
Il 11/03/2013 18:20, Gleb Natapov ha scritto:
> On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
>> Il 11/03/2013 14:54, Gleb Natapov ha scritto:
Setting the mp_state to INIT_RECEIVED is that interface, and it already
works, for APs at least. This patch extends it to work
On 2013-03-11 18:34, Jan Kiszka wrote:
> On 2013-03-11 18:23, Gleb Natapov wrote:
>> On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
>>> On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan
On 2013-03-11 18:23, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 15:23, Paolo Bonzini wrote:
>>> Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
>> We are not moving away from
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
> On 2013-03-11 15:23, Paolo Bonzini wrote:
> > Il 11/03/2013 15:05, Gleb Natapov ha scritto:
> >> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
> We are not moving away from mp_state, we are moving away from using
>
On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
> Il 11/03/2013 14:54, Gleb Natapov ha scritto:
> >> 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.
> >
> > It does not
On 2013-03-11 15:23, Paolo Bonzini wrote:
> Il 11/03/2013 15:05, Gleb Natapov ha scritto:
>> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
>> 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.
>
> It does not for AP either. If AP has vmx on mp_sate should not be set to
> INIT_RECEIVED.
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
>>> We are not moving away from mp_state, we are moving away from using
>>> mp_state for signaling because with nested virt INIT does not always
>>> change mp_state, not only that it can
On 2013-03-11 15:12, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 03:10:45PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 15:09, Gleb Natapov wrote:
>>> On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:05, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 03:01:40PM
On Mon, Mar 11, 2013 at 03:10:45PM +0100, Jan Kiszka wrote:
> On 2013-03-11 15:09, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
> >> On 2013-03-11 15:05, Gleb Natapov wrote:
> >>> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
> > We are not
On 2013-03-11 15:09, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
>> On 2013-03-11 15:05, Gleb Natapov wrote:
>>> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
> We are not moving away from mp_state, we are moving away from using
>
On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
> On 2013-03-11 15:05, Gleb Natapov wrote:
> > On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
> >>> We are not moving away from mp_state, we are moving away from using
> >>> mp_state for signaling because with nested virt
On 2013-03-11 15:05, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
>>> We are not moving away from mp_state, we are moving away from using
>>> mp_state for signaling because with nested virt INIT does not always
>>> change mp_state, not only that it can change
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
> > We are not moving away from mp_state, we are moving away from using
> > mp_state for signaling because with nested virt INIT does not always
> > change mp_state, not only that it can change mp_state long after signal
> > is received
On 2013-03-11 14:54, Gleb Natapov wrote:
> On Mon, Mar 11, 2013 at 02:31:46PM +0100, Paolo Bonzini wrote:
>> 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
On Mon, Mar 11, 2013 at 02:31:46PM +0100, Paolo Bonzini wrote:
> 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
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"
On Mon, Mar 11, 2013 at 12:25:57PM +0100, Paolo Bonzini wrote:
> Il 11/03/2013 11:28, Gleb Natapov ha scritto:
> >> Not really true---we do exit with that state and EINTR when we get a
> >> SIPI. Perhaps that can be changed.
> >
> > That's implementation detail. We can jump to the beginning of
Il 11/03/2013 11:28, Gleb Natapov ha scritto:
>> Not really true---we do exit with that state and EINTR when we get a
>> SIPI. Perhaps that can be changed.
>
> That's implementation detail. We can jump to the beginning of the
> function instead. Nowhere we document that entering
>
On Mon, Mar 11, 2013 at 11:14:39AM +0100, Paolo Bonzini wrote:
> Il 10/03/2013 19:10, Gleb Natapov ha scritto:
> > On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
> >> Il 10/03/2013 16:35, Gleb Natapov ha scritto:
> > However, it would effectively redefine the meaning of
> >
Il 10/03/2013 19:10, Gleb Natapov ha scritto:
> On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
>> Il 10/03/2013 16:35, Gleb Natapov ha scritto:
> However, it would effectively redefine the meaning of
> KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
Il 10/03/2013 19:10, Gleb Natapov ha scritto:
On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
to
On Mon, Mar 11, 2013 at 11:14:39AM +0100, Paolo Bonzini wrote:
Il 10/03/2013 19:10, Gleb Natapov ha scritto:
On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
Il 11/03/2013 11:28, Gleb Natapov ha scritto:
Not really true---we do exit with that state and EINTR when we get a
SIPI. Perhaps that can be changed.
That's implementation detail. We can jump to the beginning of the
function instead. Nowhere we document that entering
On Mon, Mar 11, 2013 at 12:25:57PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 11:28, Gleb Natapov ha scritto:
Not really true---we do exit with that state and EINTR when we get a
SIPI. Perhaps that can be changed.
That's implementation detail. We can jump to the beginning of the
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
On Mon, Mar 11, 2013 at 02:31:46PM +0100, Paolo Bonzini wrote:
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
On 2013-03-11 14:54, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 02:31:46PM +0100, Paolo Bonzini wrote:
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
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not always
change mp_state, not only that it can change mp_state long after signal
is received after vmx
On 2013-03-11 15:05, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not always
change mp_state, not only that it can change mp_state
On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:05, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not
On 2013-03-11 15:09, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:05, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling
On Mon, Mar 11, 2013 at 03:10:45PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:09, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:05, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from
On 2013-03-11 15:12, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:10:45PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:09, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:06:18PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:05, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not always
change mp_state, not only that it can change
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
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.
It does not for AP either. If AP has vmx on mp_sate should not be set to
INIT_RECEIVED. mp_sate is
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not always
change
On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
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.
It does not for AP either.
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are
On 2013-03-11 18:34, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We
Il 11/03/2013 18:20, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
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
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM
On Mon, Mar 11, 2013 at 06:39:44PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 18:20, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
Setting the mp_state to INIT_RECEIVED is that interface, and it already
On 2013-03-11 18:41, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo Bonzini wrote:
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan Kiszka wrote:
On 2013-03-11 15:23, Paolo
On 2013-03-11 19:13, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 04:36:33PM +0100, Jan
On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:13, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:23, Gleb
On 2013-03-11 19:39, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:13, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 06:34:03PM +0100, Jan
On Mon, Mar 11, 2013 at 07:47:03PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:39, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:27:44PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:13, Gleb Natapov wrote:
On Mon, Mar 11, 2013 at 07:05:48PM +0100, Jan Kiszka wrote:
On 2013-03-11 18:41, Gleb
On 2013-03-11 19:51, Gleb Natapov wrote:
On Intel:
CPU 1 CPU 2 in a guest mode
send INIT
send SIPI
INIT vmexit
vmxoff
reset and start from SIPI vector
Is SIPI sticky as
On Mon, Mar 11, 2013 at 08:01:30PM +0100, Jan Kiszka wrote:
On 2013-03-11 19:51, Gleb Natapov wrote:
On Intel:
CPU 1 CPU 2 in a guest mode
send INIT
send SIPI
INIT vmexit
vmxoff
On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
> Il 10/03/2013 16:35, Gleb Natapov ha scritto:
> >> > However, it would effectively redefine the meaning of
> >> > KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
> >> > to KVM_MP_STATE_WAIT_FOR_SIPI and
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
>> > However, it would effectively redefine the meaning of
>> > KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
>> > to KVM_MP_STATE_WAIT_FOR_SIPI and KVM_MP_STATE_RESETTING. I wasn't sure
>> > if this is considered an API
On Sun, Mar 10, 2013 at 03:53:54PM +0100, Paolo Bonzini wrote:
> Il 10/03/2013 12:46, Gleb Natapov ha scritto:
> > On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
> >> After receiving an INIT signal (either via the local APIC, or through
> >> KVM_SET_MP_STATE), the bootstrap
Il 10/03/2013 12:46, Gleb Natapov ha scritto:
> On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
>> After receiving an INIT signal (either via the local APIC, or through
>> KVM_SET_MP_STATE), the bootstrap processor should reset immediately
>> and start execution at 0xfff0.
On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
> After receiving an INIT signal (either via the local APIC, or through
> KVM_SET_MP_STATE), the bootstrap processor should reset immediately
> and start execution at 0xfff0. Also, SIPIs have no effect on the
> bootstrap
On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should reset immediately
and start execution at 0xfff0. Also, SIPIs have no effect on the
bootstrap processor.
Il 10/03/2013 12:46, Gleb Natapov ha scritto:
On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should reset immediately
and start execution at 0xfff0. Also, SIPIs
On Sun, Mar 10, 2013 at 03:53:54PM +0100, Paolo Bonzini wrote:
Il 10/03/2013 12:46, Gleb Natapov ha scritto:
On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
to KVM_MP_STATE_WAIT_FOR_SIPI and KVM_MP_STATE_RESETTING. I wasn't sure
if this is considered an API change
On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
to KVM_MP_STATE_WAIT_FOR_SIPI and
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should reset immediately
and start execution at 0xfff0. Also, SIPIs have no effect on the
bootstrap processor. However, KVM currently does not differentiate
between the BSP and
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should reset immediately
and start execution at 0xfff0. Also, SIPIs have no effect on the
bootstrap processor. However, KVM currently does not differentiate
between the BSP and
78 matches
Mail list logo
