[no subject]
subscribe kvm-commits -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/kvm/book3s_hv_builtin.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c index b9615ba5b083..4fdc27c80f4c 100644 --- a/arch/powerpc/kvm/book3s_hv_builtin.c +++ b/arch/powerpc/kvm/book3s_hv_builtin.c @@ -163,6 +163,12 @@ void __init kvm_cma_reserve(void) unsigned long align_size; struct memblock_region *reg; phys_addr_t selected_size = 0; + + /* +* We need CMA reservation only when we are in HV mode +*/ + if (!cpu_has_feature(CPU_FTR_HVMODE)) + return; /* * We cannot use memblock_phys_mem_size() here, because * memblock_analyze() has not been called yet. -- 1.9.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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Alex -- 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: reduce networking latency
On Wed, Sep 24, 2014 at 02:40:53PM -0400, David Xu wrote: Hi Michael, I found this interesting project from KVM TODO website: allow handling short packets from softirq or VCPU context Plan: We are going through the scheduler 3 times (could be up to 5 if softirqd is involved) Consider RX: host irq - io thread - VCPU thread - guest irq - guest thread. This adds a lot of latency. We can cut it by some 1.5x if we do a bit of work either in the VCPU or softirq context. Testing: netperf TCP RR - should be improved drastically netperf TCP STREAM guest to host - no regression Would you mind saying more about the work either in the vCPU or softirq context? For TX, we might be able to execute it directly from VCPU context. For RX, from softirq context. Why it is only for short packets handling? That's just one idea to avoid doing too much work like this. Doing too much work in VCPU context would break pipelining, likely degrading stream performance. Work in softirq context is not accounted against the correct cgroups, doing a lot of work there will mean guest can steal CPU from other guests. Thanks a lot! Regards, Cong -- 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
[no subject]
subscribe kvm -- 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: [PATCHv7 07/26] driver core: amba: add device binding path 'driver_override'
On Fri, Sep 26, 2014 at 5:37 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Sep 23, 2014 at 04:46:06PM +0200, Antonios Motakis wrote:
As already demonstrated with PCI [1] and the platform bus [2], a
driver_override property in sysfs can be used to bypass the id matching
of a device to a AMBA driver. This can be used by VFIO to bind to any AMBA
device requested by the user.
[1]
http://lists-archives.com/linux-kernel/28030441-pci-introduce-new-device-binding-path-using-pci_dev-driver_override.html
[2] https://www.redhat.com/archives/libvir-list/2014-April/msg00382.html
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
I have to ask why this is even needed in the first place. To take the
example in [2], what's wrong with:
echo fff51000.ethernet
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet /sys/bus/platform/drivers/vfio-platform/bind
and similar for AMBA.
All we would need to do is to introduce a way of having a driver accept
explicit bind requests.
I don't have strong feelings on whether it should be done one way or
the other, however the approach proposed here is identical to the one
already accepted in mainline for PCI and platform devices. Should we
do something different for AMBA?
In any case:
+static ssize_t driver_override_store(struct device *_dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct amba_device *dev = to_amba_device(_dev);
+ char *driver_override, *old = dev-driver_override, *cp;
+
+ if (count PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ cp = strchr(driver_override, '\n');
+ if (cp)
+ *cp = '\0';
I hope that is not replicated everywhere. This allows up to a page to be
allocated, even when the first byte may be a newline. This is wasteful.
How about:
if (count PATH_MAX)
return -EINVAL;
cp = strnchr(buf, count, '\n');
if (cp)
count = cp - buf - 1;
if (count) {
driver_override = kstrndup(buf, count, GFP_KERNEL);
if (!driver_override)
return -ENOMEM;
} else {
driver_override = NULL;
}
kfree(dev-driver_override);
dev-driver_override = driver_override;
Ack.
Also:
+static ssize_t driver_override_show(struct device *_dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct amba_device *dev = to_amba_device(_dev);
+
+ return sprintf(buf, %s\n, dev-driver_override);
+}
Do we really want to do a NULL pointer dereference here?
I'll add a check here.
Thanks
--
Antonios Motakis
Virtual Open Systems
--
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: [PATCHv7 10/26] vfio: platform: probe to devices on the platform bus
On Fri, Sep 26, 2014 at 10:18 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2014-09-26 at 17:30 +0200, Antonios Motakis wrote:
On Wed, Sep 24, 2014 at 1:01 AM, Alex Williamson
alex.william...@redhat.com wrote:
On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/platform/vfio_platform.c | 96
+++
include/uapi/linux/vfio.h | 1 +
2 files changed, 97 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_platform.c
diff --git a/drivers/vfio/platform/vfio_platform.c
b/drivers/vfio/platform/vfio_platform.c
new file mode 100644
index 000..024c026
--- /dev/null
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis a.mota...@virtualopensystems.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/device.h
+#include linux/eventfd.h
+#include linux/interrupt.h
+#include linux/iommu.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/notifier.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/uaccess.h
+#include linux/vfio.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/irq.h
+
+#include vfio_platform_private.h
+
+#define DRIVER_VERSION 0.7
+#define DRIVER_AUTHOR Antonios Motakis
a.mota...@virtualopensystems.com
+#define DRIVER_DESC VFIO for platform devices - User Level
meta-driver
+
+/* probing devices from the linux platform bus */
+
+static struct resource *get_platform_resource(struct
vfio_platform_device *vdev,
+ int i)
+{
+ struct platform_device *pdev = (struct platform_device *)
vdev-opaque;
+
+ return platform_get_resource(pdev, IORESOURCE_MEM, i);
ARM may only support IORESOURCE_MEM, but I don't think platform devices
are limited to MMIO, right? vfio-platform shouldn't be either.
Indeed. Should we however implement this lacking a target to verify it
is working correctly?
Leaving it out would mean PIO resources for those devices would not be
exposed before an update to VFIO, but we wouldn't have to break
backward compatibility I think.
Would you prefer to have it implemented regardless?
I think we need to have PIO figured out at least enough to have stubbed
read/write handlers that could be filled in by someone with test
hardware. I'm not sure I fully understand how a user associates a
region index to a device tree description, whether it's ordering or
something more complicated, so I'm not sure if simply listing all the
PIO resources after the MMIO resources is sufficient and compatible.
Maybe you have some thoughts on that. Thanks,
You are right. I'm not aware if the Linux calls used are guaranteed to
preserve ordering of PIO/MMIO resources, I will investigate a bit on
that.
Alex
+}
+
+static int get_platform_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct platform_device *pdev = (struct platform_device *)
vdev-opaque;
+
+ return platform_get_irq(pdev, i);
+}
+
+
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev-opaque = (void *) pdev;
+ vdev-name = pdev-name;
+ vdev-flags = VFIO_DEVICE_FLAGS_PLATFORM;
+ vdev-get_resource = get_platform_resource;
+ vdev-get_irq = get_platform_irq;
+
+ ret = vfio_platform_probe_common(vdev, pdev-dev);
+ if (ret)
+ kfree(vdev);
+
+ return ret;
+}
+
+static int vfio_platform_remove(struct platform_device *pdev)
+{
+ return vfio_platform_remove_common(pdev-dev);
+}
+
+static struct platform_driver vfio_platform_driver = {
+ .probe = vfio_platform_probe,
+ .remove = vfio_platform_remove,
+ .driver = {
+ .name = vfio-platform,
+ .owner = THIS_MODULE,
+ },
+};
+
Re: [PATCHv7 06/26] vfio/iommu_type1: implement the VFIO_DMA_MAP_FLAG_NOEXEC flag
On Fri, Sep 26, 2014 at 10:27 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2014-09-26 at 17:39 +0200, Antonios Motakis wrote:
On Wed, Sep 24, 2014 at 12:40 AM, Alex Williamson
alex.william...@redhat.com wrote:
On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
Some IOMMU drivers, such as the ARM SMMU driver, make available the
IOMMU_NOEXEC flag, to set the page tables for a device as XN (execute
never).
This affects devices such as the ARM PL330 DMA Controller, which respects
this flag and will refuse to fetch DMA instructions from memory where the
XN flag has been set.
The flag can be used only if all IOMMU domains behind the container
support
the IOMMU_NOEXEC flag. Also, if any mappings are created with the flag,
any
new domains with devices will have to support it as well.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/vfio_iommu_type1.c | 38
+-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c
b/drivers/vfio/vfio_iommu_type1.c
index 0734fbe..09e5064 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -81,6 +81,26 @@ struct vfio_group {
};
/*
+ * This function returns true only if _all_ domains support the
capability.
+ */
+static int vfio_all_domains_have_iommu_noexec(struct vfio_iommu *iommu)
Rename to vfio_domains_have_iommu_noexec() for consistency with the
cache version.
The logic here is a slightly different logic between the two. For
IOMMU_CACHE we generally check if any domain includes it,
Not true, all the domains must support IOMMU_CACHE for the function to
return 1. In fact, the code is so identical that if we were to cache
IOMMU_CAP_NOEXEC into domain-prot, we should probably only have one
function:
static int vfio_domains_have_iommu_flag(struct vfio_iommu *iommu, int flag);
You are absolutely correct, I managed to confuse myself when switching
from vfio_domains_have_iommu_exec to vfio_domains_have_iommu_noexec.
I will implement the shared function.
for NOEXEC
in contract we need all domains to support it, otherwise we can't
expose the capability. Hence the _all_ addition in the name of the
function.
+{
+ struct vfio_domain *d;
+ int ret = 1;
+
+ mutex_lock(iommu-lock);
+ list_for_each_entry(d, iommu-domain_list, next) {
+ if (!iommu_domain_has_cap(d-domain, IOMMU_CAP_NOEXEC)) {
Should we cache this in domain-prot like we do for IOMMU_CACHE?
+ ret = 0;
+ break;
+ }
+ }
+ mutex_unlock(iommu-lock);
+
+ return ret;
+}
+
+/*
* This code handles mapping and unmapping of user data buffers
* into DMA'ble space using the IOMMU
*/
@@ -546,6 +566,11 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
prot |= IOMMU_WRITE;
if (map-flags VFIO_DMA_MAP_FLAG_READ)
prot |= IOMMU_READ;
+ if (map-flags VFIO_DMA_MAP_FLAG_NOEXEC) {
+ if (!vfio_all_domains_have_iommu_noexec(iommu))
+ return -EINVAL;
+ prot |= IOMMU_NOEXEC;
+ }
if (!prot || !size || (size | iova | vaddr) mask)
return -EINVAL;
@@ -636,6 +661,12 @@ static int vfio_iommu_replay(struct vfio_iommu
*iommu,
dma = rb_entry(n, struct vfio_dma, node);
iova = dma-iova;
+ /* if any of the mappings to be replayed has the NOEXEC flag
+ * set, then the new iommu domain must support it */
nit, please fix the comment style to match the rest of the file.
Ack
+ if ((dma-prot | IOMMU_NOEXEC)
+ !iommu_domain_has_cap(domain-domain, IOMMU_CAP_NOEXEC))
+ return -EINVAL;
+
while (iova dma-iova + dma-size) {
phys_addr_t phys = iommu_iova_to_phys(d-domain,
iova);
size_t size;
@@ -890,6 +921,10 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
if (!iommu)
return 0;
return vfio_domains_have_iommu_cache(iommu);
+ case VFIO_IOMMU_PROT_NOEXEC:
+ if (!iommu)
+ return 0;
+ return vfio_all_domains_have_iommu_noexec(iommu);
default:
return 0;
}
@@ -913,7 +948,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
} else if (cmd == VFIO_IOMMU_MAP_DMA) {
struct vfio_iommu_type1_dma_map map;
uint32_t mask = VFIO_DMA_MAP_FLAG_READ |
- VFIO_DMA_MAP_FLAG_WRITE;
+ VFIO_DMA_MAP_FLAG_WRITE |
+
Re: [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Paolo -- 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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
On 29.09.14 13:48, Paolo Bonzini wrote: Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Yes, can you please directly apply it with my SoB (or Reviewed-by if you prefer)? Alex -- 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] KVM call for agenda for 2014-09-30
On 28/09/2014 18:33, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. Call details: 15:00 CEST 13:00 UTC 09:00 EDT Every two weeks By popular demand, a google calendar public entry with it https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ (Let me know if you have any problems with the calendar entry) If you need phone number details, contact me privately Thanks, Juan. Hi Juan, All, We wanted to add two topics.. The first about reverse execution: Paolo suggested we have a talk about this before the KVM forum including Pavel to compair both approaches. The second is about TCG multi thread implementation in QEMU. Thanks, Fred -- 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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
Il 29/09/2014 13:57, Alexander Graf ha scritto: On 29.09.14 13:48, Paolo Bonzini wrote: Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Yes, can you please directly apply it with my SoB (or Reviewed-by if you prefer)? Ok, will do. Paolo -- 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 v11 2/6] KVM: Add generic implementation of kvm_vm_ioctl_get_dirty_log
On Mon, Sep 22, 2014 at 05:54:46PM -0700, Mario Smarduch wrote: Add support for generic implementation of dirty log read function. For now x86_64 and ARMv7 share generic dirty log read. Other architectures call their architecture specific functions. Signed-off-by: Mario Smarduch m.smard...@samsung.com --- This looks reasonable to me, Other arch kvm-maintainers: will you give this a look and a spin for your ok? Thanks, -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: [PATCH v11 6/6] arm: KVM: ARMv7 dirty page logging 2nd stage page fault
On Mon, Sep 22, 2014 at 05:54:50PM -0700, Mario Smarduch wrote: This patch adds support for handling 2nd stage page faults during migration, it disables faulting in huge pages, and dissolves huge pages to page tables. In case migration is canceled huge pages may be used again. Signed-off-by: Mario Smarduch m.smard...@samsung.com It seems here and in a bunch of the other patches you didn't apply my Reviewed-by tags. Did you change the patches in other ways than addressed by the review comments? Thanks, -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: [PATCH v4 2/4] kvmtool: ARM64: Add target type potenza for aarch64
On 19/09/14 00:57, Anup Patel wrote:
The VCPU target type KVM_ARM_TARGET_XGENE_POTENZA is available
in latest Linux-3.16-rcX or higher hence register aarch64 target
type for it.
This patch enables us to run KVMTOOL on X-Gene Potenza host.
I still don't like the addition of another CPU, but for the sake of
running older kernels (which seems to have a use-case in your case) I am
OK with this.
Maybe it's worth adding a comment which states that this list is
closed and just provided to support older kernels?
So that other SoCs don't get funny ideas... ;-)
Cheers,
Andre.
Signed-off-by: Pranavkumar Sawargaonkar pranavku...@linaro.org
Signed-off-by: Anup Patel anup.pa...@linaro.org
---
tools/kvm/arm/aarch64/arm-cpu.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/arm/aarch64/arm-cpu.c b/tools/kvm/arm/aarch64/arm-cpu.c
index 9ee3da3..51a1e2f 100644
--- a/tools/kvm/arm/aarch64/arm-cpu.c
+++ b/tools/kvm/arm/aarch64/arm-cpu.c
@@ -46,11 +46,18 @@ static struct kvm_arm_target target_cortex_a57 = {
.init = arm_cpu__vcpu_init,
};
+static struct kvm_arm_target target_potenza = {
+ .id = KVM_ARM_TARGET_XGENE_POTENZA,
+ .compatible = arm,arm-v8,
+ .init = arm_cpu__vcpu_init,
+};
+
static int arm_cpu__core_init(struct kvm *kvm)
{
return (kvm_cpu__register_kvm_arm_target(target_generic_v8) ||
kvm_cpu__register_kvm_arm_target(target_aem_v8) ||
kvm_cpu__register_kvm_arm_target(target_foundation_v8) ||
- kvm_cpu__register_kvm_arm_target(target_cortex_a57));
+ kvm_cpu__register_kvm_arm_target(target_cortex_a57) ||
+ kvm_cpu__register_kvm_arm_target(target_potenza));
}
core_init(arm_cpu__core_init);
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
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 v11 2/6] KVM: Add generic implementation of kvm_vm_ioctl_get_dirty_log
On Mon, 22 Sep 2014 17:54:46 -0700 Mario Smarduch m.smard...@samsung.com wrote: Add support for generic implementation of dirty log read function. For now x86_64 and ARMv7 share generic dirty log read. Other architectures call their architecture specific functions. Signed-off-by: Mario Smarduch m.smard...@samsung.com This (and the previous patch), once fitted on current kvm/next (trivial rejects), seems to work fine on s390 and looks sane to me. So, for the s390 parts: Acked-by: Cornelia Huck cornelia.h...@de.ibm.com -- 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 v11 2/6] KVM: Add generic implementation of kvm_vm_ioctl_get_dirty_log
On 09/29/2014 10:18 AM, Cornelia Huck wrote: On Mon, 22 Sep 2014 17:54:46 -0700 Mario Smarduch m.smard...@samsung.com wrote: Add support for generic implementation of dirty log read function. For now x86_64 and ARMv7 share generic dirty log read. Other architectures call their architecture specific functions. Signed-off-by: Mario Smarduch m.smard...@samsung.com This (and the previous patch), once fitted on current kvm/next (trivial rejects), seems to work fine on s390 and looks sane to me. So, for the s390 parts: Acked-by: Cornelia Huck cornelia.h...@de.ibm.com Thanks, Mario -- 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
[PATCH] KVM: x86: x2apic broadcast with physical mode does not work
KVM does not deliver x2APIC broadcast messages with physical mode. Intel SDM
(10.12.9 ICR Operation in x2APIC Mode) states: A destination ID value of
_H is used for broadcast of interrupts in both logical destination and
physical destination modes.
The fix tries to combine broadcast in different modes. Broadcast can be done
in the fast-path if the delivery-mode is logical and there is only a single
cluster. Otherwise, do it slowly.
Signed-off-by: Nadav Amit na...@cs.technion.ac.il
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/lapic.c| 22 --
arch/x86/kvm/lapic.h| 4 ++--
virt/kvm/ioapic.h | 2 +-
4 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7d603a7..6f2be83 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -542,7 +542,7 @@ struct kvm_apic_map {
struct rcu_head rcu;
u8 ldr_bits;
/* fields bellow are used to decode ldr values in different modes */
- u32 cid_shift, cid_mask, lid_mask;
+ u32 cid_shift, cid_mask, lid_mask, broadcast;
struct kvm_lapic *phys_map[256];
/* first index is cluster id second is cpu id in a cluster */
struct kvm_lapic *logical_map[16][16];
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index b8345dd..16404cd 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -149,6 +149,7 @@ static void recalculate_apic_map(struct kvm *kvm)
new-cid_shift = 8;
new-cid_mask = 0;
new-lid_mask = 0xff;
+ new-broadcast = 0xff;
kvm_for_each_vcpu(i, vcpu, kvm) {
struct kvm_lapic *apic = vcpu-arch.apic;
@@ -170,6 +171,7 @@ static void recalculate_apic_map(struct kvm *kvm)
new-cid_shift = 16;
new-cid_mask = (1 KVM_X2APIC_CID_BITS) - 1;
new-lid_mask = 0x;
+ new-broadcast = (u32)-1;
} else if (kvm_apic_sw_enabled(apic)
!new-cid_mask /* flat mode */
kvm_apic_get_reg(apic, APIC_DFR) ==
APIC_DFR_CLUSTER) {
@@ -558,17 +560,21 @@ static void apic_set_tpr(struct kvm_lapic *apic, u32 tpr)
apic_update_ppr(apic);
}
-int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest)
+int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u32 dest)
{
- return dest == 0xff || kvm_apic_id(apic) == dest;
+ u32 broadcast = apic_x2apic_mode(apic) ? (u32)-1 : 0xff;
+
+ return (dest == broadcast || kvm_apic_id(apic) == dest);
}
-int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda)
+int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u32 mda)
{
int result = 0;
u32 logical_id;
if (apic_x2apic_mode(apic)) {
+ if (mda == (u32)-1)
+ return 1; /* x2apic broadcast */
logical_id = kvm_apic_get_reg(apic, APIC_LDR);
return logical_id mda;
}
@@ -595,7 +601,7 @@ int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8
mda)
}
int kvm_apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
- int short_hand, int dest, int dest_mode)
+ int short_hand, unsigned int dest, int dest_mode)
{
int result = 0;
struct kvm_lapic *target = vcpu-arch.apic;
@@ -657,9 +663,13 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct
kvm_lapic *src,
if (!map)
goto out;
+ /* broadcast on physical or multiple clusters is done slowly */
+ if (irq-dest_id == map-broadcast
+ (irq-dest_mode == 0 || map-cid_mask != 0))
+ goto out;
+
if (irq-dest_mode == 0) { /* physical mode */
- if (irq-delivery_mode == APIC_DM_LOWEST ||
- irq-dest_id == 0xff)
+ if (irq-delivery_mode == APIC_DM_LOWEST)
goto out;
dst = map-phys_map[irq-dest_id 0xff];
} else {
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 6a11845..3fd6c22 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -55,8 +55,8 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu);
void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr);
void kvm_apic_update_irr(struct kvm_vcpu *vcpu, u32 *pir);
-int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest);
-int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda);
+int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u32 dest);
+int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u32 mda);
int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_lapic_irq *irq,
unsigned long *dest_map);
int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type);
diff --git
[PATCH kvm-unit-tests] x86: Test physical x2apic broadcast ICR
Previously KVM did not deliver x2apic broadcast IPI (dest-id==0x) with
physical delivery mode. This test checks the fix.
Signed-off-by: Nadav Amit na...@cs.technion.ac.il
---
x86/apic.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/x86/apic.c b/x86/apic.c
index 2619d85..373f6e0 100644
--- a/x86/apic.c
+++ b/x86/apic.c
@@ -372,6 +372,24 @@ static void test_multiple_nmi(void)
report(multiple nmi, ok);
}
+static void test_x2apic_broadcast(void)
+{
+ int i = 0;
+ u32 old_received = nmi_received;
+
+ if (!enable_x2apic())
+ return;
+
+ handle_irq(2, multiple_nmi_handler);
+
+ apic_icr_write(APIC_DEST_PHYSICAL | APIC_DM_NMI | APIC_INT_ASSERT,
+ (u32)-1);
+ while (nmi_received == old_received i++ 1)
+ pause();
+
+ report(x2apic broadcast, nmi_received != old_received);
+}
+
int main()
{
setup_vm();
@@ -392,6 +410,7 @@ int main()
test_multiple_nmi();
test_tsc_deadline_timer();
+test_x2apic_broadcast();
return report_summary();
}
--
1.9.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: FreeBSD Guest Freezes during boot up on Linux KVM, RHEL 6.4 or RHEL 6.5
On Fri, Sep 26, 2014 at 07:31:17AM +, Venkateswara Rao Nandigam wrote: Hi Paolo, As suggested by You, the following is the issue info. Is this something to be fixed in host kernel? Description: FreeBSD 64bit(10.0) Guest freezes at booting on Linux KVM, host running RHEL6.4 or RHEL 6.5. Tested various versions of FreeBSD, Any version of FreeBSD 64bit will freeze the same way. The issue occurs only on RHEL6.4 or RHEL6.5 host, if the Physical CPU has SMEP feature enabled. In these host versions, if the kernel loaded with nosmep boot parameter, cannot find SMEP feature on '/proc/cpuinfo', And FreeBSD guest boots properly. This issue has been fixed in kernel-2.6.32-472.el6. -- 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 v11 6/6] arm: KVM: ARMv7 dirty page logging 2nd stage page fault
On 09/29/2014 06:35 AM, Christoffer Dall wrote: On Mon, Sep 22, 2014 at 05:54:50PM -0700, Mario Smarduch wrote: This patch adds support for handling 2nd stage page faults during migration, it disables faulting in huge pages, and dissolves huge pages to page tables. In case migration is canceled huge pages may be used again. Signed-off-by: Mario Smarduch m.smard...@samsung.com It seems here and in a bunch of the other patches you didn't apply my Reviewed-by tags. Did you change the patches in other ways than addressed by the review comments? Thanks, -Christoffer Christoffer, you comments and Hiabins were applied, no other changes. Overlooked the acks/reviewed :( Thanks, - Mario -- 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
[PATCH] vfio-pci: Fix remove path locking
Locking both the remove() and release() path results in a deadlock
that should have been obvious. To fix this we can get and hold the
vfio_device reference as we evaluate whether to do a bus/slot reset.
This will automatically block any remove() calls, allowing us to
remove the explict lock. Fixes 61d792562b53.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: sta...@vger.kernel.org [3.17]
---
drivers/vfio/pci/vfio_pci.c | 136 ++-
1 file changed, 57 insertions(+), 79 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index f782533..9558da3 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -876,15 +876,11 @@ static void vfio_pci_remove(struct pci_dev *pdev)
{
struct vfio_pci_device *vdev;
- mutex_lock(driver_lock);
-
vdev = vfio_del_group_dev(pdev-dev);
if (vdev) {
iommu_group_put(pdev-dev.iommu_group);
kfree(vdev);
}
-
- mutex_unlock(driver_lock);
}
static pci_ers_result_t vfio_pci_aer_err_detected(struct pci_dev *pdev,
@@ -927,108 +923,90 @@ static struct pci_driver vfio_pci_driver = {
.err_handler= vfio_err_handlers,
};
-/*
- * Test whether a reset is necessary and possible. We mark devices as
- * needs_reset when they are released, but don't have a function-local reset
- * available. If any of these exist in the affected devices, we want to do
- * a bus/slot reset. We also need all of the affected devices to be unused,
- * so we abort if any device has a non-zero refcnt. driver_lock prevents a
- * device from being opened during the scan or unbound from vfio-pci.
- */
-static int vfio_pci_test_bus_reset(struct pci_dev *pdev, void *data)
-{
- bool *needs_reset = data;
- struct pci_driver *pci_drv = ACCESS_ONCE(pdev-driver);
- int ret = -EBUSY;
-
- if (pci_drv == vfio_pci_driver) {
- struct vfio_device *device;
- struct vfio_pci_device *vdev;
-
- device = vfio_device_get_from_dev(pdev-dev);
- if (!device)
- return ret;
-
- vdev = vfio_device_data(device);
- if (vdev) {
- if (vdev-needs_reset)
- *needs_reset = true;
-
- if (!vdev-refcnt)
- ret = 0;
- }
-
- vfio_device_put(device);
- }
-
- /*
-* TODO: vfio-core considers groups to be viable even if some devices
-* are attached to known drivers, like pci-stub or pcieport. We can't
-* freeze devices from being unbound to those drivers like we can
-* here though, so it would be racy to test for them. We also can't
-* use device_lock() to prevent changes as that would interfere with
-* PCI-core taking device_lock during bus reset. For now, we require
-* devices to be bound to vfio-pci to get a bus/slot reset on release.
-*/
-
- return ret;
-}
+struct vfio_devices {
+ struct vfio_device **devices;
+ int cur_index;
+ int max_index;
+};
-/* Clear needs_reset on all affected devices after successful bus/slot reset */
-static int vfio_pci_clear_needs_reset(struct pci_dev *pdev, void *data)
+static int vfio_pci_get_devs(struct pci_dev *pdev, void *data)
{
+ struct vfio_devices *devs = data;
struct pci_driver *pci_drv = ACCESS_ONCE(pdev-driver);
- if (pci_drv == vfio_pci_driver) {
- struct vfio_device *device;
- struct vfio_pci_device *vdev;
+ if (pci_drv != vfio_pci_driver)
+ return -EBUSY;
- device = vfio_device_get_from_dev(pdev-dev);
- if (!device)
- return 0;
+ if (devs-cur_index == devs-max_index)
+ return -ENOSPC;
- vdev = vfio_device_data(device);
- if (vdev)
- vdev-needs_reset = false;
-
- vfio_device_put(device);
- }
+ devs-devices[devs-cur_index] = vfio_device_get_from_dev(pdev-dev);
+ if (!devs-devices[devs-cur_index])
+ return -EINVAL;
+ devs-cur_index++;
return 0;
}
/*
* Attempt to do a bus/slot reset if there are devices affected by a reset for
* this device that are needs_reset and all of the affected devices are unused
- * (!refcnt). Callers of this function are required to hold driver_lock such
- * that devices can not be unbound from vfio-pci or opened by a user while we
- * test for and perform a bus/slot reset.
+ * (!refcnt). Callers are required to hold driver_lock when calling this to
+ * prevent device opens and concurrent bus reset attempts. We prevent device
+ * unbinds by acquiring and holding a reference to the vfio_device.
+ *
+ * NB: vfio-core considers a group to be viable even if some
Re: [RESEND PATCH v3 2/2] vfio/pci: Restore MSIx message prior to enabling
On Sat, 2014-09-27 at 15:43 +1000, Gavin Shan wrote:
The MSIx vector table lives in device memory, which may be cleared as
part of a backdoor device reset. This is the case on the IBM IPR HBA
when the BIST is run on the device. When assigned to a QEMU guest,
the guest driver does a pci_save_state(), issues a BIST, then does a
pci_restore_state(). The BIST clears the MSIx vector table, but due
to the way interrupts are configured the pci_restore_state() does not
restore the vector table as expected. Eventually this results in an
EEH error on Power platforms when the device attempts to signal an
interrupt with the zero'd table entry.
Fix the problem by restoring the host cached MSI message prior to
enabling each vector.
Reported-by: Wen Xiong wenxi...@linux.vnet.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/pci/vfio_pci_intrs.c | 15 +++
1 file changed, 15 insertions(+)
Applied both to linux-vfio.git/next for 3.18. Thanks!
Alex
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 9dd49c9..553212f 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -16,6 +16,7 @@
#include linux/device.h
#include linux/interrupt.h
#include linux/eventfd.h
+#include linux/msi.h
#include linux/pci.h
#include linux/file.h
#include linux/poll.h
@@ -548,6 +549,20 @@ static int vfio_msi_set_vector_signal(struct
vfio_pci_device *vdev,
return PTR_ERR(trigger);
}
+ /*
+ * The MSIx vector table resides in device memory which may be cleared
+ * via backdoor resets. We don't allow direct access to the vector
+ * table so even if a userspace driver attempts to save/restore around
+ * such a reset it would be unsuccessful. To avoid this, restore the
+ * cached value of the message prior to enabling.
+ */
+ if (msix) {
+ struct msi_msg msg;
+
+ get_cached_msi_msg(irq, msg);
+ write_msi_msg(irq, msg);
+ }
+
ret = request_irq(irq, vfio_msihandler, 0,
vdev-ctx[vector].name, trigger);
if (ret) {
--
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] drivers/vfio: Export vfio_spapr_iommu_eeh_ioctl() with GPL
On Sat, 2014-09-27 at 16:04 +1000, Gavin Shan wrote: The function should have been exported with EXPORT_SYMBOL_GPL() as part of commit 92d18a68 (drivers/vfio: Fix EEH build error). Suggested-by: Alexey Kardashevskiy a...@ozlabs.ru Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com --- drivers/vfio/vfio_spapr_eeh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c index 86dfceb..5fa42db 100644 --- a/drivers/vfio/vfio_spapr_eeh.c +++ b/drivers/vfio/vfio_spapr_eeh.c @@ -92,7 +92,7 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group, return ret; } -EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl); +EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl); MODULE_VERSION(DRIVER_VERSION); MODULE_LICENSE(GPL v2); Applied to linux-vfio.git/next for 3.18. Thanks! Alex -- 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] arm/arm64: KVM: Fix set_clear_sgi_pend_reg offset
Hi Christoffer,
On 2014/9/26 21:44, Christoffer Dall wrote:
On Fri, Sep 26, 2014 at 12:16:35PM +0200, Christoffer Dall wrote:
On Fri, Sep 26, 2014 at 05:26:00PM +0800, Shannon Zhao wrote:
On 2014/9/26 16:44, Christoffer Dall wrote:
Hi Shannon,
On Fri, Sep 26, 2014 at 01:57:46PM +0800, Shannon Zhao wrote:
On 2014/9/26 1:49, Christoffer Dall wrote:
The sgi values calculated in read_set_clear_sgi_pend_reg() and
write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
with catastrophic results in that subfunctions ended up overwriting
memory not allocated for the expected purpose.
This showed up as bugs in kfree() and the kernel complaining a lot of
you turn on memory debugging.
This addresses: http://marc.info/?l=kvmm=141164910007868w=2
Reported-by: Shannon Zhao zhaoshengl...@huawei.com
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
virt/kvm/arm/vgic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index b6fab0f..8629678 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -816,7 +816,7 @@ static bool read_set_clear_sgi_pend_reg(struct
kvm_vcpu *vcpu,
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
int sgi;
-int min_sgi = (offset ~0x3) * 4;
+int min_sgi = (offset ~0x3);
int max_sgi = min_sgi + 3;
int vcpu_id = vcpu-vcpu_id;
u32 reg = 0;
@@ -837,7 +837,7 @@ static bool write_set_clear_sgi_pend_reg(struct
kvm_vcpu *vcpu,
{
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
int sgi;
-int min_sgi = (offset ~0x3) * 4;
+int min_sgi = (offset ~0x3);
int max_sgi = min_sgi + 3;
int vcpu_id = vcpu-vcpu_id;
u32 reg;
Hi Christoffer,
I have test this patch for a few hours. The kfree() bug doesn't appear
again.
But I come to another problem as followed.
The test is that start 2 VMs, sleep 10 and do pkill qemu.
qemu-system-aar[1207]: unhandled level 1 permission fault (11) at
0xc01ed6c200, esr 0x920d
pgd = ffc012986000
[c01ed6c200] *pgd=, *pud=
CPU: 1 PID: 1207 Comm: qemu-system-aar Not tainted 3.17.0-rc4+ #1
task: ffc87b072900 ti: ffc0129e task.ti: ffc0129e
PC is at 0x4181a0
LR is at 0x41826c
pc : [004181a0] lr : [0041826c] pstate: 8000
sp : 007fcd38ace0
x29: 007fcd38ace0 x28:
x27: x26:
x25: x24:
x23: x22:
x21: x20:
x19: 007fcd38b070 x18: 007fcd38ab10
x17: 007f9bb14480 x16: 009f2370
x15: x14:
x13: x12: 0268
x11: 115e5520 x10: 0101010101010101
x9 : 0004 x8 : 00ac7a78
x7 : x6 : 003f
x5 : 0040 x4 :
x3 : 0030 x2 : 0001
x1 : ffc01ed6c200 x0 : ffc01ed6c200
Hmmm, I just ran a similar loop with a number of tests in the VM for a
few hours and I didn't see this error.
Yeah, it really need to run longer.
After running about one hour this problem first appears and after running
about 4 hours it second appears.
In any case, this patch should still be merged, but we should try to
reproduce your setup.
Your patch really solves the kfree() bug. I'll add tested-by line.
What is your command line, exact QEMU version, the file system you use,
and the guest kernel you are running?
My test script is as followed. QEMU version is v2.1.0 release.
The fs is linaro-image-lamp-genericarmv8-20140727-701.rootfs.tar.gz.
Host kernel is based on marc's branch kvmtool-vgic-dyn with your patch
Fix set_clear_sgi_pend_reg offset.
Guest kernel is 3.16 release.
while true
do
qemu-system-aarch64 \
-enable-kvm -smp 4 \
-kernel Image \
-m 512 -machine virt,kernel_irqchip=on \
-initrd guestfs.cpio.gz \
-cpu host \
-chardev pty,id=pty0,mux=on -monitor chardev:pty0 \
-serial chardev:pty0 -daemonize \
-vnc 0.0.0.0:0 \
-append rdinit=/sbin/init console=ttyAMA0 mem=512M root=/dev/ram
earlyprintk=pl011,0x900 rw
qemu-system-aarch64 \
-enable-kvm -smp 4 \
-kernel Image \
-m 512 -machine virt,kernel_irqchip=on \
-initrd guestfs.cpio.gz \
-cpu host \
-chardev pty,id=pty0,mux=on -monitor chardev:pty0 \
-serial chardev:pty0 -daemonize \
-vnc 0.0.0.0:1 \
-append rdinit=/sbin/init console=ttyAMA0 mem=512M root=/dev/ram
earlyprintk=pl011,0x900 rw
sleep 5
pkill qemu
ok, I'll try to reproduce.
With kvmarm/queue as both host and guest and otherwise not using vnc but
nographic and a serial output, I've now been running this for 5 hours
straight without any issues. That's 1131
Re: [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Alex -- 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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Paolo -- 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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
On 29.09.14 13:48, Paolo Bonzini wrote: Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Yes, can you please directly apply it with my SoB (or Reviewed-by if you prefer)? Alex -- 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] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
Il 29/09/2014 13:57, Alexander Graf ha scritto: On 29.09.14 13:48, Paolo Bonzini wrote: Il 29/09/2014 10:28, Alexander Graf ha scritto: On 29.09.14 10:02, Aneesh Kumar K.V wrote: We use cma reserved area for creating guest hash page table. Don't do the reservation in non-hypervisor mode. This avoids unnecessary CMA reservation when booting with limited memory configs like fadump and kdump. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Would you like this in 3.18? Yes, can you please directly apply it with my SoB (or Reviewed-by if you prefer)? Ok, will do. Paolo -- 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
