Am 12.11.2014 um 01:36 schrieb Linus Torvalds:
On Tue, Nov 11, 2014 at 4:33 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I guess as a workaround it is fine, as long as we don't lose sight of
trying to eventually do a better job.
Oh, and when it comes to the actual gcc bug - do
On 11/11/2014 20:57, Matt Mullins wrote:
That seems to work great, yes.
Looking through the commit history, I see:
kvmclock: Ensure time in migration never goes backward
kvmclock: Ensure proper env-tsc value for kvmclock_current_nsec
calculation
Assuming those are the
On 12/11/2014 04:42, Zhang, Yang Z wrote:
Personally, I think this feature will be helpful to the legacy device
assignment. Agree, vfio is the right solution for future feature
enabling. But the old kvm without the good vfio supporting is still
used largely today. The user really looking for
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Wednesday, November 12, 2014 5:14 PM
To: Zhang, Yang Z; Wu, Feng; Alex Williamson
Cc: g...@kernel.org; dw...@infradead.org; j...@8bytes.org;
t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
On Tue, 11 Nov 2014 16:36:06 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Nov 11, 2014 at 4:33 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I guess as a workaround it is fine, as long as we don't lose sight of
trying to eventually do a better job.
Oh,
On 28 October 2014 02:07, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/Kconfig | 1 +
On 12/11/2014 10:19, Wu, Feng wrote:
You can certainly backport these patches to distros that do not have
VFIO. But upstream we should work on VFIO first. VFIO has feature
parity with legacy device assignment, and adding a new feature that is
not in VFIO would be a bad idea.
By the way,
Hello Hongbo,
On Wed, Nov 12, 2014 at 10:52 AM, Hongbo Zhang hongbo.zh...@linaro.org wrote:
On 28 October 2014 02:07, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by:
On 12 November 2014 18:05, bharat.bhus...@freescale.com
bharat.bhus...@freescale.com wrote:
Hi,
This is not yet supported on Freescale PowerPC. I am still in process of
upstreaming the FSL PAMU specific patches for same.
Initial plan is to test with PCIe devices and then with Platform
-Original Message-
From: Hongbo Zhang [mailto:hongbo.zh...@linaro.org]
Sent: Wednesday, November 12, 2014 4:09 PM
To: Bhushan Bharat-R65777
Cc: Antonios Motakis; open list:VFIO DRIVER; will.dea...@arm.com;
alex.william...@redhat.com; open list; io...@lists.linux-foundation.org;
On 12 November 2014 19:00, bharat.bhus...@freescale.com
bharat.bhus...@freescale.com wrote:
-Original Message-
From: Hongbo Zhang [mailto:hongbo.zh...@linaro.org]
Sent: Wednesday, November 12, 2014 4:09 PM
To: Bhushan Bharat-R65777
Cc: Antonios Motakis; open list:VFIO DRIVER;
On 10/11/2014 18:38, Gleb Natapov wrote:
On Mon, Nov 10, 2014 at 06:28:25PM +0100, Paolo Bonzini wrote:
On 10/11/2014 15:23, Avi Kivity wrote:
It's not surprising [1]. Since the meaning of some PTE bits change [2],
the TLB has to be flushed. In VMX we have VPIDs, so we only need to flush
On 08/11/2014 03:25, Andy Lutomirski wrote:
At least on Sandy Bridge, letting the CPU switch IA32_EFER is much
faster than switching it manually.
I benchmarked this using the vmexit kvm-unit-test (single run, but
GOAL multiplied by 5 to do more iterations):
Test
When mutex_trylock() fails, kvm_vgic_create() will not create 'vgic', so
it need return failure code '-EBUSY' instead of '0' to let outside know
about it.
Also simplify the code within kvm_vgic_create():
- kvm_for_each_vcpu() scanning once is enough for current case.
- Remove redundant
On Wed, Nov 12, 2014 at 12:33:32PM +0100, Paolo Bonzini wrote:
On 10/11/2014 18:38, Gleb Natapov wrote:
On Mon, Nov 10, 2014 at 06:28:25PM +0100, Paolo Bonzini wrote:
On 10/11/2014 15:23, Avi Kivity wrote:
It's not surprising [1]. Since the meaning of some PTE bits change [2],
the
On 12/11/2014 16:22, Gleb Natapov wrote:
Nehalem results:
userspace exit, urn 17560 17726 17628 17572 17417
lightweight exit, urn 3316 3342 3342 3319 3328
userspace exit, LOAD_EFER, guest!=host 12200 11772 12130 12164 12327
lightweight
On Wed, Nov 12, 2014 at 04:26:29PM +0100, Paolo Bonzini wrote:
On 12/11/2014 16:22, Gleb Natapov wrote:
Nehalem results:
userspace exit, urn 17560 17726 17628 17572 17417
lightweight exit, urn 3316 3342 3342 3319 3328
userspace
On 12/11/2014 16:32, Gleb Natapov wrote:
userspace exit, urn 17560 17726 17628 17572 17417
lightweight exit, urn 3316 3342 3342 3319 3328
userspace exit, LOAD_EFER, guest!=host 12200 11772 12130 12164 12327
lightweight exit,
On Wed, Nov 12, 2014 at 7:51 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 12/11/2014 16:32, Gleb Natapov wrote:
userspace exit, urn 17560 17726 17628 17572 17417
lightweight exit, urn 3316 3342 3342 3319 3328
userspace exit, LOAD_EFER,
On Wed, 2014-11-12 at 11:32 +0100, Eric Auger wrote:
On 10/27/2014 07:07 PM, Antonios Motakis wrote:
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory
On Wed, 2014-11-12 at 10:14 +0100, Paolo Bonzini wrote:
On 12/11/2014 04:42, Zhang, Yang Z wrote:
Personally, I think this feature will be helpful to the legacy device
assignment. Agree, vfio is the right solution for future feature
enabling. But the old kvm without the good vfio
On Wed, 2014-11-12 at 11:05 +0100, Eric Auger wrote:
Hi Antonios,
On 10/27/2014 07:07 PM, Antonios Motakis wrote:
This patch forms the common skeleton code for platform devices support
with VFIO. This will include the core functionality of VFIO_PLATFORM,
however binding to the device and
Assuming you're running both of my patches (LOAD_EFER regardless of
nx, but skip LOAD_EFER of guest == host), then some of the speedup may
be just less code running. I haven't figured out exactly when
vmx_save_host_state runs, but my patches avoid a call to
kvm_set_shared_msr, which is worth
On 11/10 11:18 PM, Marcelo Tosatti wrote:
On Wed, Nov 05, 2014 at 11:46:42AM -0800, David Matlack wrote:
The new trace event records:
* the id of vcpu being updated
* the pvclock_vcpu_time_info struct being written to guest memory
This is useful for debugging pvclock bugs, such as
On Wed, Nov 12, 2014 at 11:04:23PM +0800, Chen Gang wrote:
When mutex_trylock() fails, kvm_vgic_create() will not create 'vgic', so
it need return failure code '-EBUSY' instead of '0' to let outside know
about it.
I already sent a patch for the -EBUSY:
On Tue, Nov 11, 2014 at 05:12:58PM +, Ben Hutchings wrote:
This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for
the tap drivers, but leaves UFO disabled in virtio_net.
libvirt at least assumes that tap features will never be dropped
in new kernel versions, and doing so
Wu, Feng wrote on 2014-11-13:
kvm-ow...@vger.kernel.org wrote on 2014-11-12:
kvm@vger.kernel.org; io...@lists.linux-foundation.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH 05/13] KVM: Update IRTE according to guest
interrupt configuration changes
On 12/11/2014 10:19, Wu,
-Original Message-
From: Zhang, Yang Z
Sent: Thursday, November 13, 2014 9:21 AM
To: Wu, Feng; Paolo Bonzini; Alex Williamson
Cc: g...@kernel.org; dw...@infradead.org; j...@8bytes.org;
t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
kvm@vger.kernel.org;
Wu, Feng wrote on 2014-11-13:
Zhang, Yang Z wrote on 2014-11-13:
kvm@vger.kernel.org; io...@lists.linux-foundation.org;
linux-ker...@vger.kernel.org
Subject: RE: [PATCH 05/13] KVM: Update IRTE according to guest
interrupt configuration changes
Wu, Feng wrote on 2014-11-13:
On 11/13/14 3:41, Christoffer Dall wrote:
On Wed, Nov 12, 2014 at 11:04:23PM +0800, Chen Gang wrote:
When mutex_trylock() fails, kvm_vgic_create() will not create 'vgic', so
it need return failure code '-EBUSY' instead of '0' to let outside know
about it.
I already sent a patch for the
The periodic kvmclock sync can be an undesired source of latencies.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0033df3..be56fd3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -98,6 +98,9 @@ module_param(ignore_msrs,
When running the tsc_adjust kvm-unit-test on an AMD processor with the
IA32_TSC_ADJUST feature enabled, the WARN_ON in svm_adjust_tsc_offset can be
triggered. This WARN_ON checks for a negative adjustment in case __scale_tsc
is called; however it may trigger unnecessary warnings.
This patch moves
* kernelf...@gmail.com kernelf...@gmail.com [2014-10-16 15:29:50]:
Some system such as powerpc, some tsk (vcpu thread) can only run on
the dedicated cpu. Since we adapt some asymmetric method to monitor the
whole physical cpu. (powerKVM only allows the primary hwthread to
set up runtime env
* kernelf...@gmail.com kernelf...@gmail.com [2014-10-16 15:29:51]:
When vcpu thread runs at the first time, it will ensure to stick
to the primary thread.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 3 +++
* kernelf...@gmail.com kernelf...@gmail.com [2014-10-16 15:29:52]:
When kvm is enabled on a core, we migrate all external irq to primary
thread. Since currently, the kvmirq logic is handled by the primary
hwthread.
Todo: this patch lacks re-enable of irqbalance when kvm is disable on
the
35 matches
Mail list logo
