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
27 matches
Mail list logo
