Re: [PATCH v3 4/8] ARM: KVM: Memory virtualization setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jun 5, 2011 at 5:14 PM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 06/05/2011 05:53 PM, Avi Kivity wrote:
>>
>> On 06/05/2011 05:50 PM, Christoffer Dall wrote:
>>>
>>> On Sun, Jun 5, 2011 at 2:41 PM, Avi Kivity<avi@xxxxxxxxxx>  wrote:
>>> >  On 06/03/2011 06:03 PM, Christoffer Dall wrote:
>>> >>
>>> >>  Initializes a blank level-1 translation table for the second stage
>>> >>  translation and handles freeing it as well.
>>> >>
>>> >>  +       start = (unsigned long)kvm,
>>> >>  +       end = start + sizeof(struct kvm);
>>> >>  +       ret = create_hyp_mappings(kvm_hyp_pgd, start, end);
>>> >
>>> >  Why not map all GFP_KERNEL memory?
>>> >
>>> I wanted to only map things I was sure would be there and stay there
>>> so no assumptions were made about existing pages which could have been
>>> removed, since I don't handle aborts taken in the hypervisor itself.
>>> But, if it would be as safe to map all GFP_KERNEL memory and that also
>>> maps the necessary code segments, then we could do that. Do you feel
>>> it would me simpler/faster/easier?
>>
>> I think so - you wouldn't have to worry about dereferencing pointers
>> within the vcpu structure.
>
> Also, you could use huge pages for the mapping, yes?  that should improve
> switching performance a bit.

well, the only advantage here would be to save a few entries in the
TLB right? So really it would only be the case if the data and the
code and such accessed during switches lie within the same sections,
which could happen, but could also not happen. I don't see a big
performance gain here, but slightly more complicated code. For
instance, if the VCPU struct is mapped using a page, not a section
mapping, I cannot use section mappings since I would map weird things.
So I would have to support both for allocating and freeing.

I suggest keeping this in place for now and experiment with
performance later on to see if there's a gain. Allocating all of
GFP_KERNEL memory could be good to prevent bugs, but I would like to
clear this with the ARM memory experts that it is in fact a good idea.

>
> Can you run the host kernel in hypervisor mode?  That may reduce switching
> time even further.

No, I think the implications would be way too widespread all over the kernel.

>
> --
> error compiling committee.c: too many arguments to function
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux