qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] host physical address width issues/questions for x86_64


From: Prasad Singamsetty
Subject: [Qemu-devel] host physical address width issues/questions for x86_64
Date: Fri, 13 Oct 2017 09:17:32 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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:
   1) Could we change the default value to same as the host physcial
      address for x86_64 machines?  Are there any side effects on this?
   2) Adding a check to fail to boot the guest if phys-bits is not
      sufficient for the specified maxmem or if it is more than
      the host phys bits value. Do you have any objections if I
      add a patch for this?

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?

Please let me know if you have some suggestions in fixing these
two problem cases for supporting large config guests. Also, please
let me know if there are any other known limitations in the current
implementation.

Thanks.
--Prasad



reply via email to

[Prev in Thread] Current Thread [Next in Thread]