All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, konrad.wilk@oracle.com,
	akataria@vmware.com, fujita.tomonori@lab.ntt.co.jp,
	revers@redhat.com, riel@redhat.com, pbonzini@redhat.com
Subject: Re: [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN
Date: Fri, 4 Dec 2015 12:49:49 +0100	[thread overview]
Message-ID: <20151204114949.GA15308@gmail.com> (raw)
In-Reply-To: <1449228349-243508-3-git-send-email-imammedo@redhat.com>


* Igor Mammedov <imammedo@redhat.com> wrote:

> when memory hotplug enabled system is booted with less
> than 4GB of RAM and then later more RAM is hotplugged
> 32-bit devices stop functioning with following error:
> 
>  nommu_map_single: overflow 327b4f8c0+1522 of device mask ffffffff
> 
> the reason for this is that if x86_64 system were booted
> with RAM less than 4GB, it doesn't enable SWIOTLB and
> when memory is hotplugged beyond MAX_DMA32_PFN, devices
> that expect 32-bit addresses can't handle 64-bit addresses.
> 
> Fix it by tracking max possible PFN when parsing
> memory affinity structures from SRAT ACPI table and
> enable SWIOTLB if there is hotpluggable memory
> regions beyond MAX_DMA32_PFN.
> 
> It fixes KVM guests when they use emulated devices
> (reproduces with ata_piix, e1000 and usb devices,
>  RHBZ: 1275941, 1275977, 1271527)
> It also fixes the HyperV, VMWare with emulated devices
> which are affected by this issue as well.
> 
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
>  arch/x86/kernel/pci-swiotlb.c | 2 +-
>  arch/x86/mm/srat.c            | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
> index adf0392..7c577a1 100644
> --- a/arch/x86/kernel/pci-swiotlb.c
> +++ b/arch/x86/kernel/pci-swiotlb.c
> @@ -88,7 +88,7 @@ int __init pci_swiotlb_detect_4gb(void)
>  {
>  	/* don't initialize swiotlb if iommu=off (no_iommu=1) */
>  #ifdef CONFIG_X86_64
> -	if (!no_iommu && max_pfn > MAX_DMA32_PFN)
> +	if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
>  		swiotlb = 1;

Ok, this series looks a lot better!

>  #endif
>  	return swiotlb;
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index c2aea63..a26bdbe 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -203,6 +203,9 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>  		pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
>  			(unsigned long long)start, (unsigned long long)end - 1);
>  
> +	if (max_possible_pfn < PFN_UP(end - 1))
> +		max_possible_pfn = PFN_UP(end - 1);

Small nit, why not write this as something like:

	max_possible_pfn = max(max_possible_pfn, PFN_UP(end - 1));

?

I'd also move this second hunk to the first patch, because logically it belongs 
there (or into a third patch).

Thanks,

	Ingo

  reply	other threads:[~2015-12-04 11:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 11:25 [PATCH v2 0/2] x86: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN Igor Mammedov
2015-12-04 11:25 ` [PATCH v2 1/2] x86: introduce max_possible_pfn Igor Mammedov
2015-12-04 11:25 ` [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN Igor Mammedov
2015-12-04 11:49   ` Ingo Molnar [this message]
2015-12-04 12:16     ` Igor Mammedov
2015-12-04 12:33     ` Igor Mammedov
2015-12-04 12:37       ` Paolo Bonzini
2015-12-04 14:34         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151204114949.GA15308@gmail.com \
    --to=mingo@kernel.org \
    --cc=akataria@vmware.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hpa@zytor.com \
    --cc=imammedo@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=revers@redhat.com \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.