Differential D20522

[PPC64] Support QEMU/KVM pseries without hugepages
ClosedPublic
Actions

Authored by luporl on Jun 5 2019, 4:07 PM.

Details

Reviewers

jhibbits
bdragon

Commits

rS348783: [PPC64] Support QEMU/KVM pseries without hugepages

Summary

This set of changes make it possible to run FreeBSD for PowerPC64/pseries, under QEMU/KVM, without requiring the host to make hugepages available to the guest.

While there was already this possibility, by means of setting hw_direct_map to 0, on PowerPC64 there were a couple of issues/wrong assumptions that prevented this from working, before this changelist.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

luporl created this revision.Jun 5 2019, 4:07 PM

Herald added subscribers: bdragon, jhibbits. · View Herald TranscriptJun 5 2019, 4:07 PM

Harbormaster completed remote builds in B24698: Diff 58267.Jun 5 2019, 4:07 PM

luporl edited the summary of this revision. (Show Details)Jun 5 2019, 4:13 PM

luporl added reviewers: jhibbits, bdragon.

luporl added subscribers: alfredo, gromero_br.ibm.com.

Overall looks good, just one question.

sys/powerpc/aim/mmu_oea64.c
700 ↗	(On Diff #58267)	Does this need the \| DMAP_BASE_ADDRESS as well, like below?

luporl added inline comments.Jun 7 2019, 12:48 PM

sys/powerpc/aim/mmu_oea64.c
700 ↗	(On Diff #58267)	I think it doesn't make much difference in this case, in a practical sense, but indeed it seems better to add the \| DMAP_BASE_ADDRESS, for consistency and for getting this memory range out of the low memory addresses range.

Thanks for the explanation. It looks fine either way. I just recommend making the change for consistency, but it's not required if it's not needed.

This revision is now accepted and ready to land.Jun 7 2019, 2:59 PM

luporl marked an inline comment as done.Jun 7 2019, 5:52 PM

luporl added inline comments.

sys/powerpc/aim/mmu_oea64.c
700 ↗	(On Diff #58267)	Well, in fact I was wrong, and \| DMAP_BASE_ADDRESS can't be added in this case. This change results in the kernel hanging right after printing the mmu_phyp message, when hugepages are off. As moea64_bpvo_pool is used for early pvo allocation (alloc_pvo_entry), remapping the region at this point invalidate previous pvo pointers allocated from the pool.