From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v3 1/1] Add pci_hole_min_size Date: Tue, 01 Jul 2014 09:54:31 -0400 Message-ID: <53B2BD97.3090501@terremark.com> References: <1403804869-3461-1-git-send-email-dslutz@verizon.com> <1403804869-3461-2-git-send-email-dslutz@verizon.com> <53AD48B8020000780001DDC2@mail.emea.novell.com> <53B2A205.3080807@terremark.com> <53B2CA36020000780001F015@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53B2CA36020000780001F015@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Don Slutz Cc: Boris Ostrovsky , xen-devel@lists.xen.org, Ian Jackson , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 07/01/14 08:48, Jan Beulich wrote: >>>> On 01.07.14 at 13:56, wrote: >> On 06/27/14 04:34, Jan Beulich wrote: >>> Furthermore the whole concept collides with the auto-growing of >>> the hole immediately following this code. Both logically (both having >>> a similar purpose) and, what's worse, functionally in that the >>> shifting done there requires that ((1ULL << 32) - pci_mem_start) >>> be a power of 2. An option might be to skip this auto-sizing if the >>> option was given. >> I am fine with disabling the auto-growing (since as far as I know >> this is bug #28 ( >> >> >> #28 - support PCI hole resize in qemu-xen >> >> ) > But that's only with upstream qemu I suppose; the auto-resizing > was added for a reason (see the history of the file). So this is > definitely not going to be an unconditional disabling (other than > what I kind of read from your reply). I was not clear. I am thinking that if pci_hole_min_size (or what ever the name is) is non-zero (i.e. not default (could be exists also)), I would disable the auto-resizing code. As far as I know, the auto-resizing only works with qemu-xen-traditional. I was not planning to add max-ram-below-4g to qemu-xen-traditional (but it would not be a big patch nor as complex as what is in qemu-xen (upstream master)). so currently it would be: + } + else + { /* * At the moment qemu-xen can't deal with relocated memory regions. * It's too close to the release to make a proper fix; for now, * only allow the MMIO hole to grow large enough to move guest memory * if we're running qemu-traditional. Items that don't fit will be * relocated into the 64-bit address space. * * This loop now does the following: * - If allow_memory_relocate, increase the MMIO hole until it's * big enough, or until it's 2GiB * - If !allow_memory_relocate, increase the MMIO hole until it's * big enough, or until it's 2GiB, or until it overlaps guest * memory */ while ( (mmio_total > (pci_mem_end - pci_mem_start)) && ((pci_mem_start << 1) != 0) && (allow_memory_relocate || (((pci_mem_start << 1) >> PAGE_SHIFT) >= hvm_info->low_mem_pgend)) ) pci_mem_start <<= 1; + } But looking closer I could just set: HVM_XS_ALLOW_MEMORY_RELOCATE to 0 to stop part of this. And the other part should be false do to xc_hvm_build_with_hole() but this will need testing. -Don Slutz > Jan >