On Centos 6.4 x64,with libvirt-0.10.2-18.el6.x86_64 i am trying to
set memory.limit_in_bytes for all qemu process.
changed cgconfig.conf
group mygroup{
perm {
admin {
uid = root;
gid = root;
}
On 14/12/14 14:14, Christoffer Dall wrote:
On Sun, Dec 14, 2014 at 11:33:04AM +, Marc Zyngier wrote:
On Sat, Dec 13 2014 at 11:17:29 AM, Christoffer Dall
christoffer.d...@linaro.org wrote:
It is curently possible to run a VM with architected timers support
without creating an in-kernel
On 15/12/2014 02:52, Zhang Haoyu wrote:
Yes, I find it,
but what's the relationship between
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=next
This is branch next.
and
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/ ?
This is branch master.
Paolo
--
To unsubscribe from this
Hi Paolo, Yang
What's the status of this problem?
Thanks,
Zhang Haoyu
On 2014-12-04 00:13:49, Paolo Bonzini wrote:
On 28/11/2014 12:59, Zhang, Yang Z wrote:
According the feedback from Haoyu on my test patch which skipping the
interrupt injection if irq line is active (See another thread),
On 15/12/2014 10:39, Zhang Haoyu wrote:
Hi Paolo, Yang
What's the status of this problem?
I will look at Yang's patch after the end of the merge window.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
On 15/12/2014 01:09, Samuel Thibault wrote:
Hello,
Just FTR, it seems that the overhead is due to gnumach somtimes using
the PIC quite a lot. It used not to be too much a concern with just
kvm, but kvm on kvm becomes too expensive for that. I've fixed gnumach
into being a lot more
It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.
To address this issue, move the architected timers initialization to the
time when we run a VCPU for the first time, and
On 15/12/14 10:20, Christoffer Dall wrote:
It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.
To address this issue, move the architected timers initialization to the
On 12/12/2014 12:06 PM, Christoffer Dall wrote:
On Thu, Dec 11, 2014 at 01:38:16PM +0100, Eric Auger wrote:
On 12/11/2014 01:01 PM, Christoffer Dall wrote:
On Wed, Dec 10, 2014 at 01:45:50PM +0100, Eric Auger wrote:
On 12/09/2014 04:44 PM, Christoffer Dall wrote:
Userspace assumes that it can
On Mon, Dec 15, 2014 at 10:39:23AM +, Marc Zyngier wrote:
On 15/12/14 10:20, Christoffer Dall wrote:
It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.
To
Hi Paolo,
Here's the second pull request for KVM for arm/arm64 for v3.19, which fixes
reboot problems, clarifies VCPU init, and fixes a regression concerning the
VGIC init flow.
The diffstat includes the previous pull request's patches, because the
previous pull request is not in kvm/next yet I
When the vgic initializes its internal state it does so based on the
number of VCPUs available at the time. If we allow KVM to create more
VCPUs after the VGIC has been initialized, we are likely to error out in
unfortunate ways later, perform buffer overflows etc.
Acked-by: Marc Zyngier
Userspace assumes that it can wire up IRQ injections after having
created all VCPUs and after having created the VGIC, but potentially
before starting the first VCPU. This can currently lead to lost IRQs
because the state of that IRQ injection is not stored anywhere and we
don't return an error
Some code paths will need to check to see if the internal state of the
vgic has been initialized (such as when creating new VCPUs), so
introduce such a macro that checks the nr_cpus field which is set when
the vgic has been initialized.
Also set nr_cpus = 0 in kvm_vgic_destroy, because the error
If a VCPU was originally started with power off (typically to be brought
up by PSCI in SMP configurations), there is no need to clear the
POWER_OFF flag in the kernel, as this flag is only tested during the
init ioctl itself.
Acked-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Christoffer
The implementation of KVM_ARM_VCPU_INIT is currently not doing what
userspace expects, namely making sure that a vcpu which may have been
turned off using PSCI is returned to its initial state, which would be
powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag.
Implement the
It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.
To address this issue, move the architected timers initialization to the
time when we run a VCPU for the first time, and
Introduce a new function to unmap user RAM regions in the stage2 page
tables. This is needed on reboot (or when the guest turns off the MMU)
to ensure we fault in pages again and make the dcache, RAM, and icache
coherent.
Using unmap_stage2_range for the whole guest physical range does not
work,
When a vcpu calls SYSTEM_OFF or SYSTEM_RESET with PSCI v0.2, the vcpus
should really be turned off for the VM adhering to the suggestions in
the PSCI spec, and it's the sane thing to do.
Also, clarify the behavior and expectations for exits to user space with
the KVM_EXIT_SYSTEM_EVENT case.
It is not clear that this ioctl can be called multiple times for a given
vcpu. Userspace already does this, so clarify the ABI.
Also specify that userspace is expected to always make secondary and
subsequent calls to the ioctl with the same parameters for the VCPU as
the initial call (which
When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also
reset the HCR, because we now modify the HCR dynamically to
enable/disable trapping of guest accesses to the VM registers.
This is crucial for reboot of VMs working since otherwise we will not be
doing the necessary cache
From: Peter Maydell peter.mayd...@linaro.org
VGIC initialization currently happens in three phases:
(1) kvm_vgic_create() (triggered by userspace GIC creation)
(2) vgic_init_maps() (triggered by userspace GIC register read/write
requests, or from kvm_vgic_init() if not already run)
(3)
The vgic_initialized() macro currently returns the state of the
vgic-ready flag, which indicates if the vgic is ready to be used when
running a VM, not specifically if its internal state has been
initialized.
Rename the macro accordingly in preparation for a more nuanced
initialization flow.
Hello Luis,
On 09/12/14 23:35, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available
On 15/12/2014 12:41, Christoffer Dall wrote:
Hi Paolo,
Here's the second pull request for KVM for arm/arm64 for v3.19, which fixes
reboot problems, clarifies VCPU init, and fixes a regression concerning the
VGIC init flow.
The diffstat includes the previous pull request's patches,
On 14/12/2014 02:17, Eugene Korenevsky wrote:
Hi there,
Please DO NOT take v3 version of patchset in account. It contains bug
(missing check for MSR load/store area size in
`nested_vmx_check_msr_switch`). This bug has been fixed in v4 version
of patchset.
The diff is just
diff --git
The diff is just
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d6fe958a0403..09ccf6c09435 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8305,6 +8305,8 @@ static int nested_vmx_check_msr_switch(struct kvm_vcpu
*vcpu,
WARN_ON(1);
On 15/12/2014 14:59, Eugene Korenevsky wrote:
The diff is just
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d6fe958a0403..09ccf6c09435 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8305,6 +8305,8 @@ static int nested_vmx_check_msr_switch(struct kvm_vcpu
On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to
On 12/12/2014 20:54, Eugene Korenevsky wrote:
Remove unused variable to get rid of compiler warning.
And remove commented out code (it can always be restored
from git logs).
This is also specifying that the behavior is incorrect. It should be
changed to an XFAIL instead.
Paolo
On 12/12/2014 17:06, Andrew Jones wrote:
Signed-off-by: Andrew Jones drjo...@redhat.com
---
x86/pmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 5c85146810cb1..f116bafebf424 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -228,14
On 12/12/2014 17:06, Andrew Jones wrote:
Signed-off-by: Andrew Jones drjo...@redhat.com
---
x86/pmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 5c85146810cb1..f116bafebf424 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -228,14
On 12/12/2014 17:19, Andrew Jones wrote:
I'm afraid I didn't test all the changes, as not all unit tests
could run on my test machine.
svm- didn't run
xsave - didn't run 'have xsave' tests
asyncpf- is commented out of unittests.cfg,
and
Since the advent of VGIC dynamic initialization, this latter is
initialized quite late on the first vcpu run or on-demand, when
injecting an IRQ or when the guest sets its registers.
This series now allows the user space to explicitly request the VGIC init,
when the dimensioning parameters have
To be more explicit on vgic initialization failure, -ENODEV is
returned by vgic_init when no online vcpus can be found at init.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v2 - v3: vgic_init_maps was renamed into vgic_init
---
virt/kvm/arm/vgic.c | 2 +-
1 file changed, 1 insertion(+),
Since the advent of VGIC dynamic initialization, this latter is
initialized quite late on the first vcpu run or on-demand, when
injecting an IRQ or when the guest sets its registers.
This initialization could be initiated explicitly much earlier
by the users-space, as soon as it has provided the
When generating #PF VM-exit, check equality:
(PFEC PFEC_MASK) == PFEC_MATCH
If there is equality, the 14 bit of exception bitmap is used to take decision
about generating #PF VM-exit. If there is inequality, inverted 14 bit is used.
Signed-off-by: Eugene Korenevsky ekorenev...@gmail.com
---
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/vringh.h | 33 ++
drivers/vhost/vringh.c | 121 ++---
2 files changed, 107 insertions(+), 47 deletions(-)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
Pass u64 everywhere.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/vringh.h | 4 ++--
drivers/vhost/vringh.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
index 749cde2..f696dd0 100644
---
See patches for details.
v2:
- fix email address.
v3:
- use module parameter for configuration of value (Paolo/Radim)
v4:
- fix check for tscdeadline mode while waiting for expiration (Paolo)
- use proper delay function (Radim)
- fix LVTT tscdeadline mode check in hrtimer interrupt handler
Add tracepoint to wait_lapic_expire.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++ kvm/arch/x86/kvm/lapic.c
@@ -1121,6 +1121,7 @@ void
For the hrtimer which emulates the tscdeadline timer in the guest,
add an option to advance expiration, and busy spin on VM-entry waiting
for the actual expiration time to elapse.
This allows achieving low latencies in cyclictest (or any scenario
which requires strict timing regarding timer
kvm_x86_ops-test_posted_interrupt() returns true/false depending
whether 'vector' is set.
Next patch makes use of this interface.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/include/asm/kvm_host.h
===
---
On Sat, Dec 13, 2014 at 1:08 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 12/12/2014 22:39, Andy Lutomirski wrote:
KVM internal error. Suberror: 3
extra data[0]: 8202
extra data[1]: 31
EAX=8be4df61 EBX=8be4df61 ECX=3ff6002c EDX=11d293ca
ESI=3f08e408 EDI=3e82df7c EBP=3e82deb8
Hi,
I am novice to kvm/qemu, perhaps you can explain something to me.
I pass-through sata controller with fakeraid. It works, but I am getting
strange results during performance testing:
A. Host Windows, 6 cores (no HT, turbo boost off): 6:23 (+- 10 secs)
B. Host Windows, 1 CPU core (other are
45 matches
Mail list logo
