On 10/13/2017 10:14 AM, Alex Williamson wrote:
On Fri, 13 Oct 2017 18:01:44 +0100
"Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote:
* Prasad Singamsetty (prasad.singamse...@oracle.com) wrote:
Hi,
I am new to the alias. I have some questions on this subject
and seek some clarifications from the experts in the team.
I ran into a couple of issues when I tried with large configuration
( >= 1TB memory, > 255 CPUs) for x86_64 guest machine.
1. QEMU uses the default value of 40 (TCG_PHYS_ADDR_BITS) for address
width if user has not specified phys-bits or host-phys-bits=true
property. The default value is obviously not sufficient and
causing guest kernel to crash if configured with >= 1TB
memory. Depending on the linux kernel version in the guest the
panic was in different code paths. The workaround is for the
user to specify the phys-bits property or set the property
host-phys-bits=true.
QUESTIONS:
...
2. host_address_width in DMAR table structure
In this case, the default value is set to 39
(VTD_HOST_ADDRESS_WIDTH - 1). With interrupt remapping
enabled for the intel iommu and the guest is configured
with > 255 cpus and >= 1TB memory, the guest kernel hangs
during boot up. This need to be fixed.
QUESTION:
The question here again is can we fix this to use the
real address width from the host as the default?
I don't know DMAR stuff; chatting to Alex (cc'd) it does sound
like that's an ommission that should be fixed.
[CC +Peter]
On physical hardware VT-d supports either 39 or 48 bit address widths
and generally you'd expect a sufficiently capable IOMMU to be matched
with the CPU. Seems QEMU has only implemented a lower bit width and
it should probably be forcing phys bits of the VM to 39 to match until
the extended width can be implemented. Thanks,
Thanks Alex. Are there specific incompatibilities with emulated
IOMMU features presented by QEMU and CPU that can cause problems?
Thanks.
--Prasad
Alex
