Asias He (4):
tcm_vhost: Refactor the lock nesting rule
tcm_vhost: Add hotplug/hotunplug support
tcm_vhost: Add ioctl to get and set events missed flag
tcm_vhost: Enable VIRTIO_SCSI_F_HOTPLUG
drivers/vhost/tcm_vhost.c | 262 +++---
We want to use tcm_vhost_mutex to make sure hotplug/hotunplug will not
happen when set_endpoint/clear_endpoint is in process.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff
In commit 365a7150094 ([SCSI] virtio-scsi: hotplug support for
virtio-scsi), hotplug support is added to virtio-scsi.
This patch adds hotplug and hotunplug support to tcm_vhost.
You can create or delete a LUN in targetcli to hotplug or hotunplug a
LUN in guest.
Changes in v8:
- Use vq-mutex for
Everything for hotplug is ready. Let's enable the feature bit.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 07217d8..1677238 100644
---
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 17 +
drivers/vhost/tcm_vhost.h | 3 +++
2 files changed, 20 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 5340fd7..07217d8 100644
--- a/drivers/vhost/tcm_vhost.c
On Thu, Apr 25, 2013 at 12:28:35AM +, Joji Mekkattuparamban (joji) wrote:
Thank you Gleb and Marcelo. I will migrate the API using gettimeofday.
Is there any dependency on the QEMU or the Guest? If the host supports
pvclock and the guest invokes gettimeofday, would the pvclock be
MST wants one without change history in commit log.
From 8996c9464fae1f28d0bd729677a3917d204990ec Mon Sep 17 00:00:00 2001
From: Asias He as...@redhat.com
Date: Thu, 25 Apr 2013 09:51:26 +0800
Subject: [PATCH v10 2/4] tcm_vhost: Add hotplug/hotunplug support
In commit 365a7150094 ([SCSI]
On Thu, Apr 25, 2013 at 03:14:11PM +0800, Asias He wrote:
MST wants one without change history in commit log.
So post v11, and add changes since v9 and since v10
after ---.
Make life easy for maintainers please.
From 8996c9464fae1f28d0bd729677a3917d204990ec Mon Sep 17 00:00:00 2001
From:
On Wed, Apr 24, 2013 at 01:20:31PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most of the code already is
perfectly
Changes in v11
- Drop change log histroy in commit log
Changes in v10
- Drop comments about lun
- Add Enable VIRTIO_SCSI_F_HOTPLUG to this series
Changes in v9
- Drop tcm_vhost_check_feature
- Add Refactor the lock nesting rule to this sereis
Asias He (4):
tcm_vhost: Refactor the lock nesting
We want to use tcm_vhost_mutex to make sure hotplug/hotunplug will not
happen when set_endpoint/clear_endpoint is in process.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff
In commit 365a7150094 ([SCSI] virtio-scsi: hotplug support for
virtio-scsi), hotplug support is added to virtio-scsi.
This patch adds hotplug and hotunplug support to tcm_vhost.
You can create or delete a LUN in targetcli to hotplug or hotunplug a
LUN in guest.
Signed-off-by: Asias He
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 17 +
drivers/vhost/tcm_vhost.h | 3 +++
2 files changed, 20 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 5340fd7..07217d8 100644
--- a/drivers/vhost/tcm_vhost.c
Everything for hotplug is ready. Let's enable the feature bit.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 07217d8..1677238 100644
---
On Thu, Apr 25, 2013 at 03:35:19PM +0800, Asias He wrote:
Changes in v11
- Drop change log histroy in commit log
Changes in v10
- Drop comments about lun
- Add Enable VIRTIO_SCSI_F_HOTPLUG to this series
Changes in v9
- Drop tcm_vhost_check_feature
- Add Refactor the lock nesting rule
On Thu, Apr 25, 2013 at 03:35:20PM +0800, Asias He wrote:
We want to use tcm_vhost_mutex to make sure hotplug/hotunplug will not
happen when set_endpoint/clear_endpoint is in process.
Signed-off-by: Asias He as...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
On Thu, Apr 25, 2013 at 03:35:21PM +0800, Asias He wrote:
In commit 365a7150094 ([SCSI] virtio-scsi: hotplug support for
virtio-scsi), hotplug support is added to virtio-scsi.
This patch adds hotplug and hotunplug support to tcm_vhost.
You can create or delete a LUN in targetcli to hotplug
On Thu, Apr 25, 2013 at 03:35:22PM +0800, Asias He wrote:
Signed-off-by: Asias He as...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/tcm_vhost.c | 17 +
drivers/vhost/tcm_vhost.h | 3 +++
2 files changed, 20 insertions(+)
diff --git
On Thu, Apr 25, 2013 at 03:35:23PM +0800, Asias He wrote:
Everything for hotplug is ready. Let's enable the feature bit.
Signed-off-by: Asias He as...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/tcm_vhost.c | 3 ++-
1 file changed, 2 insertions(+), 1
Recent KVM, since http://kerneltrap.org/mailarchive/linux-kvm/2010/5/2/6261577
switch the EFER MSR when EPT is used and the host and guest have different
NX bits. So if we add support for nested EPT (L1 guest using EPT to run L2)
and want to be able to run recent KVM as L1, we need to allow L1 to
This is the first patch in a series which adds nested EPT support to KVM's
nested VMX. Nested EPT means emulating EPT for an L1 guest so that L1 can use
EPT when running a nested guest L2. When L1 uses EPT, it allows the L2 guest
to set its own cr3 and take its own page faults without either of L0
KVM's existing shadow MMU code already supports nested TDP. To use it, we
need to set up a new MMU context for nested EPT, and create a few callbacks
for it (nested_ept_*()). This context should also use the EPT versions of
the page table access functions (defined in the previous patch).
Then, we
The existing code for handling cr3 and related VMCS fields during nested
exit and entry wasn't correct in all cases:
If L2 is allowed to control cr3 (and this is indeed the case in nested EPT),
during nested exit we must copy the modified cr3 from vmcs02 to vmcs12, and
we forgot to do so. This
kvm_set_cr3() attempts to check if the new cr3 is a valid guest physical
address. The problem is that with nested EPT, cr3 is an *L2* physical
address, not an L1 physical address as this test expects.
As the comment above this test explains, it isn't necessary, and doesn't
correspond to anything
Some additional comments to preexisting code:
Explain who (L0 or L1) handles EPT violation and misconfiguration exits.
Don't mention shadow on either EPT or shadow as the only two options.
Signed-off-by: Nadav Har'El n...@il.ibm.com
Signed-off-by: Jun Nakajima jun.nakaj...@intel.com
modified:
Advertise the support of EPT to the L1 guest, through the appropriate MSR.
This is the last patch of the basic Nested EPT feature, so as to allow
bisection through this patch series: The guest will not see EPT support until
this last patch, and will not attempt to use the half-applied feature.
If we let L1 use EPT, we should probably also support the INVEPT instruction.
In our current nested EPT implementation, when L1 changes its EPT table for
L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in the course
of this modification already calls INVEPT. Therefore, when L1
Update the documentation to no longer say that nested EPT is not supported.
Signed-off-by: Nadav Har'El n...@il.ibm.com
Signed-off-by: Jun Nakajima jun.nakaj...@intel.com
modified: Documentation/virtual/kvm/nested-vmx.txt
---
Documentation/virtual/kvm/nested-vmx.txt | 4 ++--
1 file changed,
Some trivial code cleanups not really related to nested EPT.
Signed-off-by: Nadav Har'El n...@il.ibm.com
Signed-off-by: Jun Nakajima jun.nakaj...@intel.com
modified: arch/x86/include/asm/vmx.h
modified: arch/x86/kvm/vmx.c
---
arch/x86/include/asm/vmx.h | 44
Since vcpu_vmx is contained in vmx.c, use kvm_vcpu_arch so that we can
use the exit quaflication in paging_tmpl.h.
Signed-off-by: Jun Nakajima jun.nakaj...@intel.com
modified: arch/x86/include/asm/kvm_host.h
modified: arch/x86/kvm/paging_tmpl.h
modified: arch/x86/kvm/vmx.c
---
Signed-off-by: Nadav Har'El n...@il.ibm.com
Signed-off-by: Jun Nakajima jun.nakaj...@intel.com
modified: arch/x86/kvm/mmu.c
---
arch/x86/kvm/mmu.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 34e406e2..99bfc5e
On Wed, Apr 24, 2013 at 8:55 AM, Nakajima, Jun jun.nakaj...@intel.com wrote:
Sorry about the slow progress. We've been distracted by some priority
things. The patches are ready (i.e. working), but we are cleaning them
up. I'll send what we have today.
So, I have sent them, and frankly we are
All the patches are mangled by your email client. Please use git
send-email --thread to send them.
On Thu, Apr 25, 2013 at 12:50:19AM -0700, Nakajima, Jun wrote:
Recent KVM, since http://kerneltrap.org/mailarchive/linux-kvm/2010/5/2/6261577
switch the EFER MSR when EPT is used and the host and
On Thu, 2013-04-25 at 10:39 +0300, Michael S. Tsirkin wrote:
On Thu, Apr 25, 2013 at 03:35:19PM +0800, Asias He wrote:
Changes in v11
- Drop change log histroy in commit log
Changes in v10
- Drop comments about lun
- Add Enable VIRTIO_SCSI_F_HOTPLUG to this series
Changes in v9
On 08.03.2013, at 21:25, Scott Wood wrote:
The existing check handles the case where we've migrated to a different
core than we last ran on, but it doesn't handle the case where we're
still on the same cpu we last ran on, but some other vcpu has run on
this cpu in the meantime.
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Friday, April 19, 2013 1:03 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM: PPC: e500: Add e6500 core to Kconfig
description
On
On 04/25/2013 05:09 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Friday, April 19, 2013 1:03 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM: PPC:
On Thu, Apr 25, 2013 at 01:00:42AM -0700, Nakajima, Jun wrote:
On Wed, Apr 24, 2013 at 8:55 AM, Nakajima, Jun jun.nakaj...@intel.com wrote:
Sorry about the slow progress. We've been distracted by some priority
things. The patches are ready (i.e. working), but we are cleaning them
up. I'll
On 04/24/2013 08:59 PM, Gleb Natapov wrote:
On Mon, Apr 01, 2013 at 05:56:49PM +0800, Xiao Guangrong wrote:
Then it has chance to trigger mmio generation number wrap-around
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_host.h |1 +
On 04/24/2013 09:34 PM, Gleb Natapov wrote:
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 2adcbc2..6b4ba1e 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -52,6 +52,20 @@
int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu, u64 addr, u64
sptes[4]);
void
Off-list, Asias asked about adding scsi specific fields per vq.
Something like the following would be helpful: untested, just to give
you the idea.
On top of this we can add patches to move things like ubufs
from vhost.h out to net.c
Warning: completely untested.
Signed-off-by: Michael S.
On 25.04.2013, at 09:28, Gleb Natapov wrote:
On Wed, Apr 24, 2013 at 01:20:31PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most
On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote:
I start 10 VMs(windows xp), then running geekbench tool on
them, about 2 days, one of them was reset, I found the reset
operation is done by int kvm_cpu_exec(CPUArchState *env) {
...
switch
On 21.04.2013, at 12:51, Michael S. Tsirkin wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most of the code already is
perfectly
generic.
This
On Fri, Apr 12, 2013 at 07:08:42PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through
On 04/25/2013 05:32 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, April 25, 2013 12:17 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM:
On 19.04.2013, at 20:02, Scott Wood wrote:
On 04/19/2013 09:06:26 AM, Alexander Graf wrote:
diff --git a/Documentation/virtual/kvm/devices/mpic.txt
b/Documentation/virtual/kvm/devices/mpic.txt
index ce98e32..dadc1e0 100644
--- a/Documentation/virtual/kvm/devices/mpic.txt
+++
On 23.04.2013, at 08:38, Paul Mackerras wrote:
On Fri, Apr 19, 2013 at 04:06:26PM +0200, Alexander Graf wrote:
Now that all the irq routing and irqfd pieces are generic, we can expose
real irqchip support to all of KVM's internal helpers.
This allows us to use irqfd with the in-kernel
On Fri, Apr 19, 2013 at 04:06:12PM +0200, Alexander Graf wrote:
The concept of routing interrupt lines to an irqchip is nothing
that is IOAPIC specific. Every irqchip has a maximum number of pins
that can be linked to irq lines.
So let's add a new define that allows us to reuse generic code
On Fri, Apr 19, 2013 at 04:06:13PM +0200, Alexander Graf wrote:
Quite a bit of code in KVM has been conditionalized on availability of
IOAPIC emulation. However, most of it is generically applicable to
platforms that don't have an IOPIC, but a different type of irq chip.
Make code that only
On Fri, Apr 19, 2013 at 04:06:14PM +0200, Alexander Graf wrote:
We have a capability enquire system that allows user space to ask kvm
whether a feature is available.
The point behind this system is that we can have different kernel
configurations with different capabilities and user space
On Fri, Apr 19, 2013 at 04:06:16PM +0200, Alexander Graf wrote:
The IRQ routing set ioctl lives in the hacky device assignment code inside
of KVM today. This is definitely the wrong place for it. Move it to the much
more natural kvm_main.c.
Signed-off-by: Alexander Graf ag...@suse.de
On Fri, Apr 19, 2013 at 04:06:15PM +0200, Alexander Graf wrote:
The prototype has been stale for a while, I can't spot any real function
define behind it. Let's just remove it.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Michael S. Tsirkin m...@redhat.com
---
On Fri, Apr 19, 2013 at 04:06:17PM +0200, Alexander Graf wrote:
The current irq_comm.c file contains pieces of code that are generic
across different irqchip implementations, as well as code that is
fully IOAPIC specific.
Split the generic bits out into irqchip.c.
Signed-off-by: Alexander
On Fri, Apr 19, 2013 at 04:06:18PM +0200, Alexander Graf wrote:
Setting up IRQ routes is nothing IOAPIC specific. Extract everything
that really is generic code into irqchip.c and only leave the ioapic
specific bits to irq_comm.c.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by:
On Fri, Apr 19, 2013 at 04:06:19PM +0200, Alexander Graf wrote:
Now that we have most irqfd code completely platform agnostic, let's move
irqfd's resample capability return to generic code as well.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Michael S. Tsirkin m...@redhat.com
---
On Fri, Apr 19, 2013 at 04:06:11PM +0200, Alexander Graf wrote:
Hi,
This patch set contains a fully working implementation of the in-kernel MPIC
from Scott with a few fixups and a new version of my irqfd generalization
patch set.
For patches 1-8:
Acked-by: Michael S. Tsirkin m...@redhat.com
On 25.04.2013, at 11:43, Gleb Natapov wrote:
On Fri, Apr 12, 2013 at 07:08:42PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM, Alexander Graf wrote:
Now that all pieces are in place for reusing generic irq infrastructure,
we can copy x86's implementation of KVM_IRQ_LINE irq injection and simply
reuse it for PPC, as it will work there just as well.
Commit cd66cc2e, powerpc/85xx: Add AltiVec support for e6500, adds
support for AltiVec on a Book-E class processor, but while compiling
in the CONFIG_PPC_BOOK3E_64 and CONFIG_VIRTUALIZATION case, this
introduce the following error:
arch/powerpc/kernel/exceptions-64e.S:402: undefined reference to
On Thu, Apr 25, 2013 at 12:47:39PM +0200, Alexander Graf wrote:
On 25.04.2013, at 11:43, Gleb Natapov wrote:
On Fri, Apr 12, 2013 at 07:08:42PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
ow...@vger.kernel.org] On Behalf Of Tiejun Chen
Sent: Thursday, April 25, 2013 2:46 PM
To: ga...@kernel.crashing.org
Cc: linuxppc-...@lists.ozlabs.org; kvm-...@vger.kernel.org;
kvm@vger.kernel.org
Subject:
On 24/04/13 17:55, Christoffer Dall wrote:
On Wed, Apr 24, 2013 at 4:03 AM, Marc Zyngier marc.zyng...@arm.com wrote:
On 23/04/13 23:58, Christoffer Dall wrote:
On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
Define the arm64 specific MMU backend:
- HYP/kernel VA offset
- S2
On 25.04.2013, at 14:07, Gleb Natapov wrote:
On Thu, Apr 25, 2013 at 12:47:39PM +0200, Alexander Graf wrote:
On 25.04.2013, at 11:43, Gleb Natapov wrote:
On Fri, Apr 12, 2013 at 07:08:42PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
On Thu, Apr 25, 2013 at 03:45:14PM +0200, Alexander Graf wrote:
Please move struct definitions and KVM_CREATE_DEVICE_TEST define out
from ioctl definition block.
Let me change that in my tree...
So are you sending this via your tree and I should not apply it directly?
I was hoping
On 25.04.2013, at 13:30, Alexander Graf wrote:
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM, Alexander Graf wrote:
Now that all pieces are in place for reusing generic irq infrastructure,
we can copy x86's implementation of KVM_IRQ_LINE irq injection and simply
On 23.04.2013, at 08:39, Bharat Bhushan wrote:
Kernel should only try flushing pages which are managed by kernel.
pfn_to_page will returns junk struct page for pages not managed by kernel,
so if kernel will try to flush direct mapped memory or direct assigned device
mapping then it will work
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, April 25, 2013 8:36 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
Bharat-R65777
Subject: Re: [PATCH] KVM : PPC : cache flush for kernel
On Thu, Apr 25, 2013 at 5:59 AM, Marc Zyngier marc.zyng...@arm.com wrote:
On 24/04/13 17:55, Christoffer Dall wrote:
On Wed, Apr 24, 2013 at 4:03 AM, Marc Zyngier marc.zyng...@arm.com wrote:
On 23/04/13 23:58, Christoffer Dall wrote:
On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier
From: Bharat Bhushan bharat.bhus...@freescale.com
Kernel can only access pages which maps as memory.
So flush only the valid kernel pages.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2
- move pfn_valid() check in kvmppc_mmu_flush_icache
- Added comment to describe why
On 04/25/2013 05:47:39 AM, Alexander Graf wrote:
On 25.04.2013, at 11:43, Gleb Natapov wrote:
+void kvm_device_put(struct kvm_device *dev)
+{
+ if (atomic_dec_and_test(dev-users))
+ dev-ops-destroy(dev);
+}
+
+static int kvm_device_release(struct inode *inode, struct
On 04/25/2013 04:58:51 AM, Alexander Graf wrote:
On 19.04.2013, at 20:02, Scott Wood wrote:
On 04/19/2013 09:06:26 AM, Alexander Graf wrote:
+ if (notify_eoi != -1) {
+ spin_unlock_irq(opp-lock);
+ kvm_notify_acked_irq(opp-kvm, 0, notify_eoi);
+
On Thu, Apr 25, 2013 at 11:51:08AM -0500, Scott Wood wrote:
On 04/25/2013 05:47:39 AM, Alexander Graf wrote:
On 25.04.2013, at 11:43, Gleb Natapov wrote:
+void kvm_device_put(struct kvm_device *dev)
+{
+ if (atomic_dec_and_test(dev-users))
+ dev-ops-destroy(dev);
+}
+
On 04/25/2013 01:22:04 PM, Gleb Natapov wrote:
On Thu, Apr 25, 2013 at 11:51:08AM -0500, Scott Wood wrote:
On 04/25/2013 05:47:39 AM, Alexander Graf wrote:
On 25.04.2013, at 11:43, Gleb Natapov wrote:
+void kvm_device_put(struct kvm_device *dev)
+{
+ if
On 04/25/2013 09:49:23 AM, Alexander Graf wrote:
On 25.04.2013, at 13:30, Alexander Graf wrote:
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM, Alexander Graf wrote:
Now that all pieces are in place for reusing generic irq
infrastructure,
we can copy x86's
On 25.04.2013, at 21:03, Scott Wood wrote:
On 04/25/2013 09:49:23 AM, Alexander Graf wrote:
On 25.04.2013, at 13:30, Alexander Graf wrote:
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM, Alexander Graf wrote:
Now that all pieces are in place for reusing generic
From: Borislav Petkov b...@suse.de
It is exit_int_info. It is actually EXITINTINFO in the official docs
but we don't like screaming docs.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c
If a group or device is released or a container is unset from a group
it can race against file ops on the container. Protect these with
down_reads to allow concurrent users.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Reported-by: Michael S. Tsirkin m...@redhat.com
---
Michael Tsirkin pointed out that file operations on /dev/vfio/vfio
dereference iommu_driver and iommu_data without a lock. If releasing
a group or unsetting the container occurs concurrently, we could race.
We currently use a mutex when setting this association, so we can
convert to a rwsem
All current users are writers, maintaining current mutual exclusion.
This lets us add read users next.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/vfio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git
From: Borislav Petkov b...@suse.de
Date: Tue, 16 Apr 2013 18:24:34 +0200
Subject: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm. Instead of going and searching for each
required option
We no longer need to keep track of this now that MPIC destruction
always happens either during VM destruction (after MMIO has been
destroyed) or during a failed creation (before the fd has been exposed
to userspace, and thus before the MMIO region could have been
registered).
Signed-off-by: Scott
The hassle of getting refcounting right was greater than the hassle
of keeping a list of devices to destroy on VM exit.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c |2 --
include/linux/kvm_host.h |3 ++-
virt/kvm/kvm_main.c | 29
On 04/25/2013 08:11 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
ow...@vger.kernel.org] On Behalf Of Tiejun Chen
Sent: Thursday, April 25, 2013 2:46 PM
To: ga...@kernel.crashing.org
Cc: linuxppc-...@lists.ozlabs.org;
On 04/25/2013 07:32 PM, Caraman Mihai Claudiu-B02008 wrote:
Is the flowing is fine with that generic machine, ppce500, to boot
P5040DS with
64bit,
./qemu-system-ppc64 -enable-kvm -m 1048 -nographic -M ppce500 -kernel
uImage
-initrd ramdisk.gz -L . -append root=/dev/ram rw console=ttyS0,115200
Hi Yang Zhang,
Could you please let me know your CPU model or the CPU models which supports
apic-v which your patch requires()? So that I could try you patches.
Intel Software Developer's Manualm, Volume 3C,
System Programming Guide, Part 3. Ch29,
APIC VIRTUALIZATION AND VIRTUAL
Yangminqiang wrote on 2013-04-26:
Hi Yang Zhang,
Could you please let me know your CPU model or the CPU models which
supports apic-v which your patch requires()? So that I could try you
patches.
Intel Software Developer's Manualm, Volume 3C,
System Programming Guide, Part 3. Ch29,
On Wed, Apr 24, 2013 at 01:20:31PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most of the code already is
perfectly
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Friday, April 19, 2013 1:03 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM: PPC: e500: Add e6500 core to Kconfig
description
On
On 04/25/2013 05:09 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Friday, April 19, 2013 1:03 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM:
On 25.04.2013, at 09:28, Gleb Natapov wrote:
On Wed, Apr 24, 2013 at 01:20:31PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most
On 21.04.2013, at 12:51, Michael S. Tsirkin wrote:
On Tue, Apr 16, 2013 at 07:26:08PM +0200, Alexander Graf wrote:
The concept of an irqfd and interrupt routing are nothing particularly tied
into the IOAPIC implementation. In fact, most of the code already is
perfectly
generic.
This
On Fri, Apr 12, 2013 at 07:08:42PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through
On 04/25/2013 05:32 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, April 25, 2013 12:17 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 8/8 v3] KVM:
On 19.04.2013, at 20:02, Scott Wood wrote:
On 04/19/2013 09:06:26 AM, Alexander Graf wrote:
diff --git a/Documentation/virtual/kvm/devices/mpic.txt
b/Documentation/virtual/kvm/devices/mpic.txt
index ce98e32..dadc1e0 100644
--- a/Documentation/virtual/kvm/devices/mpic.txt
+++
On 23.04.2013, at 08:38, Paul Mackerras wrote:
On Fri, Apr 19, 2013 at 04:06:26PM +0200, Alexander Graf wrote:
Now that all the irq routing and irqfd pieces are generic, we can expose
real irqchip support to all of KVM's internal helpers.
This allows us to use irqfd with the in-kernel
On Fri, Apr 19, 2013 at 04:06:12PM +0200, Alexander Graf wrote:
The concept of routing interrupt lines to an irqchip is nothing
that is IOAPIC specific. Every irqchip has a maximum number of pins
that can be linked to irq lines.
So let's add a new define that allows us to reuse generic code
On Fri, Apr 19, 2013 at 04:06:13PM +0200, Alexander Graf wrote:
Quite a bit of code in KVM has been conditionalized on availability of
IOAPIC emulation. However, most of it is generically applicable to
platforms that don't have an IOPIC, but a different type of irq chip.
Make code that only
On Fri, Apr 19, 2013 at 04:06:14PM +0200, Alexander Graf wrote:
We have a capability enquire system that allows user space to ask kvm
whether a feature is available.
The point behind this system is that we can have different kernel
configurations with different capabilities and user space
On Fri, Apr 19, 2013 at 04:06:16PM +0200, Alexander Graf wrote:
The IRQ routing set ioctl lives in the hacky device assignment code inside
of KVM today. This is definitely the wrong place for it. Move it to the much
more natural kvm_main.c.
Signed-off-by: Alexander Graf ag...@suse.de
1 - 100 of 123 matches
Mail list logo
