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 vm
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
> >>> v
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
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
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 2013-03-11
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 2013-03-11
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 h
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
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
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 f
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 Kiszk
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 m
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 for
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
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_s
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 chan
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 m
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
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
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
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 af
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
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 sig
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" semanti
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 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
> KVM_MP_STATE_SIP
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
>
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 KVM_MP_
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 chang
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 processo
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,
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.
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 APs
39 matches
Mail list logo