On Thu, Apr 12, 2018 at 1:59 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> On 12/04/2018 00:20, Jim Mattson wrote:
>> On Tue, Mar 20, 2018 at 12:17 PM, Sean Christopherson
>> <sean.j.christopherson@xxxxxxxxx> wrote:
>>> Add struct kvm_vmx, which wraps struct kvm, and a helper to_kvm_vmx()
>>> that retrieves 'struct kvm_vmx *' from 'struct kvm *'. Move the VMX
>>> specific variables out of kvm_arch and into kvm_vmx.
>>
>>> static struct kvm *vmx_vm_alloc(void)
>>> {
>>> - return kzalloc(sizeof(struct kvm), GFP_KERNEL);
>>> + struct kvm_vmx *kvm_vmx = kzalloc(sizeof(struct kvm_vmx), GFP_KERNEL);
>>> + return &kvm_vmx->kvm;
>>> }
>>
>> struct kvm_vmx is getting quite large:
>> (gdb) p sizeof(struct kvm_vmx)
>> $1 = 42216
>>
>> We sometimes find that kmalloc cannot satisfy order 4 allocation
>> requests due to fragmentation. Is vmalloc an option?
>
> cpuid info could definitely be moved to a separate vmalloc-ed block, as
> a start.
>
> Paolo
It's a small start, but it won't get us down to order 3...
(gdb) p sizeof(((struct kvm_vcpu_arch *)0)->cpuid_entries)
$1 = 3200
What is the objection to a single vmalloc for the entire structure? Is
there anything in there that needs physically contiguous pages?
