On 09/14/2012 01:57 PM, Xiao Guangrong wrote:
On 09/12/2012 04:15 PM, Avi Kivity wrote:
On 09/12/2012 07:40 AM, Fengguang Wu wrote:
Hi,
3 of my test boxes running v3.5 kernel become unaccessible and I find
two of them kept emitting this dmesg:
vmx_handle_exit: unexpected, valid vectoring
On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote:
On 09/14/2012 01:57 PM, Xiao Guangrong wrote:
On 09/12/2012 04:15 PM, Avi Kivity wrote:
On 09/12/2012 07:40 AM, Fengguang Wu wrote:
Hi,
3 of my test boxes running v3.5 kernel become unaccessible and I find
two of them
On 10/17/2012 02:43 PM, Fengguang Wu wrote:
On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote:
On 09/14/2012 01:57 PM, Xiao Guangrong wrote:
On 09/12/2012 04:15 PM, Avi Kivity wrote:
On 09/12/2012 07:40 AM, Fengguang Wu wrote:
Hi,
3 of my test boxes running v3.5 kernel become
On Wed, Oct 17, 2012 at 02:57:15AM +, Wei, Bing (WeiBing, MCXS-SH) wrote:
For pCPU/core and VCPUS/logical cpu mapping, It should be 8 multiple. 254 is
reasonable. Or something I miss?
I am not sure what do you mean. Can you clarify?
-Original Message-
From:
The problem with this is that it requires an administrator to understand the
workload, not only of the guest, but also of other guests on the machine.
With low overcommit, a high PLE window reduces unneeded exits, but with
high overcommit we need those exits to reduce spinning.
In
On 10/17/2012 06:23 AM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
cause confusion for the end user. To ease the confusion
On Wed, Oct 17, 2012 at 03:04:49PM +0800, Xiao Guangrong wrote:
On 10/17/2012 02:43 PM, Fengguang Wu wrote:
On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote:
On 09/14/2012 01:57 PM, Xiao Guangrong wrote:
On 09/12/2012 04:15 PM, Avi Kivity wrote:
On 09/12/2012 07:40 AM,
On Sat, Oct 13, 2012 at 08:57:19AM +, Blue Swirl wrote:
On Tue, Oct 9, 2012 at 5:04 PM, Vasilis Liaskovitis
vasilis.liaskovi...@profitbricks.com wrote:
snip
Maybe even the dimmbus device shouldn't exist by itself after all, or
it should be pretty much invisible to users. On real HW,
Hello,
I am testing KVM on an Oracle NFS box that I have.
Does the list have any advice on best practice? I remember reading that there
is stuff you can do with I/O schedulers and stuff to make it more efficient.
My VMs will primarily be running mysql databases. I am currently using o_direct.
On 10/16/2012 08:50 PM, Rohan Sharma wrote:
Thanks for the reply.
I have one more question.
If I do munmap of the RAM allocated in qemu,
will the changes be reflected in KVM Ept.
Yes. Those changes will be reflected. See
kvm_mmu_notifier_invalidate_page(), and related.
I guess there is
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
I don't think so, but probably there's a limit of DIMMs that real
controllers have, something like 8 max.
In the case of i440fx specifically, do you mean that we should model the DRB
(Dram row boundary registers in section 3.2.19 of the
On 10/17/2012 10:02 AM, Hu, Xuekun wrote:
The problem with this is that it requires an administrator to understand the
workload, not only of the guest, but also of other guests on the machine.
With low overcommit, a high PLE window reduces unneeded exits, but with
high overcommit we need
On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
于 2012年10月15日 23:43, Avi Kivity 写道:
On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
Currently, kdump just makes all the logical processors leave VMX operation
by
executing VMXOFF instruction, so any VMCSs active on the logical processors
may
be
Am 16.10.2012 12:10, schrieb Avi Kivity:
On 10/16/2012 11:48 AM, Lukas Laukamp wrote:
Am 16.10.2012 11:40, schrieb Avi Kivity:
On 10/16/2012 11:12 AM, Lukas Laukamp wrote:
Hey all,
I have a question about a solution for migrate LVM based guests directly
over the network.
So the situation:
On 10/16/2012 10:03 PM, Anthony Liguori wrote:
This forces userspace to dedicate a thread for the HPT.
If no changes are available, does read return a size 0? I don't think
it's necessary to support polling. The kernel should always be able to
respond to userspace here. The only catch
On 10/16/2012 11:52 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 03:06:33PM +0200, Avi Kivity wrote:
On 10/16/2012 01:58 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 12:06:58PM +0200, Avi Kivity wrote:
Does/should the fd support O_NONBLOCK and poll? (=waiting for an entry
to
On 10/17/2012 04:10 AM, Will Auld wrote:
Signed-off-by: Will Auld will.a...@intel.com
---
Resending to full list
Marcelo,
This patch is what I believe you ask for as foundational for later
patches to address IA32_TSC_ADJUST.
Please write a changelog to reflect the motivation.
All
On 10/17/2012 11:20 AM, Andrew Holway wrote:
Hello,
I am testing KVM on an Oracle NFS box that I have.
Does the list have any advice on best practice? I remember reading that there
is stuff you can do with I/O schedulers and stuff to make it more efficient.
My VMs will primarily be
O_DIRECT is good. I/O schedulers don't affect NFS so no need to tune
anything on the host. You might experiment with switching to the
deadline scheduler in the guest.
Ill give it a go. Any ideas how I should be tuning my NFS?
--
error compiling committee.c: too many arguments to
On 10/17/2012 01:04 PM, Andrew Holway wrote:
O_DIRECT is good. I/O schedulers don't affect NFS so no need to tune
anything on the host. You might experiment with switching to the
deadline scheduler in the guest.
Ill give it a go. Any ideas how I should be tuning my NFS?
Not really.
Am Dienstag, 16. Oktober 2012, 12:44:27 schrieb Brian Jackson:
On Tuesday, October 16, 2012 11:33:44 AM Guido Winkelmann wrote:
[...]
The commandline, as generated by libvirtd, looks like this:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=none
On 10/16/2012 02:07 PM, Xiao Guangrong wrote:
We can not directly call kvm_release_pfn_clean to release the pfn
since we can meet noslot pfn which is used to cache mmio info into
spte
Applied to master for 3.7, 3.6, thanks.
--
error compiling committee.c: too many arguments to function
--
Make uapi/asm-generic/kvm_para.h non-empty by addition of a comment to stop
the patch program from deleting it when it creates it.
Then delete empty arch-specific uapi/asm/kvm_para.h files and tell the Kbuild
files to use the generic instead.
Should this perhaps instead be a #warning or #error
On Wednesday 17 October 2012, David Howells wrote:
Make uapi/asm-generic/kvm_para.h non-empty by addition of a comment to stop
the patch program from deleting it when it creates it.
Then delete empty arch-specific uapi/asm/kvm_para.h files and tell the Kbuild
files to use the generic
On Wed, Oct 17, 2012 at 12:35:33PM +0200, Avi Kivity wrote:
On 10/17/2012 04:10 AM, Will Auld wrote:
Signed-off-by: Will Auld will.a...@intel.com
---
Resending to full list
Marcelo,
This patch is what I believe you ask for as foundational for later
patches to address
Make uapi/asm-generic/kvm_para.h non-empty by addition of a comment to stop
the patch program from deleting it when it creates it.
Then delete empty arch-specific uapi/asm/kvm_para.h files and tell the Kbuild
files to use the generic instead.
Should this perhaps instead be a #warning or #error
On 10/17/2012 04:09 PM, Marcelo Tosatti wrote:
On Wed, Oct 17, 2012 at 12:35:33PM +0200, Avi Kivity wrote:
On 10/17/2012 04:10 AM, Will Auld wrote:
Signed-off-by: Will Auld will.a...@intel.com
---
Resending to full list
Marcelo,
This patch is what I believe you ask for as
On 10/16/2012 02:08 PM, Xiao Guangrong wrote:
Remove mmu_is_invalid and use is_invalid_pfn instead
Applied 2-5 to next; 6 depends on 1, so will wait until it is merged
upstream.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 10/16/2012 04:49 PM, Alexander Graf wrote:
If there is a lot of prioritization and/or queuing logic, then yes. But
what about MSI? Doesn't that have a direct path?
Nope. Well, yes, in a certain special case where the MPIC pushes the
interrupt vector on interrupt delivery into a special
We can deliver certain interrupts, notably MSIX,
from atomic context.
Here's an untested patch to do this (compiled only).
Changes from v2:
Don't inject broadcast interrupts directly
Changes from v1:
Tried to address comments from v1, except unifying
with kvm_set_irq: passing flags to it looks
Add an API to inject IRQ from atomic context.
Return EWOULDBLOCK if impossible (e.g. for multicast).
Only MSI is supported ATM.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/kvm_host.h | 1 +
virt/kvm/irq_comm.c | 83 +---
2
We can deliver certain interrupts, notably MSI,
from atomic context. Use kvm_set_irq_inatomic,
to implement an irq handler for msi.
This reduces the pressure on scheduler in case
where host and guest irq share a host cpu.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
On Wed, 2012-10-17 at 21:14 +0400, Glauber Costa wrote:
On 10/17/2012 06:23 AM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
Am Dienstag, 16. Oktober 2012, 12:44:27 schrieb Brian Jackson:
On Tuesday, October 16, 2012 11:33:44 AM Guido Winkelmann wrote:
The commandline, as generated by libvirtd, looks like this:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=none
Hi,
we are seeing something strange when running the KVM unit-tests on
recent KVM and older CPUs (K8 Family).
[ cut here ]
WARNING: at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1325
kvm_release_pfn_clean+0x5b/0x60 [kvm]()
Hardware name: WARTHOG
Modules linked in: tun
On 10/17/2012 06:08 PM, Conny Seidel wrote:
Hi,
we are seeing something strange when running the KVM unit-tests on
recent KVM and older CPUs (K8 Family).
A patch was just applied fixing this; it will be merged upstream in a
few days.
--
error compiling committee.c: too many arguments
On 10/17/2012 04:50 PM, Avi Kivity wrote:
On 10/16/2012 04:49 PM, Alexander Graf wrote:
If there is a lot of prioritization and/or queuing logic, then yes. But
what about MSI? Doesn't that have a direct path?
Nope. Well, yes, in a certain special case where the MPIC pushes the
interrupt
On Wednesday, October 17, 2012 06:54:00 AM Guido Winkelmann wrote:
Am Dienstag, 16. Oktober 2012, 12:44:27 schrieb Brian Jackson:
On Tuesday, October 16, 2012 11:33:44 AM Guido Winkelmann wrote:
[...]
The commandline, as generated by libvirtd, looks like this:
LC_ALL=C
On Wednesday, October 17, 2012 10:45:14 AM Guido Winkelmann wrote:
Am Dienstag, 16. Oktober 2012, 12:44:27 schrieb Brian Jackson:
On Tuesday, October 16, 2012 11:33:44 AM Guido Winkelmann wrote:
The commandline, as generated by libvirtd, looks like this:
LC_ALL=C
Hi,
OpenBSD/i386 seems to be one of the few operating systems that still
uses the LAPIC taks priority register for interrupt handling. On AMD
CPUs and on older Intel CPUs without the flexpriority feature, this
causes a huge performance impact on kvm. I have seen slowdown by a
factor of 10.
On 14 October 2012 01:04, Christoffer Dall
c.d...@virtualopensystems.com wrote:
Used to initialize the in-kernel interrupt controller. On ARM we need to
map the virtual generic interrupt controller (vGIC) into Hyp the guest's
physicall address space so the guest can access the virtual cpu
On Wed, Oct 17, 2012 at 4:21 PM, Peter Maydell peter.mayd...@linaro.org wrote:
On 14 October 2012 01:04, Christoffer Dall
c.d...@virtualopensystems.com wrote:
Used to initialize the in-kernel interrupt controller. On ARM we need to
map the virtual generic interrupt controller (vGIC) into Hyp
On 14 October 2012 01:04, Christoffer Dall
c.d...@virtualopensystems.com wrote:
On ARM (and possibly other architectures) some bits are specific to the
model being emulated for the guest and user space needs a way to tell
the kernel about those bits. An example is mmio device base addresses,
On 17 October 2012 21:23, Christoffer Dall
c.d...@virtualopensystems.com wrote:
On Wed, Oct 17, 2012 at 4:21 PM, Peter Maydell peter.mayd...@linaro.org
wrote:
+for the emulated platofrm (see KVM_SET_DEVICE_ADDRESS), but before the CPU
is
+initally run.
initially.
thanks a bunch for
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at which we expect VMs to access
the interrupt controller (both the emulated distributor and the hardware
interface supporting virtualization).
On Wed, Oct 17, 2012 at 4:31 PM, Peter Maydell peter.mayd...@linaro.org wrote:
On 17 October 2012 21:23, Christoffer Dall
c.d...@virtualopensystems.com wrote:
On Wed, Oct 17, 2012 at 4:21 PM, Peter Maydell peter.mayd...@linaro.org
wrote:
+for the emulated platofrm (see
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de wrote:
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at which we expect VMs to access
the interrupt controller (both the emulated
On Wed, 2012-10-17 at 16:39 -0400, Christoffer Dall wrote:
Have you talked to Ben about this one? He wanted to design a new, more
flexible irqchip API that would work for XICS MPIC. Maybe there's some
room for cooperation here?
I have not - Ben, what do you have in mind?
I've been
OK, agreed it is not pretty.
Thanks,
Will
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Wednesday, October 17, 2012 7:09 AM
To: Avi Kivity
Cc: Auld, Will; Will Auld; kvm@vger.kernel.org; Zhang, Xiantao; Liu,
Jinsong
Subject: Re: [PATCH] Added call
On Wed, Oct 17, 2012 at 04:39:57PM -0400, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de wrote:
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip: a source controller and
a presentation controller. There is one presentation controller per
vcpu and typically one source controller per PCI host bridge (a source
controller can manage
Acked-by: Xiantao Zhangxiantao.zh...@intel.com
-Original Message-
From: Wei Yongjun [mailto:weiyj...@gmail.com]
Sent: Wednesday, October 17, 2012 11:04 PM
To: a...@redhat.com; mtosa...@redhat.com; Zhang, Xiantao; Luck, Tony; Yu,
Fenghua
Cc: yongjun_...@trendmicro.com.cn;
于 2012年10月17日 18:16, Avi Kivity 写道:
On 10/17/2012 04:28 AM, Zhang Yanfei wrote:
于 2012年10月15日 23:43, Avi Kivity 写道:
On 10/12/2012 08:40 AM, Zhang Yanfei wrote:
Currently, kdump just makes all the logical processors leave VMX operation
by
executing VMXOFF instruction, so any VMCSs active on
Asias He as...@redhat.com writes:
+#define BLK_HDR0
What's this for, exactly? Please add a comment.
The block headr is in the first and separate buffer.
Please don't assume this! We're trying to fix all the assumptions in
qemu at the moment.
vhost_net handles this correctly, taking
On 16.10.2012, at 21:33, Benjamin Herrenschmidt wrote:
On Tue, 2012-10-16 at 17:00 +1100, Michael Ellerman wrote:
Thanks for looking at this - but in fact this is fixed by my patch
entitled KVM: PPC: Book3S HV: Fix some races in starting secondary
threads submitted back on August 28.
OK
On 10/16/2012 10:03 PM, Anthony Liguori wrote:
This forces userspace to dedicate a thread for the HPT.
If no changes are available, does read return a size 0? I don't think
it's necessary to support polling. The kernel should always be able to
respond to userspace here. The only catch
On 10/16/2012 11:52 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 03:06:33PM +0200, Avi Kivity wrote:
On 10/16/2012 01:58 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 12:06:58PM +0200, Avi Kivity wrote:
Does/should the fd support O_NONBLOCK and poll? (=waiting for an entry
to
On 10/16/2012 04:49 PM, Alexander Graf wrote:
If there is a lot of prioritization and/or queuing logic, then yes. But
what about MSI? Doesn't that have a direct path?
Nope. Well, yes, in a certain special case where the MPIC pushes the
interrupt vector on interrupt delivery into a special
On 10/17/2012 04:50 PM, Avi Kivity wrote:
On 10/16/2012 04:49 PM, Alexander Graf wrote:
If there is a lot of prioritization and/or queuing logic, then yes. But
what about MSI? Doesn't that have a direct path?
Nope. Well, yes, in a certain special case where the MPIC pushes the
interrupt
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at which we expect VMs to access
the interrupt controller (both the emulated distributor and the hardware
interface supporting virtualization).
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de wrote:
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at which we expect VMs to access
the interrupt controller (both the emulated
On Wed, 2012-10-17 at 16:39 -0400, Christoffer Dall wrote:
Have you talked to Ben about this one? He wanted to design a new, more
flexible irqchip API that would work for XICS MPIC. Maybe there's some
room for cooperation here?
I have not - Ben, what do you have in mind?
I've been
On Wed, Oct 17, 2012 at 04:39:57PM -0400, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de wrote:
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip: a source controller and
a presentation controller. There is one presentation controller per
vcpu and typically one source controller per PCI host bridge (a source
controller can manage
64 matches
Mail list logo
