On Fri, 28 Dec 2012 16:37:33 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
The existing -cpu host code simply set every bit inside svm_features
(initializing it to -1), and that makes it impossible to make the
enforce/check options work properly when the user asks for SVM features
Am 28.12.2012 19:37, schrieb Eduardo Habkost:
The existing -cpu host code simply set every bit inside svm_features
(initializing it to -1), and that makes it impossible to make the
enforce/check options work properly when the user asks for SVM features
explicitly in the command-line.
So,
Am 28.12.2012 19:37, schrieb Eduardo Habkost:
This series has two very similar fixes for feature initizliation for -cpu
host. This should allow us to make the check/enforce code check for host
support of KVM and SVM features, later.
I am out of my field here to verify whether this is
On Fri, 28 Dec 2012 16:37:34 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
When using -cpu host, we don't need to use the kvm_default_features
variable, as the user is explicitly asking QEMU to enable all feature
supported by the host.
This changes the kvm_cpu_fill_host() code to use
On Wed, Jan 02, 2013 at 03:39:03PM +0100, Andreas Färber wrote:
Am 28.12.2012 19:37, schrieb Eduardo Habkost:
The existing -cpu host code simply set every bit inside svm_features
(initializing it to -1), and that makes it impossible to make the
enforce/check options work properly when the
On Wed, Jan 02, 2013 at 03:52:45PM +0100, Igor Mammedov wrote:
On Fri, 28 Dec 2012 16:37:34 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
When using -cpu host, we don't need to use the kvm_default_features
variable, as the user is explicitly asking QEMU to enable all feature
supported
Gleb Natapov g...@redhat.com writes:
The following changes since commit e376a788ae130454ad5e797f60cb70d0308babb6:
Merge remote-tracking branch 'kwolf/for-anthony' into staging (2012-12-13
14:32:28 -0600)
are available in the git repository at:
On Wed, 2 Jan 2013 13:29:10 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
On Wed, Jan 02, 2013 at 03:52:45PM +0100, Igor Mammedov wrote:
On Fri, 28 Dec 2012 16:37:34 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
When using -cpu host, we don't need to use the kvm_default_features
On Wed, Jan 02, 2013 at 09:30:20PM +0100, Igor Mammedov wrote:
On Wed, 2 Jan 2013 13:29:10 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
On Wed, Jan 02, 2013 at 03:52:45PM +0100, Igor Mammedov wrote:
On Fri, 28 Dec 2012 16:37:34 -0200
Eduardo Habkost ehabk...@redhat.com wrote:
Can you describe more details of the test you are performing?
If transparent hugepages are being used then there is the possibility
that there has been no time for khugepaged to back guest memory
with huge pages, in the destination (don't recall the interface for
retrieving number of hugepages
On Mon, Dec 10, 2012 at 03:31:51PM -0600, Jesse Larrew wrote:
Correct a typo in the comment explaining hypercalls.
Signed-off-by: Jesse Larrew jlar...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_para.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
To
I don't think it's related to huge pages...
I was using phoronix-test-suite to run benchmarks. The 'batch/compilation'
group shows the slowdown for all tests, the 'batch/computation' show some
performance degradation, but not nearly as significant.
You could probably easily test this way
On Wed, Jan 02, 2013 at 11:56:11PM +, Mark Petersen wrote:
I don't think it's related to huge pages...
I was using phoronix-test-suite to run benchmarks. The 'batch/compilation'
group shows the slowdown for all tests, the 'batch/computation' show some
performance degradation, but not
I believe I disabled huge pages on the guest and host previously, but I'll test
a few scenarios and look at transparent hugepage usage specifically again over
the next couple days and report back.
Below is a command line used for testing.
/usr/bin/kvm - qemu-x86_64
/usr/bin/kvm -name one-483
14 matches
Mail list logo
