On Thu, Jun 15, 2017 at 07:05:29PM +0300, Roman Kagan wrote:
> On Thu, Jun 15, 2017 at 03:27:28PM +0200, Igor Mammedov wrote:
[...]
> > > > > future. But the APIC id is also the KVM vcpu_id, so there's no need
> > > > > to
> > > > > have VP_INDEX maintained by QEMU.
> > > > agreed it'd be bette
On Thu, Jun 15, 2017 at 03:27:28PM +0200, Igor Mammedov wrote:
> On Thu, 15 Jun 2017 15:41:08 +0300
> Roman Kagan wrote:
> > On Wed, Jun 14, 2017 at 03:00:27PM +0200, Igor Mammedov wrote:
> > > On Wed, 14 Jun 2017 13:26:44 +0200
> > > Paolo Bonzini wrote:
> > >
> > > > On 14/06/2017 13:25, Rom
On Thu, 15 Jun 2017 15:41:08 +0300
Roman Kagan wrote:
> On Wed, Jun 14, 2017 at 03:00:27PM +0200, Igor Mammedov wrote:
> > On Wed, 14 Jun 2017 13:26:44 +0200
> > Paolo Bonzini wrote:
> >
> > > On 14/06/2017 13:25, Roman Kagan wrote:
> > > >> The problem with that is that it will break as so
On 15/06/2017 14:41, Roman Kagan wrote:
> On Wed, Jun 14, 2017 at 03:00:27PM +0200, Igor Mammedov wrote:
>> On Wed, 14 Jun 2017 13:26:44 +0200
>> Paolo Bonzini wrote:
>>
>>> On 14/06/2017 13:25, Roman Kagan wrote:
> The problem with that is that it will break as soon as we create
> VCPUs
On Wed, Jun 14, 2017 at 03:00:27PM +0200, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 13:26:44 +0200
> Paolo Bonzini wrote:
>
> > On 14/06/2017 13:25, Roman Kagan wrote:
> > >> The problem with that is that it will break as soon as we create
> > >> VCPUs in a different order. Unsolvable on hosts
On Thu, Jun 15, 2017 at 01:42:56PM +0200, Paolo Bonzini wrote:
>
>
> On 15/06/2017 13:40, Roman Kagan wrote:
> > On Thu, Jun 15, 2017 at 10:26:58AM +0200, Paolo Bonzini wrote:
> >> On 14/06/2017 20:59, Eduardo Habkost wrote:
> >>> On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
> >>>
On 15/06/2017 13:40, Roman Kagan wrote:
> On Thu, Jun 15, 2017 at 10:26:58AM +0200, Paolo Bonzini wrote:
>> On 14/06/2017 20:59, Eduardo Habkost wrote:
>>> On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
One more data point is that until now there was no use for vp_index in
On Thu, Jun 15, 2017 at 10:26:58AM +0200, Paolo Bonzini wrote:
> On 14/06/2017 20:59, Eduardo Habkost wrote:
> > On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
> >> One more data point is that until now there was no use for vp_index in
> >> QEMU, so it didn't care how KVM managed it.
On 14/06/2017 20:59, Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
>> One more data point is that until now there was no use for vp_index in
>> QEMU, so it didn't care how KVM managed it. In KVM the only
>> vp_index-aware path that the guests could trigger
On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
> On Wed, Jun 14, 2017 at 10:45:23AM -0300, Eduardo Habkost wrote:
> > On Wed, Jun 14, 2017 at 03:38:59PM +0200, Igor Mammedov wrote:
> > > On Wed, 14 Jun 2017 10:22:16 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > On Wed, Jun 14, 20
On Wed, Jun 14, 2017 at 10:45:23AM -0300, Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 03:38:59PM +0200, Igor Mammedov wrote:
> > On Wed, 14 Jun 2017 10:22:16 -0300
> > Eduardo Habkost wrote:
> >
> > > On Wed, Jun 14, 2017 at 03:17:54PM +0200, Paolo Bonzini wrote:
> > > >
> > > >
> > > > On
On Wed, 14 Jun 2017 10:35:36 -0300
Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 03:24:50PM +0200, Igor Mammedov wrote:
> > On Wed, 14 Jun 2017 10:00:15 -0300
> > Eduardo Habkost wrote:
> >
> > > On Wed, Jun 14, 2017 at 02:25:07PM +0300, Roman Kagan wrote:
> > > > On Tue, Jun 13, 2017 at
On Wed, Jun 14, 2017 at 03:38:59PM +0200, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 10:22:16 -0300
> Eduardo Habkost wrote:
>
> > On Wed, Jun 14, 2017 at 03:17:54PM +0200, Paolo Bonzini wrote:
> > >
> > >
> > > On 14/06/2017 15:11, Igor Mammedov wrote:
> > > >> No, KVM really uses the VCPU _
On Wed, 14 Jun 2017 10:22:16 -0300
Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 03:17:54PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 14/06/2017 15:11, Igor Mammedov wrote:
> > >> No, KVM really uses the VCPU _index_ for HV_X64_MSR_VP_INDEX:
> > >
> > > and as you pointed out that works
On 14/06/2017 15:22, Eduardo Habkost wrote:
>> Yes, definitely. At this point let's add a new "KVM_CAP_HYPERV_SYNIC2"
>> capability and declare the old one broken, that will make things easier.
> What do we need a capability for? Can't we just call
> KVM_SET_MSRS using arch_id (== apic_id) and
On Wed, Jun 14, 2017 at 03:24:50PM +0200, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 10:00:15 -0300
> Eduardo Habkost wrote:
>
> > On Wed, Jun 14, 2017 at 02:25:07PM +0300, Roman Kagan wrote:
> > > On Tue, Jun 13, 2017 at 03:57:52PM -0300, Eduardo Habkost wrote:
> > > > On Tue, Jun 06, 2017 at
On Wed, 14 Jun 2017 10:00:15 -0300
Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 02:25:07PM +0300, Roman Kagan wrote:
> > On Tue, Jun 13, 2017 at 03:57:52PM -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 06, 2017 at 09:19:30PM +0300, Roman Kagan wrote:
> > > > Hyper-V identifies vcpus by
On Wed, Jun 14, 2017 at 03:17:54PM +0200, Paolo Bonzini wrote:
>
>
> On 14/06/2017 15:11, Igor Mammedov wrote:
> >> No, KVM really uses the VCPU _index_ for HV_X64_MSR_VP_INDEX:
> >
> > and as you pointed out that works just by luck,
> > as soon as we there would be out of order created CPUs
> >
On Wed, Jun 14, 2017 at 03:11:17PM +0200, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 10:01:49 -0300
> Eduardo Habkost wrote:
>
> > On Wed, Jun 14, 2017 at 01:26:44PM +0200, Paolo Bonzini wrote:
> > >
> > >
> > > On 14/06/2017 13:25, Roman Kagan wrote:
> > > >> The problem with that is that it
On 14/06/2017 15:11, Igor Mammedov wrote:
>> No, KVM really uses the VCPU _index_ for HV_X64_MSR_VP_INDEX:
>
> and as you pointed out that works just by luck,
> as soon as we there would be out of order created CPUs
> returned value won't match cpu_index.
>
> So instead of spreading this nonsens
On Wed, 14 Jun 2017 10:01:49 -0300
Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 01:26:44PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 14/06/2017 13:25, Roman Kagan wrote:
> > >> The problem with that is that it will break as soon as we create
> > >> VCPUs in a different order. Unsolvable
On Wed, Jun 14, 2017 at 01:26:44PM +0200, Paolo Bonzini wrote:
>
>
> On 14/06/2017 13:25, Roman Kagan wrote:
> >> The problem with that is that it will break as soon as we create
> >> VCPUs in a different order. Unsolvable on hosts that don't allow
> >> HV_X64_MSR_VP_INDEX to be set, however.
>
On Wed, Jun 14, 2017 at 02:25:07PM +0300, Roman Kagan wrote:
> On Tue, Jun 13, 2017 at 03:57:52PM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 06, 2017 at 09:19:30PM +0300, Roman Kagan wrote:
> > > Hyper-V identifies vcpus by the virtual processor (VP) index which is
> > > normally queried by the
On Wed, 14 Jun 2017 13:26:44 +0200
Paolo Bonzini wrote:
> On 14/06/2017 13:25, Roman Kagan wrote:
> >> The problem with that is that it will break as soon as we create
> >> VCPUs in a different order. Unsolvable on hosts that don't allow
> >> HV_X64_MSR_VP_INDEX to be set, however.
> > Right,
On 14/06/2017 13:25, Roman Kagan wrote:
>> The problem with that is that it will break as soon as we create
>> VCPUs in a different order. Unsolvable on hosts that don't allow
>> HV_X64_MSR_VP_INDEX to be set, however.
> Right, thanks for putting together a detailed explanation.
>
> This was a
On Tue, Jun 13, 2017 at 03:57:52PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 06, 2017 at 09:19:30PM +0300, Roman Kagan wrote:
> > Hyper-V identifies vcpus by the virtual processor (VP) index which is
> > normally queried by the guest via HV_X64_MSR_VP_INDEX msr.
> >
> > It has to be owned by QEM
On Tue, Jun 06, 2017 at 09:19:30PM +0300, Roman Kagan wrote:
> Hyper-V identifies vcpus by the virtual processor (VP) index which is
> normally queried by the guest via HV_X64_MSR_VP_INDEX msr.
>
> It has to be owned by QEMU in order to preserve it across migration.
>
> However, the current imple
Hyper-V identifies vcpus by the virtual processor (VP) index which is
normally queried by the guest via HV_X64_MSR_VP_INDEX msr.
It has to be owned by QEMU in order to preserve it across migration.
However, the current implementation in KVM doesn't allow to set this
msr, and KVM uses its own noti
28 matches
Mail list logo
