On 2016/7/11 23:52, Radim Krčmář wrote:
2016-07-11 16:14+0200, Paolo Bonzini:
On 11/07/2016 15:48, Radim Krčmář wrote:
I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
(I guess the fewest LOC is to
On 2016/7/11 23:52, Radim Krčmář wrote:
2016-07-11 16:14+0200, Paolo Bonzini:
On 11/07/2016 15:48, Radim Krčmář wrote:
I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
(I guess the fewest LOC is to
On 11/07/2016 17:52, Radim Krčmář wrote:
> 2016-07-11 16:14+0200, Paolo Bonzini:
>> On 11/07/2016 15:48, Radim Krčmář wrote:
> I guess the easiest solution is to replace kvm_apic_id with a field in
> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>>
>>> (I guess
On 11/07/2016 17:52, Radim Krčmář wrote:
> 2016-07-11 16:14+0200, Paolo Bonzini:
>> On 11/07/2016 15:48, Radim Krčmář wrote:
> I guess the easiest solution is to replace kvm_apic_id with a field in
> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>>
>>> (I guess
2016-07-11 16:14+0200, Paolo Bonzini:
> On 11/07/2016 15:48, Radim Krčmář wrote:
I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>
>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which
2016-07-11 16:14+0200, Paolo Bonzini:
> On 11/07/2016 15:48, Radim Krčmář wrote:
I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>
>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which
On 11/07/2016 15:48, Radim Krčmář wrote:
>>> I guess the easiest solution is to replace kvm_apic_id with a field in
>>> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>
> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
> x2apic id. xapic id cannot
On 11/07/2016 15:48, Radim Krčmář wrote:
>>> I guess the easiest solution is to replace kvm_apic_id with a field in
>>> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>
> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
> x2apic id. xapic id cannot
2016-07-11 18:14+0800, Yang Zhang:
> On 2016/7/11 15:43, Paolo Bonzini wrote:
>> On 11/07/2016 08:07, Yang Zhang wrote:
>> > >
>> > > mutex_lock(>arch.apic_map_lock);
>> > >
>> > > +kvm_for_each_vcpu(i, vcpu, kvm)
>> > > +if (kvm_apic_present(vcpu))
>> > > +max_id =
2016-07-11 18:14+0800, Yang Zhang:
> On 2016/7/11 15:43, Paolo Bonzini wrote:
>> On 11/07/2016 08:07, Yang Zhang wrote:
>> > >
>> > > mutex_lock(>arch.apic_map_lock);
>> > >
>> > > +kvm_for_each_vcpu(i, vcpu, kvm)
>> > > +if (kvm_apic_present(vcpu))
>> > > +max_id =
On 2016/7/11 15:43, Paolo Bonzini wrote:
On 11/07/2016 08:07, Yang Zhang wrote:
mutex_lock(>arch.apic_map_lock);
+kvm_for_each_vcpu(i, vcpu, kvm)
+if (kvm_apic_present(vcpu))
+max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
+
+new = kzalloc(sizeof(struct
On 2016/7/11 15:43, Paolo Bonzini wrote:
On 11/07/2016 08:07, Yang Zhang wrote:
mutex_lock(>arch.apic_map_lock);
+kvm_for_each_vcpu(i, vcpu, kvm)
+if (kvm_apic_present(vcpu))
+max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
+
+new = kzalloc(sizeof(struct
On 11/07/2016 08:07, Yang Zhang wrote:
>>
>> mutex_lock(>arch.apic_map_lock);
>>
>> +kvm_for_each_vcpu(i, vcpu, kvm)
>> +if (kvm_apic_present(vcpu))
>> +max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
>> +
>> +new = kzalloc(sizeof(struct kvm_apic_map) +
>> +
On 11/07/2016 08:07, Yang Zhang wrote:
>>
>> mutex_lock(>arch.apic_map_lock);
>>
>> +kvm_for_each_vcpu(i, vcpu, kvm)
>> +if (kvm_apic_present(vcpu))
>> +max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
>> +
>> +new = kzalloc(sizeof(struct kvm_apic_map) +
>> +
On 2016/7/8 1:15, 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 with cpu
On 2016/7/8 1:15, 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 with cpu
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ář
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ář
---
18 matches
Mail list logo
