Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path
Joonsoo Kim iamjoonsoo@lge.com writes:
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
if (ret == 0) {
page = pfn_to_page(pfn);
break;
- } else if (ret != -EBUSY) {
- clear_cma_bitmap(cma, pfn, count);
- break;
}
+
clear_cma_bitmap(cma, pfn, count);
+ if (ret != -EBUSY)
+ break;
+
pr_debug(%s(): memory range at %p is busy, retrying\n,
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list
Joonsoo Kim iamjoonsoo@lge.com writes:
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 28ec226..97613ea 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -184,7 +184,7 @@ void __init kvm_cma_reserve(void)
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
cma_declare_contiguous(selected_size, 0, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index f177f73..bfd4553 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -149,7 +149,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(size, base, limit, 0, 0, res_cma, fixed);
+ ret = cma_declare_contiguous(size, base, limit, 0, 0, fixed, res_cma);
if (ret)
return ret;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index e38efe9..e53eead 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -6,7 +6,7 @@ struct cma;
extern int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed);
+ bool fixed, struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, int count, unsigned int
align);
extern bool cma_release(struct cma *cma, struct page *pages, int count);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 01a0713..22a5b23 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -142,8 +142,8 @@ core_initcall(cma_init_reserved_areas);
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
* @order_per_bit: Order of pages represented by one bit on bitmap.
- * @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
+ * @res_cma: Pointer to store the created cma region.
*
* This function reserves memory from early allocator. It should be
* called by arch specific code once the early allocator (memblock or
bootmem)
@@ -156,9 +156,9 @@ core_initcall(cma_init_reserved_areas);
int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed)
+ bool fixed, struct cma **res_cma)
{
- struct cma *cma = cma_areas[cma_area_count];
+ struct cma *cma;
int ret = 0;
pr_debug(%s(size %lx, base %08lx, limit %08lx alignment %08lx)\n,
@@ -214,6 +214,7 @@ int __init cma_declare_contiguous(phys_addr_t size,
* Each reserved area must be initialised later, when more kernel
* subsystems (like slab allocator) are available.
*/
+ cma = cma_areas[cma_area_count];
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
cma-order_per_bit = order_per_bit;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 77871] New: USB device passthrough to Virtual GUEST system from Linux
https://bugzilla.kernel.org/show_bug.cgi?id=77871 Bug ID: 77871 Summary: USB device passthrough to Virtual GUEST system from Linux Product: Virtualization Version: unspecified Kernel Version: 3.14.6 or 3.14.7 Hardware: All OS: Linux Tree: Fedora Status: NEW Severity: high Priority: P1 Component: kvm Assignee: virtualization_...@kernel-bugs.osdl.org Reporter: ertaner...@gmail.com Regression: No Created attachment 139701 -- https://bugzilla.kernel.org/attachment.cgi?id=139701action=edit Full log file. After kernel 3.14.6 and 3.14.7 upgrade at Fedora when I try passthrough any USB device to Virtual GUEST then kerel create log some time after rsyslog demon top collect log due rate limit. I try that problem with Qemu KVM and Virtualbox. Also I add full log file to this ticket. I get that log from Fedora 20 when I use Virtualbox but also KVM have same problem. -##- Jun 13 10:44:58 homless kernel: WARNING: CPU: 0 PID: 15753 at drivers/usb/core/urb.c:476 usb_submit_urb+0x28d/0x5c0() Jun 13 10:44:58 homless kernel: usb 3-2.2: BOGUS urb flags, 1 -- 0 Jun 13 10:44:58 homless kernel: Modules linked in: ax88179_178a usbnet rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt rtl8187 eeprom_93cx6 nls_utf8 udf crc_itu_t usb_storage fuse ccm nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter bnep bluetooth 6lowpan_iphc ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle vboxpci(OF) vboxnetadp(OF) iptable_security vboxnetflt(OF) iptable_raw vboxdrv(OF) bbswitch(OF) iTCO_wdt rtsx_pci_sdmmc iTCO_vendor_support rtsx_pci_ms mmc_core memstick arc4 uvcvideo videobuf2_vmalloc videobuf2_memops Jun 13 10:44:58 homless kernel: videobuf2_core videodev media snd_hda_codec_hdmi snd_hda_codec_via snd_hda_codec_generic x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ath9k ghash_clmulni_intel ath9k_common snd_hda_codec snd_hwdep ath9k_hw snd_seq snd_seq_device ath snd_pcm mac80211 microcode joydev serio_raw cfg80211 r8169 rtsx_pci mii snd_timer lpc_ich snd mfd_core rfkill i2c_i801 soundcore mei_me shpchp mei tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc mxm_wmi i915 i2c_algo_bit drm_kms_helper drm i2c_core video wmi [last unloaded: nvidia] Jun 13 10:44:58 homless kernel: CPU: 0 PID: 15753 Comm: EMT-1 Tainted: PF W O 3.14.7-200.fc20.x86_64 #1 Jun 13 10:44:58 homless kernel: Hardware name: CLEVO CO. W110ER /W110ER , BIOS 1.02.11 PM v3 07/01/20 Jun 13 10:44:58 homless kernel: bf4461af 8802a0239ca8 816f04b2 Jun 13 10:44:58 homless kernel: 8802a0239cf0 8802a0239ce0 8108a1cd 8802e99e79c0 Jun 13 10:44:58 homless kernel: 88036a43e800 0002 0001 0020 Jun 13 10:44:58 homless kernel: Call Trace: Jun 13 10:44:58 homless kernel: [816f04b2] dump_stack+0x45/0x56 Jun 13 10:44:58 homless kernel: [8108a1cd] warn_slowpath_common+0x7d/0xa0 Jun 13 10:44:58 homless kernel: [8108a24c] warn_slowpath_fmt+0x5c/0x80 Jun 13 10:44:58 homless kernel: [814e4d4d] usb_submit_urb+0x28d/0x5c0 Jun 13 10:44:58 homless kernel: [814f0e0d] proc_do_submiturb+0xc6d/0xcc0 Jun 13 10:44:58 homless kernel: [811cc265] ? __kmalloc+0x55/0x240 Jun 13 10:44:58 homless kernel: [a10ace8d] ? rtR0MemAllocEx+0x19d/0x280 [vboxdrv] Jun 13 10:44:58 homless kernel: [814f130f] usbdev_do_ioctl+0x4af/0x1080 Jun 13 10:44:58 homless kernel: [a10acfca] ? rtR0MemFree+0x5a/0x70 [vboxdrv] Jun 13 10:44:58 homless kernel: [814f1f0e] usbdev_ioctl+0xe/0x20 Jun 13 10:44:58 homless kernel: [811fd0f0] do_vfs_ioctl+0x2e0/0x4a0 Jun 13 10:44:58 homless kernel: [811fd331] SyS_ioctl+0x81/0xa0 Jun 13 10:44:58 homless kernel: [81121eb6] ? __audit_syscall_exit+0x1f6/0x2a0 Jun 13 10:44:58 homless kernel: [81700869] system_call_fastpath+0x16/0x1b Jun 13 10:44:58 homless kernel: ---[ end trace 0fe71e2b17d4081e ]--- Jun 13 10:44:58 homless kernel: xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 2 with no TDs queued? Jun 13 10:44:58 homless kernel: xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 2 with no TDs queued? Jun 13 10:44:58 homless kernel: xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 2 with no TDs queued? Jun 13 10:44:58 homless kernel: xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 2 with no TDs
Re: [PATCH v2 00/10] CMA: generalize CMA reserved area management code
Joonsoo Kim iamjoonsoo@lge.com writes: Currently, there are two users on CMA functionality, one is the DMA subsystem and the other is the kvm on powerpc. They have their own code to manage CMA reserved area even if they looks really similar. From my guess, it is caused by some needs on bitmap management. Kvm side wants to maintain bitmap not for 1 page, but for more size. Eventually it use bitmap where one bit represents 64 pages. When I implement CMA related patches, I should change those two places to apply my change and it seem to be painful to me. I want to change this situation and reduce future code management overhead through this patch. This change could also help developer who want to use CMA in their new feature development, since they can use CMA easily without copying pasting this reserved area management code. v2: Although this patchset looks very different with v1, the end result, that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7. Patch 1-5 prepare some features to cover ppc kvm's requirements. Patch 6-7 generalize CMA reserved area management code and change users to use it. Patch 8-10 clean-up minor things. I wanted to test the ppc changes and found that the patch series doesn't apply against v3.15 . Do you have a kernel tree which I can clone to test this series ? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] PPC, KVM, CMA: use general CMA reserved area management framework
Joonsoo Kim iamjoonsoo@lge.com writes:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Need this. We may want to keep the VM_BUG_ON by moving
KVM_CMA_CHUNK_ORDER around.
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 8056107..1932e0e 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -37,8 +37,6 @@
#include asm/ppc-opcode.h
#include asm/cputable.h
-#include book3s_hv_cma.h
-
/* POWER7 has 10-bit LPIDs, PPC970 has 6-bit LPIDs */
#define MAX_LPID_970 63
@@ -64,7 +62,6 @@ long kvmppc_alloc_hpt(struct kvm *kvm, u32 *htab_orderp)
}
kvm-arch.hpt_cma_alloc = 0;
- VM_BUG_ON(order KVM_CMA_CHUNK_ORDER);
page = kvm_alloc_hpt(1 (order - PAGE_SHIFT));
if (page) {
hpt = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] PPC, KVM, CMA: use general CMA reserved area management framework
Joonsoo Kim iamjoonsoo@lge.com writes:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 7cde8a6..28ec226 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -16,12 +16,14 @@
#include linux/init.h
#include linux/memblock.h
#include linux/sizes.h
+#include linux/cma.h
#include asm/cputable.h
#include asm/kvm_ppc.h
#include asm/kvm_book3s.h
-#include book3s_hv_cma.h
+#define KVM_CMA_CHUNK_ORDER 18
+
/*
* Hash page table alignment on newer cpus(CPU_FTR_ARCH_206)
* should be power of 2.
@@ -43,6 +45,8 @@ static unsigned long kvm_cma_resv_ratio = 5;
unsigned long kvm_rma_pages = (1 27) PAGE_SHIFT; /* 128MB */
EXPORT_SYMBOL_GPL(kvm_rma_pages);
+static struct cma *kvm_cma;
+
/* Work out RMLS (real mode limit selector) field value for a given RMA size.
Assumes POWER7 or PPC970. */
static inline int lpcr_rmls(unsigned long rma_size)
@@ -97,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
- page = kvm_alloc_cma(kvm_rma_pages, kvm_rma_pages);
+ page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(ri-use_count, 1);
@@ -112,7 +116,7 @@ EXPORT_SYMBOL_GPL(kvm_alloc_rma);
void kvm_release_rma(struct kvm_rma_info *ri)
{
if (atomic_dec_and_test(ri-use_count)) {
- kvm_release_cma(pfn_to_page(ri-base_pfn), kvm_rma_pages);
+ cma_release(kvm_cma, pfn_to_page(ri-base_pfn), kvm_rma_pages);
kfree(ri);
}
}
@@ -134,13 +138,13 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
- return kvm_alloc_cma(nr_pages, align_pages);
+ return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
void kvm_release_hpt(struct page *page, unsigned long nr_pages)
{
- kvm_release_cma(page, nr_pages);
+ cma_release(kvm_cma, page, nr_pages);
}
EXPORT_SYMBOL_GPL(kvm_release_hpt);
@@ -179,7 +183,8 @@ void __init kvm_cma_reserve(void)
align_size = HPT_ALIGN_PAGES PAGE_SHIFT;
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
- kvm_cma_declare_contiguous(selected_size, align_size);
+ cma_declare_contiguous(selected_size, 0, 0, align_size,
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
}
}
diff --git a/arch/powerpc/kvm/book3s_hv_cma.c
b/arch/powerpc/kvm/book3s_hv_cma.c
deleted file mode 100644
index d9d3d85..000
--- a/arch/powerpc/kvm/book3s_hv_cma.c
+++ /dev/null
@@ -1,240 +0,0 @@
-/*
- * Contiguous Memory Allocator for ppc KVM hash pagetable based on CMA
- * for DMA mapping framework
- *
- * Copyright IBM Corporation, 2013
- * Author Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License or (at your optional) any later version of the license.
- *
- */
-#define pr_fmt(fmt) kvm_cma: fmt
-
-#ifdef CONFIG_CMA_DEBUG
-#ifndef DEBUG
-# define DEBUG
-#endif
-#endif
-
-#include linux/memblock.h
-#include linux/mutex.h
-#include linux/sizes.h
-#include linux/slab.h
-
-#include book3s_hv_cma.h
-
-struct kvm_cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
-};
-
-static DEFINE_MUTEX(kvm_cma_mutex);
-static struct kvm_cma kvm_cma_area;
-
-/**
- * kvm_cma_declare_contiguous() - reserve area for contiguous memory handling
- * for kvm hash pagetable
- * @size: Size of the reserved memory.
- * @alignment: Alignment for the contiguous memory area
- *
- * This function reserves memory for kvm cma area. It should be
- * called by arch code when early allocator (memblock or bootmem)
- * is still activate.
- */
-long __init kvm_cma_declare_contiguous(phys_addr_t size, phys_addr_t
alignment)
-{
- long base_pfn;
- phys_addr_t addr;
- struct kvm_cma *cma = kvm_cma_area;
-
- pr_debug(%s(size %lx)\n, __func__, (unsigned long)size);
-
- if (!size)
- return -EINVAL;
- /*
- * Sanitise input arguments.
- * We should be pageblock aligned for CMA.
- */
-
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- * alloc_contig_range requires the pfn range
- * specified to be in the same zone. Make this
- * simple by forcing the
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- * alloc_contig_range requires the pfn range
- * specified to be in the same zone. Make this
- * simple by forcing the
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
Joonsoo Kim iamjoonsoo@lge.com writes:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+ return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+ return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+ unsigned long pages)
+{
+ return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
- phys_addr_t alignment,
+ phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+ /* size should be aligned with order_per_bit */
+ BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+ cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
- mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
- unsigned long mask, pfn, pageno, start = 0;
+ unsigned long mask, pfn, start = 0;
+ unsigned long bitmap_maxno, bitmapno, nr_bits;
struct page *page =
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
.
+
+ mask = cma_bitmap_aligned_mask(cma, align);
+ bitmap_maxno = cma_bitmap_maxno(cma);
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ for (;;) {
+ mutex_lock(cma-lock);
+ bitmapno = bitmap_find_next_zero_area(cma-bitmap,
+ bitmap_maxno, start, nr_bits, mask);
+ if (bitmapno = bitmap_maxno) {
+ mutex_unlock(cma-lock);
+ break;
+ }
+ bitmap_set(cma-bitmap, bitmapno, nr_bits);
+ /*
+ * It's safe to drop the lock here. We've marked this region for
+ * our exclusive use. If the migration fails we will take the
+ * lock again and unmark it.
+ */
+ mutex_unlock(cma-lock);
+
+ pfn = cma-base_pfn + (bitmapno cma-order_per_bit);
+ mutex_lock(cma_mutex);
+ ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
+ mutex_unlock(cma_mutex);
+ if (ret == 0) {
+ page = pfn_to_page(pfn);
+ break;
+ } else if (ret != -EBUSY) {
+ clear_cma_bitmap(cma, pfn, count);
+ break;
+ }
+
For setting bit map we do
bitmap_set(cma-bitmap, bitmapno, nr_bits);
alloc_contig()..
if (error)
clear_cma_bitmap(cma, pfn, count);
Why ?
why not bitmap_clear() ?
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 11/19] add minimal virtio support for devtree virtio-mmio
On Wed, Jun 11, 2014 at 04:01:26PM +0200, Andrew Jones wrote: Support the bare minimum of virtio to enable access to the virtio-mmio config space of a device. Currently this implementation must use a device tree to find the device. Signed-off-by: Andrew Jones drjo...@redhat.com --- v5: - use same virtio struct names as kernel - no need to alloc a new virtio_config_ops for each virtio device - use ioremap v4: - split from the virtio-testdev patch - search a table to discover that the device must be DT/virtio-mmio, which doesn't change anything, but looks less hacky than comments saying the device must be DT/virtio-mmio... - manage own pool of virtio-mmio pre-allocated device structures in order to avoid needing access to the heap --- Reviewed-by: Christoffer Dall christoffer.d...@linaro.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 15/19] arm: initial drop
On Wed, Jun 11, 2014 at 04:01:30PM +0200, Andrew Jones wrote:
This is the initial drop of the arm test framework and a first test
that just checks that setup completed (a selftest). kvm isn't needed
to run this test unless testing with smp 1.
Try it out with
yum install gcc-arm-linux-gnu
export QEMU=[qemu with mach-virt and virtio-testdev]
./configure --cross-prefix=arm-linux-gnu- --arch=arm
make
./run_tests.sh
Signed-off-by: Andrew Jones drjo...@redhat.com
---
v5:
- memregions: check freemem_start is in bounds and document
- selftest: rename testnam = testname and properly init it
- io.c: use writeb instead of writel in puts() and use ioremap
- arm/run script update for new qemu ('-device ?' now requires -machine)
- couple other minor changes to setup.c and io.c [Christoffer Dall]
v4:
- moved fdt to just after stacktop (it was in the middle of free memory)
- switched from using heap to memregions
- get nr_cpus and added smp=num test
- added barrier.h
- use new report()/report_summary()
- config/config-arm.mak cleanup
---
arm/cstart.S | 35
arm/flat.lds | 18 ++
arm/run| 35
arm/selftest.c | 89 +
arm/unittests.cfg | 18 ++
config/config-arm.mak | 72
configure | 12 +++-
lib/argv.c | 6 ++
lib/arm/asm/barrier.h | 18 ++
lib/arm/asm/io.h | 24
lib/arm/asm/setup.h| 63 +
lib/arm/asm/spinlock.h | 16 ++
lib/arm/eabi_compat.c | 20 +++
lib/arm/io.c | 65 +
lib/arm/setup.c| 149
+
15 files changed, 638 insertions(+), 2 deletions(-)
create mode 100644 arm/cstart.S
create mode 100644 arm/flat.lds
create mode 100755 arm/run
create mode 100644 arm/selftest.c
create mode 100644 arm/unittests.cfg
create mode 100644 config/config-arm.mak
create mode 100644 lib/arm/asm/barrier.h
create mode 100644 lib/arm/asm/io.h
create mode 100644 lib/arm/asm/setup.h
create mode 100644 lib/arm/asm/spinlock.h
create mode 100644 lib/arm/eabi_compat.c
create mode 100644 lib/arm/io.c
create mode 100644 lib/arm/setup.c
diff --git a/arm/cstart.S b/arm/cstart.S
new file mode 100644
index 0..e28251db2950d
--- /dev/null
+++ b/arm/cstart.S
@@ -0,0 +1,35 @@
+/*
+ * Boot entry point and assembler functions for armv7 tests.
+ *
+ * Copyright (C) 2014, Red Hat Inc, Andrew Jones drjo...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.
+ */
+
+.arm
+
+.section .init
+
+.globl start
+start:
+ /*
+ * bootloader params are in r0-r2
+ * See the kernel doc Documentation/arm/Booting
+ */
+ ldr sp, =stacktop
+ bl setup
+
+ /* run the test */
+ ldr r0, =__argc
+ ldr r0, [r0]
+ ldr r1, =__argv
+ bl main
+ bl exit
+ b halt
+
+.text
+
+.globl halt
+halt:
+1: wfi
+ b 1b
diff --git a/arm/flat.lds b/arm/flat.lds
new file mode 100644
index 0..3e5d72e24989b
--- /dev/null
+++ b/arm/flat.lds
@@ -0,0 +1,18 @@
+
+SECTIONS
+{
+.text : { *(.init) *(.text) *(.text.*) }
+. = ALIGN(4K);
+.data : { *(.data) }
+. = ALIGN(16);
+.rodata : { *(.rodata) }
+. = ALIGN(16);
+.bss : { *(.bss) }
+. = ALIGN(4K);
+edata = .;
+. += 8K;
+. = ALIGN(4K);
+stacktop = .;
+}
+
+ENTRY(start)
diff --git a/arm/run b/arm/run
new file mode 100755
index 0..627123b7bc9b6
--- /dev/null
+++ b/arm/run
@@ -0,0 +1,35 @@
+#!/bin/bash
+
+if [ ! -f config.mak ]; then
+ echo run ./configure first. See ./configure -h
+ exit 2
+fi
+source config.mak
+
+qemu=${QEMU:-qemu-system-arm}
+qpath=$(which $qemu 2/dev/null)
+testdev=virtio-testdev
+
+if [ -z $qpath ]; then
+ echo $qemu not found.
+ exit 2
+fi
+
+if ! $qemu -machine '?' 21 | grep 'ARM Virtual Machine' /dev/null; then
+ echo $qpath doesn't support mach-virt ('-machine virt'). Exiting.
+ exit 2
+fi
+
+if ! $qemu -machine virt -device '?' 21 | grep $testdev /dev/null; then
+ echo $qpath doesn't support $testdev. Exiting.
+ exit 2
+fi
+
+command=$qemu -machine virt,accel=kvm:tcg -device $testdev -cpu $PROCESSOR
+command+= -display none -serial stdio -kernel
+
+echo $command $@
+$command $@
+ret=$?
+echo Return value from qemu: $ret
+exit $ret
diff --git a/arm/selftest.c b/arm/selftest.c
new file mode 100644
index 0..bcaecfae17fcd
--- /dev/null
+++ b/arm/selftest.c
@@ -0,0 +1,89 @@
+/*
+ * Test the framework itself. These tests confirm that setup works.
+ *
+ * Copyright (C) 2014, Red Hat Inc, Andrew Jones drjo...@redhat.com
+ *
+ * This work is licensed under
Re: [PATCH v5 00/19] kvm-unit-tests/arm: initial drop
On Wed, Jun 11, 2014 at 04:01:15PM +0200, Andrew Jones wrote: This is a v5 of a series that introduces arm to kvm-unit-tests. First, it does some tidying up of the repo. Then, it adds support for device trees (libfdt), and for virtio-testdev[1]. Next, it adds the basic infrastructure for booting a test case (guest), and adds a first test case, a self-test to confirm setup was completed successfully. Finally, it further prepares the framework for more complicated tests by adding vector support, and extends the self-test to test that too. This initial drop doesn't require kvmarm. qemu-system-arm is enough, but it must have mach-virt, and the virtio-testdev patch[1]. These patches (v5) are also available from a git repo here https://github.com/rhdrjones/kvm-unit-tests/commits/arm/v5-initial-drop The v4 patches are available for reference here https://github.com/rhdrjones/kvm-unit-tests/commits/arm/v4-initial-drop Not too much has changed since v4. There are no new patches nor dropped patches, and all patches that did get a change have a v5 note. To see a branch interdiff (created with git-tbdiff[2]) take a look here[3]. Thanks in advance for reviews! This now looks pretty good overall. Feels to me like if you address Paolo's comments then this could be merged, and we can start adding more complicated tests to it. When you send out the next (last?) version, I can give it a spin on hardware with KVM as well. -Christoffer -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
(resending, this email is missing at http://lists.nongnu.org/archive/html/qemu-devel/2014-06/index.html) Fine, however Red Hat would also need a way to test ivshmem code, with proper quality assurance (that also benefits upstream, of course). With ivshmem this is not possible without the out-of-tree packages. You did not reply to my question: how to get the list of things that are/will be disabled by Redhat? About Redhat's QA, I do not care. About Qemu's QA, I do care ;) I guess we can combine both. What's about something like: tests/virtio-net-test.c # qtest_add_func( is a nop) but for ivshmem test/ivshmem-test.c ? would it have any values? If not, what do you use at Redhat to test Qemu? now, you cannot compare vhost-user to DPDK/ivshmem; both should exsit because they have different scope and use cases. It is like comparing two different(A) models of IPC: I do repeat this use case that you had removed because vhost-user does not solve it yet: - ivshmem - framework to be generic to have shared memory for many use cases (HPC, in-memory-database, a network too like memnic). - vhost-user - networking use case specific Not necessarily. First and foremost, vhost-user defines an API for communication between QEMU and the host, including: * file descriptor passing for the shared memory file * mapping offsets in shared memory to physical memory addresses in the guests * passing dirty memory information back and forth, so that migration is not prevented * sending interrupts to a device * setting up ring buffers in the shared memory Yes, I do agree that it is promising. And of course some tests are here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00584.html for some of the bullets you are listing (not all yet). Also, vhost-user is documented! See here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00581.html as I told you, we'll send a contribution with ivshmem's documentation. The only part of ivshmem that vhost doesn't include is the n-way inter-guest doorbell. This is the part that requires a server and uio driver. vhost only supports host-guest and guest-host doorbells. agree: both will need it: vhost and ivshmem requires a doorbell for VM2VM, but then we'll have a security issue to be managed by Qemu for vhost and ivshmem. I'll be pleased to contribute on it for ivshmem thru another thread that this one. ivhsmem does not require DPDK kernel driver. see memnic's PMD: http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c You're right, I was confusing memnic and the vhost example in DPDK. Definitively, it proves a lack of documentation. You welcome. Olivier did explain it: http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg03127.html ivhsmem does not require hugetlbfs. It is optional. * it doesn't require ivshmem (it does require shared memory, which will also be added to 2.1) Right, hugetlbfs is not required. A posix shared memory or tmpfs can be used instead. For instance, to use /dev/shm/foobar: qemu-system-x86_64 -enable-kvm -cpu host [...] \ -device ivshmem,size=16,shm=foobar Best regards, Vincent -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] arm/arm64: KVM: vgic: Clarify and correct vgic documentation
The VGIC virtual distributor implementation documentation was written a very long time ago, before the true nature of the beast had been partially absorbed into my bloodstream. I think this amalgamates the two evil beings (myself and the code) a little more. Plus, it fixes an actual bug. ICFRn, pfff. Signed-off-by: Christoffer Dall christoffer.d...@linaro.org --- virt/kvm/arm/vgic.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c index 1f91b3b..cc776af 100644 --- a/virt/kvm/arm/vgic.c +++ b/virt/kvm/arm/vgic.c @@ -36,21 +36,22 @@ * How the whole thing works (courtesy of Christoffer Dall): * * - At any time, the dist-irq_pending_on_cpu is the oracle that knows if - * something is pending - * - VGIC pending interrupts are stored on the vgic.irq_pending vgic - * bitmap (this bitmap is updated by both user land ioctls and guest - * mmio ops, and other in-kernel peripherals such as the - * arch. timers) and indicate the 'wire' state. + * something is pending on the CPU interface. + * - Interrupts that are pending on the distributor are stored on the + * vgic.irq_pending vgic bitmap (this bitmap is updated by both user land + * ioctls and guest mmio ops, and other in-kernel peripherals such as the + * arch. timers). * - Every time the bitmap changes, the irq_pending_on_cpu oracle is * recalculated * - To calculate the oracle, we need info for each cpu from * compute_pending_for_cpu, which considers: * - PPI: dist-irq_pending dist-irq_enable * - SPI: dist-irq_pending dist-irq_enable dist-irq_spi_target - * - irq_spi_target is a 'formatted' version of the GICD_ICFGR + * - irq_spi_target is a 'formatted' version of the GICD_ITARGETSRn * registers, stored on each vcpu. We only keep one bit of * information per interrupt, making sure that only one vcpu can * accept the interrupt. + * - If any of the above state changes, we must recalculate the oracle. * - The same is true when injecting an interrupt, except that we only * consider a single interrupt at a time. The irq_spi_cpu array * contains the target CPU for each SPI. -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] arm/arm64: KVM: vgic: Improve handling of GICD_I{CS}PENDRn
The handling of writes to the GICD_ISPENDRn and GICD_ICPENDRn is
currently not handled correctly for level-triggered interrupts. The
spec states that for level-triggered interrupts, writes to the
GICD_ISPENDRn activates the output of a flip-flop which is in turn or'ed
with the actual input interrupt signal. Correspondingly, writes to
GICD_ICPENDRn simply deactives the output of that flip-flop, but does
not (of course) affect the external input signal. Reads from GICC_IAR
will also deactivate the flip-flop output.
This requires us to track the state of the level-input separately from
the state in the flip-flop. Introduce two new variables on the
distributor struct to track these two exact states. Astute readers
may notice that this is introducing more state than required (because an
OR of the two states give you the pending state), but the remainding
vgic code uses the pending bitmap for optimized operations to figure
out, at the end of the day, if an interrupt is pending or not on the
distributor side. Changing all the to consider the two state variables
did not look pretty.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
include/kvm/arm_vgic.h | 16 ++-
virt/kvm/arm/vgic.c| 118 -
2 files changed, 122 insertions(+), 12 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 10fa64b..f678d5c 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -86,9 +86,23 @@ struct vgic_dist {
/* Interrupt enabled (one bit per IRQ) */
struct vgic_bitmap irq_enabled;
- /* Interrupt state is pending on the distributor */
+ /* Level-triggered interrupt external input is asserted */
+ struct vgic_bitmap irq_level;
+
+ /*
+* Interrupt state is pending on the distributor
+*/
struct vgic_bitmap irq_pending;
+ /*
+* Tracks writes to GICD_ISPENDRn and GICD_ICPENDRn for level-triggered
+* interrupts. Essentially holds the state of the flip-flop in
+* Figure 4-10 on page 4-101 in ARM IHI 0048B.b.
+* Once set, it is only cleared for level-triggered interrupts on
+* guest ACKs (when we queue it) or writes to GICD_ICPENDRn.
+*/
+ struct vgic_bitmap irq_soft_pend;
+
/* Level-triggered interrupt queued on VCPU interface */
struct vgic_bitmap irq_queued;
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 87c977c..0b41875 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -67,6 +67,11 @@
* - When the interrupt is EOIed, the maintenance interrupt fires,
* and clears the corresponding bit in irq_queued. This allow the
* interrupt line to be sampled again.
+ * - Note that level-triggered interrupts can also be set to pending from
+ * writes to GICD_ISPENDRn and lowering the external input line does not
+ * cause the interrupt to become inactive in such a situation.
+ * Conversely, writes to GICD_ICPENDRn do not cause the interrupt to become
+ * inactive as long as the external input line is held high.
*/
#define VGIC_ADDR_UNDEF(-1)
@@ -200,6 +205,41 @@ static void vgic_irq_clear_queued(struct kvm_vcpu *vcpu,
int irq)
vgic_bitmap_set_irq_val(dist-irq_queued, vcpu-vcpu_id, irq, 0);
}
+static int vgic_dist_irq_get_level(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ return vgic_bitmap_get_irq_val(dist-irq_level, vcpu-vcpu_id, irq);
+}
+
+static void vgic_dist_irq_set_level(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ vgic_bitmap_set_irq_val(dist-irq_level, vcpu-vcpu_id, irq, 1);
+}
+
+static void vgic_dist_irq_clear_level(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ vgic_bitmap_set_irq_val(dist-irq_level, vcpu-vcpu_id, irq, 0);
+}
+
+static int vgic_dist_irq_soft_pend(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ return vgic_bitmap_get_irq_val(dist-irq_soft_pend, vcpu-vcpu_id,
irq);
+}
+
+static void vgic_dist_irq_clear_soft_pend(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ vgic_bitmap_set_irq_val(dist-irq_soft_pend, vcpu-vcpu_id, irq, 0);
+}
+
static int vgic_dist_irq_is_pending(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
@@ -392,11 +432,26 @@ static bool handle_mmio_set_pending_reg(struct kvm_vcpu
*vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
{
- u32 *reg = vgic_bitmap_get_reg(vcpu-kvm-arch.vgic.irq_pending,
- vcpu-vcpu_id, offset);
+ u32 *reg;
+ u32 level_mask;
+ struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+
+ reg =
[RFC PATCH 2/6] arm/arm64: KVM: Rename irq_active to irq_queued
We have a special bitmap on the distributor struct to keep track of when
level-triggered interrupts are queued on the list registers. This was
named irq_active, which is confusing, because the active state of an
interrupt as per the GIC spec is a different thing, not specifically
related to edge-triggered/level-triggered configurations but rather
indicates an interrupt which has been ack'ed but not yet eoi'ed.
Rename the bitmap and the corresponding accessor functions to irq_queued
to clarify what this is actually used for.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
include/kvm/arm_vgic.h | 4 ++--
virt/kvm/arm/vgic.c| 28 ++--
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index a5d55d5..10fa64b 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -89,8 +89,8 @@ struct vgic_dist {
/* Interrupt state is pending on the distributor */
struct vgic_bitmap irq_pending;
- /* Level-triggered interrupt in progress */
- struct vgic_bitmap irq_active;
+ /* Level-triggered interrupt queued on VCPU interface */
+ struct vgic_bitmap irq_queued;
/* Interrupt priority. Not used yet. */
struct vgic_bytemap irq_priority;
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index aba960a..00e6bdd 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -60,12 +60,12 @@
* the 'line' again. This is achieved as such:
*
* - When a level interrupt is moved onto a vcpu, the corresponding
- * bit in irq_active is set. As long as this bit is set, the line
+ * bit in irq_queued is set. As long as this bit is set, the line
* will be ignored for further interrupts. The interrupt is injected
* into the vcpu with the GICH_LR_EOI bit set (generate a
* maintenance interrupt on EOI).
* - When the interrupt is EOIed, the maintenance interrupt fires,
- * and clears the corresponding bit in irq_active. This allow the
+ * and clears the corresponding bit in irq_queued. This allow the
* interrupt line to be sampled again.
*/
@@ -179,25 +179,25 @@ static int vgic_irq_is_enabled(struct kvm_vcpu *vcpu, int
irq)
return vgic_bitmap_get_irq_val(dist-irq_enabled, vcpu-vcpu_id, irq);
}
-static int vgic_irq_is_active(struct kvm_vcpu *vcpu, int irq)
+static int vgic_irq_is_queued(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- return vgic_bitmap_get_irq_val(dist-irq_active, vcpu-vcpu_id, irq);
+ return vgic_bitmap_get_irq_val(dist-irq_queued, vcpu-vcpu_id, irq);
}
-static void vgic_irq_set_active(struct kvm_vcpu *vcpu, int irq)
+static void vgic_irq_set_queued(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- vgic_bitmap_set_irq_val(dist-irq_active, vcpu-vcpu_id, irq, 1);
+ vgic_bitmap_set_irq_val(dist-irq_queued, vcpu-vcpu_id, irq, 1);
}
-static void vgic_irq_clear_active(struct kvm_vcpu *vcpu, int irq)
+static void vgic_irq_clear_queued(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- vgic_bitmap_set_irq_val(dist-irq_active, vcpu-vcpu_id, irq, 0);
+ vgic_bitmap_set_irq_val(dist-irq_queued, vcpu-vcpu_id, irq, 0);
}
static int vgic_dist_irq_is_pending(struct kvm_vcpu *vcpu, int irq)
@@ -1011,8 +1011,8 @@ static void vgic_retire_disabled_irqs(struct kvm_vcpu
*vcpu)
if (!vgic_irq_is_enabled(vcpu, irq)) {
vgic_retire_lr(lr, irq, vgic_cpu);
- if (vgic_irq_is_active(vcpu, irq))
- vgic_irq_clear_active(vcpu, irq);
+ if (vgic_irq_is_queued(vcpu, irq))
+ vgic_irq_clear_queued(vcpu, irq);
}
}
}
@@ -1095,7 +1095,7 @@ static bool vgic_queue_sgi(struct kvm_vcpu *vcpu, int irq)
static bool vgic_queue_hwirq(struct kvm_vcpu *vcpu, int irq)
{
- if (vgic_irq_is_active(vcpu, irq))
+ if (vgic_irq_is_queued(vcpu, irq))
return true; /* level interrupt, already queued */
if (vgic_queue_irq(vcpu, 0, irq)) {
@@ -1103,7 +1103,7 @@ static bool vgic_queue_hwirq(struct kvm_vcpu *vcpu, int
irq)
vgic_dist_irq_clear_pending(vcpu, irq);
vgic_cpu_irq_clear(vcpu, irq);
} else {
- vgic_irq_set_active(vcpu, irq);
+ vgic_irq_set_queued(vcpu, irq);
}
return true;
@@ -1186,7 +1186,7 @@ static bool vgic_process_maintenance(struct kvm_vcpu
*vcpu)
vgic_cpu-nr_lr) {
irq = vgic_cpu-vgic_lr[lr] GICH_LR_VIRTUALID;
- vgic_irq_clear_active(vcpu, irq);
+ vgic_irq_clear_queued(vcpu, irq);
[RFC PATCH 0/6] arm/arm64: KVM: Various VGIC cleanups and improvements
The VGIC distributor struct has a number of fields which are named
subopimally when needing to add more refined handling of level-triggered
interrupts.
We also never handled writes to the GICD_ISPENDRn and GICD_ICPENDRn
properly, which was never a real concern until we started playing with
IRQ injection for assigned devices, IRQFDs, and other fun stuff.
This RFC series tries to address some of these issues.
*** WARNING ***
This series is untested!!
I am only sending it out now, untested, as is, giving people
ever-lasting right to ridicule me, because Eric Auger is blocked on this
work and I wanted to communicate my thoughts on how to handle this.
It also has the added benefit of receiving early comments (yes, please!)
and let other people who are messing around with this file a chance to
scream at me.
Christoffer Dall (6):
arm/arm64: KVM: Rename irq_state to irq_pending
arm/arm64: KVM: Rename irq_active to irq_queued
arm/arm64: KVM: vgic: Clear queued flags on unqueue
arm/arm64: KVM: vgic: Improve handling of GICD_I{CS}PENDRn
arm/arm64: KVM: vgic: Fix SGI writes to GICD_I{CS}PENDR0
arm/arm64: KVM: vgic: Clarify and correct vgic documentation
include/kvm/arm_vgic.h | 24 --
virt/kvm/arm/vgic.c| 217 +
2 files changed, 184 insertions(+), 57 deletions(-)
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/6] arm/arm64: KVM: vgic: Clear queued flags on unqueue
If we unqueue a level-triggered interrupt completely, and the LR does
not stick around in the active state (and will therefore no longer
generate a maintenance interrupt), then we should clear the queued flag
so that the vgic can actually queue this level-triggered interrupt at a
later time and deal with its pending state then.
Note: This should actually be properly fixed to handle the active state
on the distributor.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
virt/kvm/arm/vgic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 00e6bdd..87c977c 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -660,8 +660,10 @@ static void vgic_unqueue_irqs(struct kvm_vcpu *vcpu)
* active), then the LR does not hold any useful info and can
* be marked as free for other use.
*/
- if (!(*lr GICH_LR_STATE))
+ if (!(*lr GICH_LR_STATE)) {
vgic_retire_lr(i, irq, vgic_cpu);
+ vgic_irq_clear_queued(vcpu, irq);
+ }
/* Finally update the VGIC state. */
vgic_update_state(vcpu-kvm);
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/6] arm/arm64: KVM: vgic: Fix SGI writes to GICD_I{CS}PENDR0
Writes to GICD_ISPENDR0 and GICD_ICPENDR0 ignore all settings of the
pending state for SGIs. Make sure the implementation handles this
correctly.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
virt/kvm/arm/vgic.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 0b41875..1f91b3b 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -432,7 +432,7 @@ static bool handle_mmio_set_pending_reg(struct kvm_vcpu
*vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
{
- u32 *reg;
+ u32 *reg, orig;
u32 level_mask;
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
@@ -441,6 +441,7 @@ static bool handle_mmio_set_pending_reg(struct kvm_vcpu
*vcpu,
/* Mark both level and edge triggered irqs as pending */
reg = vgic_bitmap_get_reg(dist-irq_pending, vcpu-vcpu_id, offset);
+ orig = *reg;
vgic_reg_access(mmio, reg, offset,
ACCESS_READ_VALUE | ACCESS_WRITE_SETBIT);
@@ -452,6 +453,12 @@ static bool handle_mmio_set_pending_reg(struct kvm_vcpu
*vcpu,
ACCESS_READ_VALUE | ACCESS_WRITE_SETBIT);
*reg = level_mask;
+ /* Ignore writes to SGIs */
+ if (offset 2) {
+ *reg = ~0x;
+ *reg |= orig 0x;
+ }
+
vgic_update_state(vcpu-kvm);
return true;
}
@@ -464,10 +471,11 @@ static bool handle_mmio_clear_pending_reg(struct kvm_vcpu
*vcpu,
phys_addr_t offset)
{
u32 *level_active;
- u32 *reg;
+ u32 *reg, orig;
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
reg = vgic_bitmap_get_reg(dist-irq_pending, vcpu-vcpu_id, offset);
+ orig = *reg;
vgic_reg_access(mmio, reg, offset,
ACCESS_READ_VALUE | ACCESS_WRITE_CLEARBIT);
if (mmio-is_write) {
@@ -478,6 +486,12 @@ static bool handle_mmio_clear_pending_reg(struct kvm_vcpu
*vcpu,
vcpu-vcpu_id, offset);
*reg |= *level_active;
+ /* Ignore writes to SGIs */
+ if (offset 2) {
+ *reg = ~0x;
+ *reg |= orig 0x;
+ }
+
/* Clear soft-pending flags */
reg = vgic_bitmap_get_reg(dist-irq_soft_pend,
vcpu-vcpu_id, offset);
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6] arm/arm64: KVM: Rename irq_state to irq_pending
The irq_state field on the distributor struct is ambiguous in its
meaning; the comment says it's the level of the input put, but that
doesn't make much sense for edge-triggered interrupts. The code
actually uses this state variable to check if the interrupt is in the
pending state on the distributor so clarify the comment and rename the
actual variable and accessor methods.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
include/kvm/arm_vgic.h | 4 ++--
virt/kvm/arm/vgic.c| 52 +-
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index f27000f..a5d55d5 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -86,8 +86,8 @@ struct vgic_dist {
/* Interrupt enabled (one bit per IRQ) */
struct vgic_bitmap irq_enabled;
- /* Interrupt 'pin' level */
- struct vgic_bitmap irq_state;
+ /* Interrupt state is pending on the distributor */
+ struct vgic_bitmap irq_pending;
/* Level-triggered interrupt in progress */
struct vgic_bitmap irq_active;
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 47b2983..aba960a 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -37,7 +37,7 @@
*
* - At any time, the dist-irq_pending_on_cpu is the oracle that knows if
* something is pending
- * - VGIC pending interrupts are stored on the vgic.irq_state vgic
+ * - VGIC pending interrupts are stored on the vgic.irq_pending vgic
* bitmap (this bitmap is updated by both user land ioctls and guest
* mmio ops, and other in-kernel peripherals such as the
* arch. timers) and indicate the 'wire' state.
@@ -45,8 +45,8 @@
* recalculated
* - To calculate the oracle, we need info for each cpu from
* compute_pending_for_cpu, which considers:
- * - PPI: dist-irq_state dist-irq_enable
- * - SPI: dist-irq_state dist-irq_enable dist-irq_spi_target
+ * - PPI: dist-irq_pending dist-irq_enable
+ * - SPI: dist-irq_pending dist-irq_enable dist-irq_spi_target
* - irq_spi_target is a 'formatted' version of the GICD_ICFGR
* registers, stored on each vcpu. We only keep one bit of
* information per interrupt, making sure that only one vcpu can
@@ -204,21 +204,21 @@ static int vgic_dist_irq_is_pending(struct kvm_vcpu
*vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- return vgic_bitmap_get_irq_val(dist-irq_state, vcpu-vcpu_id, irq);
+ return vgic_bitmap_get_irq_val(dist-irq_pending, vcpu-vcpu_id, irq);
}
-static void vgic_dist_irq_set(struct kvm_vcpu *vcpu, int irq)
+static void vgic_dist_irq_set_pending(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- vgic_bitmap_set_irq_val(dist-irq_state, vcpu-vcpu_id, irq, 1);
+ vgic_bitmap_set_irq_val(dist-irq_pending, vcpu-vcpu_id, irq, 1);
}
-static void vgic_dist_irq_clear(struct kvm_vcpu *vcpu, int irq)
+static void vgic_dist_irq_clear_pending(struct kvm_vcpu *vcpu, int irq)
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
- vgic_bitmap_set_irq_val(dist-irq_state, vcpu-vcpu_id, irq, 0);
+ vgic_bitmap_set_irq_val(dist-irq_pending, vcpu-vcpu_id, irq, 0);
}
static void vgic_cpu_irq_set(struct kvm_vcpu *vcpu, int irq)
@@ -392,7 +392,7 @@ static bool handle_mmio_set_pending_reg(struct kvm_vcpu
*vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
{
- u32 *reg = vgic_bitmap_get_reg(vcpu-kvm-arch.vgic.irq_state,
+ u32 *reg = vgic_bitmap_get_reg(vcpu-kvm-arch.vgic.irq_pending,
vcpu-vcpu_id, offset);
vgic_reg_access(mmio, reg, offset,
ACCESS_READ_VALUE | ACCESS_WRITE_SETBIT);
@@ -408,7 +408,7 @@ static bool handle_mmio_clear_pending_reg(struct kvm_vcpu
*vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
{
- u32 *reg = vgic_bitmap_get_reg(vcpu-kvm-arch.vgic.irq_state,
+ u32 *reg = vgic_bitmap_get_reg(vcpu-kvm-arch.vgic.irq_pending,
vcpu-vcpu_id, offset);
vgic_reg_access(mmio, reg, offset,
ACCESS_READ_VALUE | ACCESS_WRITE_CLEARBIT);
@@ -650,7 +650,7 @@ static void vgic_unqueue_irqs(struct kvm_vcpu *vcpu)
* is fine, then we are only setting a few bits that were
* already set.
*/
- vgic_dist_irq_set(vcpu, irq);
+ vgic_dist_irq_set_pending(vcpu, irq);
if (irq VGIC_NR_SGIS)
dist-irq_sgi_sources[vcpu_id][irq] |= 1 source_cpu;
*lr = ~GICH_LR_PENDING_BIT;
@@ -929,7 +929,7 @@ static void vgic_dispatch_sgi(struct kvm_vcpu *vcpu, u32
reg)
[PATCH] powerpc/kvm: support to handle sw breakpoint
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch mandates use of abs
instruction
(primary opcode 31 and extended opcode 360) as sw breakpoint instruction.
Based on PowerISA v2.01, ABS instruction has been dropped from the architecture
and treated an illegal instruction.
Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s.c| 3 ++-
arch/powerpc/kvm/book3s_hv.c | 23 +++
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index c254c27..b40fe5d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -789,7 +789,8 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- return -EINVAL;
+ vcpu-guest_debug = dbg-control;
+ return 0;
}
void kvmppc_decrementer_func(unsigned long data)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7a12edb..688421d 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -67,6 +67,14 @@
/* Used as a null value for timebase values */
#define TB_NIL (~(u64)0)
+/*
+ * SW_BRK_DBG_INT is debug Instruction for supporting Software Breakpoint.
+ * Instruction mnemonic is ABS, primary opcode is 31 and extended opcode is
360.
+ * Based on PowerISA v2.01, ABS instruction has been dropped from the
architecture
+ * and treated an illegal instruction.
+ */
+#define SW_BRK_DBG_INT 0x7c0002d0
+
static void kvmppc_end_cede(struct kvm_vcpu *vcpu);
static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu);
@@ -721,12 +729,19 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run,
struct kvm_vcpu *vcpu,
break;
/*
* This occurs if the guest executes an illegal instruction.
-* We just generate a program interrupt to the guest, since
-* we don't emulate any guest instructions at this stage.
+* To support software breakpoint, we check for the sw breakpoint
+* instruction to return back to host, if not we just generate a
+* program interrupt to the guest.
*/
case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
- kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
- r = RESUME_GUEST;
+ if (vcpu-arch.last_inst == SW_BRK_DBG_INT) {
+ run-exit_reason = KVM_EXIT_DEBUG;
+ run-debug.arch.address = vcpu-arch.pc;
+ r = RESUME_HOST;
+ } else {
+ kvmppc_core_queue_program(vcpu, 0x8);
+ r = RESUME_GUEST;
+ }
break;
/*
* This occurs if the guest (kernel or userspace), does something that
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path
Joonsoo Kim iamjoonsoo@lge.com writes:
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
if (ret == 0) {
page = pfn_to_page(pfn);
break;
- } else if (ret != -EBUSY) {
- clear_cma_bitmap(cma, pfn, count);
- break;
}
+
clear_cma_bitmap(cma, pfn, count);
+ if (ret != -EBUSY)
+ break;
+
pr_debug(%s(): memory range at %p is busy, retrying\n,
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list
Joonsoo Kim iamjoonsoo@lge.com writes:
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 28ec226..97613ea 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -184,7 +184,7 @@ void __init kvm_cma_reserve(void)
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
cma_declare_contiguous(selected_size, 0, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index f177f73..bfd4553 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -149,7 +149,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(size, base, limit, 0, 0, res_cma, fixed);
+ ret = cma_declare_contiguous(size, base, limit, 0, 0, fixed, res_cma);
if (ret)
return ret;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index e38efe9..e53eead 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -6,7 +6,7 @@ struct cma;
extern int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed);
+ bool fixed, struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, int count, unsigned int
align);
extern bool cma_release(struct cma *cma, struct page *pages, int count);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 01a0713..22a5b23 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -142,8 +142,8 @@ core_initcall(cma_init_reserved_areas);
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
* @order_per_bit: Order of pages represented by one bit on bitmap.
- * @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
+ * @res_cma: Pointer to store the created cma region.
*
* This function reserves memory from early allocator. It should be
* called by arch specific code once the early allocator (memblock or
bootmem)
@@ -156,9 +156,9 @@ core_initcall(cma_init_reserved_areas);
int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed)
+ bool fixed, struct cma **res_cma)
{
- struct cma *cma = cma_areas[cma_area_count];
+ struct cma *cma;
int ret = 0;
pr_debug(%s(size %lx, base %08lx, limit %08lx alignment %08lx)\n,
@@ -214,6 +214,7 @@ int __init cma_declare_contiguous(phys_addr_t size,
* Each reserved area must be initialised later, when more kernel
* subsystems (like slab allocator) are available.
*/
+ cma = cma_areas[cma_area_count];
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
cma-order_per_bit = order_per_bit;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] CMA: generalize CMA reserved area management code
Joonsoo Kim iamjoonsoo@lge.com writes: Currently, there are two users on CMA functionality, one is the DMA subsystem and the other is the kvm on powerpc. They have their own code to manage CMA reserved area even if they looks really similar. From my guess, it is caused by some needs on bitmap management. Kvm side wants to maintain bitmap not for 1 page, but for more size. Eventually it use bitmap where one bit represents 64 pages. When I implement CMA related patches, I should change those two places to apply my change and it seem to be painful to me. I want to change this situation and reduce future code management overhead through this patch. This change could also help developer who want to use CMA in their new feature development, since they can use CMA easily without copying pasting this reserved area management code. v2: Although this patchset looks very different with v1, the end result, that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7. Patch 1-5 prepare some features to cover ppc kvm's requirements. Patch 6-7 generalize CMA reserved area management code and change users to use it. Patch 8-10 clean-up minor things. I wanted to test the ppc changes and found that the patch series doesn't apply against v3.15 . Do you have a kernel tree which I can clone to test this series ? -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] PPC, KVM, CMA: use general CMA reserved area management framework
Joonsoo Kim iamjoonsoo@lge.com writes:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Need this. We may want to keep the VM_BUG_ON by moving
KVM_CMA_CHUNK_ORDER around.
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 8056107..1932e0e 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -37,8 +37,6 @@
#include asm/ppc-opcode.h
#include asm/cputable.h
-#include book3s_hv_cma.h
-
/* POWER7 has 10-bit LPIDs, PPC970 has 6-bit LPIDs */
#define MAX_LPID_970 63
@@ -64,7 +62,6 @@ long kvmppc_alloc_hpt(struct kvm *kvm, u32 *htab_orderp)
}
kvm-arch.hpt_cma_alloc = 0;
- VM_BUG_ON(order KVM_CMA_CHUNK_ORDER);
page = kvm_alloc_hpt(1 (order - PAGE_SHIFT));
if (page) {
hpt = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] PPC, KVM, CMA: use general CMA reserved area management framework
Joonsoo Kim iamjoonsoo@lge.com writes:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 7cde8a6..28ec226 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -16,12 +16,14 @@
#include linux/init.h
#include linux/memblock.h
#include linux/sizes.h
+#include linux/cma.h
#include asm/cputable.h
#include asm/kvm_ppc.h
#include asm/kvm_book3s.h
-#include book3s_hv_cma.h
+#define KVM_CMA_CHUNK_ORDER 18
+
/*
* Hash page table alignment on newer cpus(CPU_FTR_ARCH_206)
* should be power of 2.
@@ -43,6 +45,8 @@ static unsigned long kvm_cma_resv_ratio = 5;
unsigned long kvm_rma_pages = (1 27) PAGE_SHIFT; /* 128MB */
EXPORT_SYMBOL_GPL(kvm_rma_pages);
+static struct cma *kvm_cma;
+
/* Work out RMLS (real mode limit selector) field value for a given RMA size.
Assumes POWER7 or PPC970. */
static inline int lpcr_rmls(unsigned long rma_size)
@@ -97,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
- page = kvm_alloc_cma(kvm_rma_pages, kvm_rma_pages);
+ page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(ri-use_count, 1);
@@ -112,7 +116,7 @@ EXPORT_SYMBOL_GPL(kvm_alloc_rma);
void kvm_release_rma(struct kvm_rma_info *ri)
{
if (atomic_dec_and_test(ri-use_count)) {
- kvm_release_cma(pfn_to_page(ri-base_pfn), kvm_rma_pages);
+ cma_release(kvm_cma, pfn_to_page(ri-base_pfn), kvm_rma_pages);
kfree(ri);
}
}
@@ -134,13 +138,13 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
- return kvm_alloc_cma(nr_pages, align_pages);
+ return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
void kvm_release_hpt(struct page *page, unsigned long nr_pages)
{
- kvm_release_cma(page, nr_pages);
+ cma_release(kvm_cma, page, nr_pages);
}
EXPORT_SYMBOL_GPL(kvm_release_hpt);
@@ -179,7 +183,8 @@ void __init kvm_cma_reserve(void)
align_size = HPT_ALIGN_PAGES PAGE_SHIFT;
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
- kvm_cma_declare_contiguous(selected_size, align_size);
+ cma_declare_contiguous(selected_size, 0, 0, align_size,
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
}
}
diff --git a/arch/powerpc/kvm/book3s_hv_cma.c
b/arch/powerpc/kvm/book3s_hv_cma.c
deleted file mode 100644
index d9d3d85..000
--- a/arch/powerpc/kvm/book3s_hv_cma.c
+++ /dev/null
@@ -1,240 +0,0 @@
-/*
- * Contiguous Memory Allocator for ppc KVM hash pagetable based on CMA
- * for DMA mapping framework
- *
- * Copyright IBM Corporation, 2013
- * Author Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License or (at your optional) any later version of the license.
- *
- */
-#define pr_fmt(fmt) kvm_cma: fmt
-
-#ifdef CONFIG_CMA_DEBUG
-#ifndef DEBUG
-# define DEBUG
-#endif
-#endif
-
-#include linux/memblock.h
-#include linux/mutex.h
-#include linux/sizes.h
-#include linux/slab.h
-
-#include book3s_hv_cma.h
-
-struct kvm_cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
-};
-
-static DEFINE_MUTEX(kvm_cma_mutex);
-static struct kvm_cma kvm_cma_area;
-
-/**
- * kvm_cma_declare_contiguous() - reserve area for contiguous memory handling
- * for kvm hash pagetable
- * @size: Size of the reserved memory.
- * @alignment: Alignment for the contiguous memory area
- *
- * This function reserves memory for kvm cma area. It should be
- * called by arch code when early allocator (memblock or bootmem)
- * is still activate.
- */
-long __init kvm_cma_declare_contiguous(phys_addr_t size, phys_addr_t
alignment)
-{
- long base_pfn;
- phys_addr_t addr;
- struct kvm_cma *cma = kvm_cma_area;
-
- pr_debug(%s(size %lx)\n, __func__, (unsigned long)size);
-
- if (!size)
- return -EINVAL;
- /*
- * Sanitise input arguments.
- * We should be pageblock aligned for CMA.
- */
-
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- * alloc_contig_range requires the pfn range
- * specified to be in the same zone. Make this
- * simple by forcing the
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- * alloc_contig_range requires the pfn range
- * specified to be in the same zone. Make this
- * simple by forcing the
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
Joonsoo Kim iamjoonsoo@lge.com writes:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+ return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+ return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+ unsigned long pages)
+{
+ return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
- phys_addr_t alignment,
+ phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+ /* size should be aligned with order_per_bit */
+ BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+ cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
- mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
- unsigned long mask, pfn, pageno, start = 0;
+ unsigned long mask, pfn, start = 0;
+ unsigned long bitmap_maxno, bitmapno, nr_bits;
struct page *page =
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
.
+
+ mask = cma_bitmap_aligned_mask(cma, align);
+ bitmap_maxno = cma_bitmap_maxno(cma);
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ for (;;) {
+ mutex_lock(cma-lock);
+ bitmapno = bitmap_find_next_zero_area(cma-bitmap,
+ bitmap_maxno, start, nr_bits, mask);
+ if (bitmapno = bitmap_maxno) {
+ mutex_unlock(cma-lock);
+ break;
+ }
+ bitmap_set(cma-bitmap, bitmapno, nr_bits);
+ /*
+ * It's safe to drop the lock here. We've marked this region for
+ * our exclusive use. If the migration fails we will take the
+ * lock again and unmark it.
+ */
+ mutex_unlock(cma-lock);
+
+ pfn = cma-base_pfn + (bitmapno cma-order_per_bit);
+ mutex_lock(cma_mutex);
+ ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
+ mutex_unlock(cma_mutex);
+ if (ret == 0) {
+ page = pfn_to_page(pfn);
+ break;
+ } else if (ret != -EBUSY) {
+ clear_cma_bitmap(cma, pfn, count);
+ break;
+ }
+
For setting bit map we do
bitmap_set(cma-bitmap, bitmapno, nr_bits);
alloc_contig()..
if (error)
clear_cma_bitmap(cma, pfn, count);
Why ?
why not bitmap_clear() ?
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] powerpc/kvm: support to handle sw breakpoint
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch mandates use of abs
instruction
(primary opcode 31 and extended opcode 360) as sw breakpoint instruction.
Based on PowerISA v2.01, ABS instruction has been dropped from the architecture
and treated an illegal instruction.
Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s.c| 3 ++-
arch/powerpc/kvm/book3s_hv.c | 23 +++
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index c254c27..b40fe5d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -789,7 +789,8 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- return -EINVAL;
+ vcpu-guest_debug = dbg-control;
+ return 0;
}
void kvmppc_decrementer_func(unsigned long data)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7a12edb..688421d 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -67,6 +67,14 @@
/* Used as a null value for timebase values */
#define TB_NIL (~(u64)0)
+/*
+ * SW_BRK_DBG_INT is debug Instruction for supporting Software Breakpoint.
+ * Instruction mnemonic is ABS, primary opcode is 31 and extended opcode is
360.
+ * Based on PowerISA v2.01, ABS instruction has been dropped from the
architecture
+ * and treated an illegal instruction.
+ */
+#define SW_BRK_DBG_INT 0x7c0002d0
+
static void kvmppc_end_cede(struct kvm_vcpu *vcpu);
static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu);
@@ -721,12 +729,19 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run,
struct kvm_vcpu *vcpu,
break;
/*
* This occurs if the guest executes an illegal instruction.
-* We just generate a program interrupt to the guest, since
-* we don't emulate any guest instructions at this stage.
+* To support software breakpoint, we check for the sw breakpoint
+* instruction to return back to host, if not we just generate a
+* program interrupt to the guest.
*/
case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
- kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
- r = RESUME_GUEST;
+ if (vcpu-arch.last_inst == SW_BRK_DBG_INT) {
+ run-exit_reason = KVM_EXIT_DEBUG;
+ run-debug.arch.address = vcpu-arch.pc;
+ r = RESUME_HOST;
+ } else {
+ kvmppc_core_queue_program(vcpu, 0x8);
+ r = RESUME_GUEST;
+ }
break;
/*
* This occurs if the guest (kernel or userspace), does something that
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
