On Wed, Aug 10, 2011 at 12:01:04PM +0300, Avi Kivity wrote:
On 08/10/2011 08:10 AM, David Gibson wrote:
On Mon, Aug 08, 2011 at 11:24:09AM +0300, Avi Kivity wrote:
On 08/08/2011 09:03 AM, David Gibson wrote:
[snip]
This would seem to be a genuine bug in the hugepage code, which has
just
On 08/10/2011 08:10 AM, David Gibson wrote:
On Mon, Aug 08, 2011 at 11:24:09AM +0300, Avi Kivity wrote:
On 08/08/2011 09:03 AM, David Gibson wrote:
Second, if userspace qemu passing hugepages to kvm can cause (host)
kernel memory corruption, that is clearly a host kernel bug. So am I
On Mon, Aug 08, 2011 at 11:24:09AM +0300, Avi Kivity wrote:
On 08/08/2011 09:03 AM, David Gibson wrote:
Second, if userspace qemu passing hugepages to kvm can cause (host)
kernel memory corruption, that is clearly a host kernel bug. So am I
correct in thinking this is basically just a safety
On Fri, Aug 05, 2011 at 12:30:53PM -0300, Marcelo Tosatti wrote:
On Fri, Aug 05, 2011 at 08:16:42AM +0200, Jan Kiszka wrote:
On 2011-08-05 06:02, David Gibson wrote:
At present, an explicit test disallows use of -mem-path when kvm is
enabled
but KVM_CAP_SYNC_MMU is not set. In
On 08/08/2011 09:03 AM, David Gibson wrote:
Second, if userspace qemu passing hugepages to kvm can cause (host)
kernel memory corruption, that is clearly a host kernel bug. So am I
correct in thinking this is basically just a safety feature if qemu is
run on a buggy kernel.
Seems so, yes.
On 2011-08-05 06:02, David Gibson wrote:
At present, an explicit test disallows use of -mem-path when kvm is enabled
but KVM_CAP_SYNC_MMU is not set. In particular, this prevents the user
from using hugetlbfs to back the guest memory.
I can see no reason for this check, and when I asked
On Fri, Aug 05, 2011 at 08:16:42AM +0200, Jan Kiszka wrote:
On 2011-08-05 06:02, David Gibson wrote:
At present, an explicit test disallows use of -mem-path when kvm is enabled
but KVM_CAP_SYNC_MMU is not set. In particular, this prevents the user
from using hugetlbfs to back the guest
