Single memory slot

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space
- modify qemu memory allocation to use MAP_FIXED to allocate memory
- some hack for the vga aliases (mmap an fd multiple times?)
- some hack for the vmx-specific pages (e.g. APIC-access page)

Not sure it's worthwhile, but something to keep in mind if a simple cache or sort by size is insufficient due to mmio.

Quoted 14 lines · Avi Kivity

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space
- modify qemu memory allocation to use MAP_FIXED to allocate memory
- some hack for the vga aliases (mmap an fd multiple times?)
- some hack for the vmx-specific pages (e.g. APIC-access page)

Quoted 2 lines

Not sure it's worthwhile, but something to keep in mind if a simple cache or sort by size is insufficient due to mmio.

One thing I've been wondering for quite a while is that slot loop. Why do we loop over all possible slots? Couldn't we just remember the max extry (usually 1 or 2) and not loop MAX_SLOT_AMOUNT times?

That would be a really easy patch and give instant speed improvements for everyone.

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space

Quoted 6 lines · Avi Kivity

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space

It could potentially speed up qemu quite a lot too as we would return to a model where host va == fixed address + guest pa. That makes things like stl_phys/ldl_phys trivial.

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space
- modify qemu memory allocation to use MAP_FIXED to allocate memory
- some hack for the vga aliases (mmap an fd multiple times?)
- some hack for the vmx-specific pages (e.g. APIC-access page)

Not sure it's worthwhile, but something to keep in mind if a simple cache or sort by size is insufficient due to mmio.

Quoted 14 lines · Avi Kivity

One way to improve the gfn_to_pfn() memslot search is to register just one slot. This can only work on 64-bit, since even the smallest guests need 4GB of physical address space. Apart from speeding up gfn_to_page(), it would also speed up mmio which must iterate over all slots, so a lookup cache cannot help.

This would require quite a bunch of changes:
- modify gfn_to_pfn() to fail gracefully if the page is in the slot but unmapped (hole handling)
- modify qemu to reserve the guest physical address space
- modify qemu memory allocation to use MAP_FIXED to allocate memory
- some hack for the vga aliases (mmap an fd multiple times?)
- some hack for the vmx-specific pages (e.g. APIC-access page)

Quoted 3 lines

Not sure it's worthwhile, but something to keep in mind if a simple cache or sort by size is insufficient due to mmio.

Downside is you lose the ability to write protect a small slot only (could mprotect(MAP_READ) the desired area but get_log+write_protect must be atomic).

Also if you enable dirty log for the large slot largepages are disabled.