On 01/07/2016 17:43, Radim Krčmář wrote:
> > Forgot to reply about this: letting SET_LAPIC change x2APIC IDs is nonsense.
> >
> > In x2APIC mode + new capability disabled SET_LAPIC should ignore the id
> > register altogether for backwards compatibility.
>
> I'd still shift SET_LAPIC APIC ID to
2016-07-01 17:12+0200, Paolo Bonzini:
> On 01/07/2016 17:06, Paolo Bonzini wrote:
>> > Should it?
>>> Yes, x2APIC ID cannot be changed in hardware and is initialized to the
>>> intitial APIC ID.
>>> Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace
>>> reuses old VMs ins
2016-07-01 17:06+0200, Paolo Bonzini:
> On 01/07/2016 16:38, Radim Krčmář wrote:
> On the
> other hand, I suspect you need to bump KVM_MAX_VCPU_ID beyond its
> current default setting (which is equal to KVM_MAX_VCPUS), up to 511 or
>
On 01/07/2016 17:06, Paolo Bonzini wrote:
>>> >> > Should it?
>> Yes, x2APIC ID cannot be changed in hardware and is initialized to the
>> intitial APIC ID.
>> Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace
>> reuses old VMs instead of building new ones after reconfigura
On 01/07/2016 16:38, Radim Krčmář wrote:
>> > Should it?
> Yes, x2APIC ID cannot be changed in hardware and is initialized to the
> intitial APIC ID.
> Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace
> reuses old VMs instead of building new ones after reconfiguration.
> I
2016-07-01 16:03+0200, Paolo Bonzini:
> On 01/07/2016 14:44, Radim Krčmář wrote:
>> 2016-07-01 10:42+0200, Paolo Bonzini:
>>> On 01/07/2016 00:15, Andrew Honig wrote:
>> + /* kvm_apic_map_get_logical_dest() expects multiples of 16 */
>> + size = round_up(max_id + 1, 16);
No
On 01/07/2016 14:44, Radim Krčmář wrote:
> 2016-07-01 10:42+0200, Paolo Bonzini:
>> On 01/07/2016 00:15, Andrew Honig wrote:
> + /* kvm_apic_map_get_logical_dest() expects multiples of 16 */
> + size = round_up(max_id + 1, 16);
>>> Now that you're using the full range of apic_
2016-07-01 10:42+0200, Paolo Bonzini:
> On 01/07/2016 00:15, Andrew Honig wrote:
>>> > + /* kvm_apic_map_get_logical_dest() expects multiples of 16 */
>>> > + size = round_up(max_id + 1, 16);
>> Now that you're using the full range of apic_id values, could this
>> calculation overflow?
On 01/07/2016 00:15, Andrew Honig wrote:
>> > + /* kvm_apic_map_get_logical_dest() expects multiples of 16 */
>> > + size = round_up(max_id + 1, 16);
> Now that you're using the full range of apic_id values, could this
> calculation overflow? Perhaps max_id could be u64?
Good point,
On 30/06/2016 22:54, Radim Krčmář wrote:
> x2APIC supports up to 2^32-1 LAPICs, but most guest in coming years will
> have slighly less VCPUs. Dynamic size saves memory at the cost of
> turning one constant into a variable.
>
> apic_map mutex had to be moved before allocation to avoid races wit
> -
> - new = kzalloc(sizeof(struct kvm_apic_map), GFP_KERNEL);
> + u32 size, max_id = 255;
>
> mutex_lock(&kvm->arch.apic_map_lock);
>
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + if (kvm_apic_present(vcpu))
> + max_id = max(max_id, kvm_apic
x2APIC supports up to 2^32-1 LAPICs, but most guest in coming years will
have slighly less VCPUs. Dynamic size saves memory at the cost of
turning one constant into a variable.
apic_map mutex had to be moved before allocation to avoid races with cpu
hotplug.
Signed-off-by: Radim Krčmář
---
v1:
12 matches
Mail list logo
