On 7/18/22 14:10, Nikunj A. Dadhania wrote: > On 7/18/2022 6:12 PM, Igor Mammedov wrote: >> On Mon, 18 Jul 2022 13:47:34 +0530 >> Nikunj A Dadhania <nik...@amd.com> wrote: >> >>> Currently it is possible to start a guest with memory that is beyond >>> the addressable range of CPU and QEMU does not even warn about it. >>> The default phys_bits is 40 and can address 1TB. However it allows to >>> start a guest with greater than 1TB memory. >>> >>> Prevent this by erroring out in such a scenario. >>> >>> Reported-by: Shaju Abraham <abraham.sh...@amd.com> >>> Signed-off-by: Nikunj A Dadhania <nik...@amd.com> >> >> >> Following shall care of your issue: >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg900136.html > > Thanks, I tried out the patch series, I could start guest till 978G (not sure > why this magic number yet) and after that I start getting errors:
It's expected. The point of the series is meant to avoid attempting at DMA mapping over the HyperTransport region. Before it would just fail to either hotplug/boot with VFIO devices on kernels >= 5.4 (even if older kernels or other configs let you go through you might still see IOMMU errors at some point). So what we essentially do is to have the region above 4G to instead start at 1T, thus requiring 1 more phys-bit on cases like this where the max gpa hits the Hyper Transport reserved region. The cover-letter and this patch (https://lore.kernel.org/qemu-devel/20220715171628.21437-11-joao.m.mart...@oracle.com/) should clarify on the logic. The check you're adding here is essentially patch 9 of the series. > > $ ./build/qemu-system-x86_64 -enable-kvm -machine q35 -m 979G -kernel > bzImage -initrd initramfs.cpio -vga none -nographic -append > "console=ttyS0,115200n8 earlyprintk=serial,ttyS0,115200 debug=1 " -nodefaults > -serial stdio > qemu-system-x86_64: Address space limit 0xffffffffff < 0x1fc3fffffff > phys-bits too low (40) > > Regards > Nikunj
