Message ID | 20160808070144.17712-1-stefan@agner.ch (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi, On 08/08/16 08:01, Stefan Agner wrote: > The madvise behavior is not a bit field and hence can not be or'ed. > Also madvise_behavior_valid checks the flag using a case statement > hence only one behavior is supposed to be supplied. Call madvise > twice, once for MERGEABLE and once for HUGEPAGE. thanks for that catch! Indeed we are only setting HUGEPAGE right now, dropping MERGEABLE due to the OR'ing. Acked-by: Andre Przywara <andre.przywara@arm.com> Cheers, Andre. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > arm/kvm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arm/kvm.c b/arm/kvm.c > index ce40897..3cfa90a 100644 > --- a/arm/kvm.c > +++ b/arm/kvm.c > @@ -80,7 +80,10 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size) > SZ_2M); > > madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, > - MADV_MERGEABLE | MADV_HUGEPAGE); > + MADV_MERGEABLE); > + > + madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, > + MADV_HUGEPAGE); > > /* Create the virtual GIC. */ > if (gic__create(kvm, kvm->cfg.arch.irqchip)) > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/08/16 08:01, Stefan Agner wrote: > The madvise behavior is not a bit field and hence can not be or'ed. > Also madvise_behavior_valid checks the flag using a case statement > hence only one behavior is supposed to be supplied. Call madvise > twice, once for MERGEABLE and once for HUGEPAGE. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > arm/kvm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arm/kvm.c b/arm/kvm.c > index ce40897..3cfa90a 100644 > --- a/arm/kvm.c > +++ b/arm/kvm.c > @@ -80,7 +80,10 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size) > SZ_2M); > > madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, > - MADV_MERGEABLE | MADV_HUGEPAGE); > + MADV_MERGEABLE); > + > + madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, > + MADV_HUGEPAGE); Should we also do a MADV_DONTDUMP for guest RAM pages ? This is a security option to strip off any guest data in case of crash in kvmtool. This could also help to reduce the size of the kvmtool core dumps. I think Qemu does this already. Suzuki -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arm/kvm.c b/arm/kvm.c index ce40897..3cfa90a 100644 --- a/arm/kvm.c +++ b/arm/kvm.c @@ -80,7 +80,10 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size) SZ_2M); madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, - MADV_MERGEABLE | MADV_HUGEPAGE); + MADV_MERGEABLE); + + madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size, + MADV_HUGEPAGE); /* Create the virtual GIC. */ if (gic__create(kvm, kvm->cfg.arch.irqchip))
The madvise behavior is not a bit field and hence can not be or'ed. Also madvise_behavior_valid checks the flag using a case statement hence only one behavior is supposed to be supplied. Call madvise twice, once for MERGEABLE and once for HUGEPAGE. Signed-off-by: Stefan Agner <stefan@agner.ch> --- arm/kvm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)