On 7/18/2022 7:15 PM, Joao Martins wrote:
> 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.
Thanks looks good !
> The check you're adding here is essentially patch 9 of the series.
Yes, saw that change.
Regards
Nikunj
