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
