From: Joerg Roedel jroe...@suse.de
This code only runs when action == BUS_NOTIFY_REMOVED_DEVICE,
so it can't be BUS_NOTIFY_DEL_DEVICE.
Signed-off-by: Joerg Roedel jroe...@suse.de
---
drivers/iommu/intel-iommu.c | 8
1 file changed, 8 deletions(-)
diff --git
From: Joerg Roedel jroe...@suse.de
Since commit 1196c2f a domain is only destroyed in the
notifier path if it is hot-unplugged. This caused a
domain leakage in iommu_attach_device when a driver was
unbound from the device and bound to VFIO. In this case the
device is attached to a new domain and
On Wed, Dec 17, 2014 at 12:19:45AM +, Laurent Pinchart wrote:
On Monday 15 December 2014 11:32:52 Will Deacon wrote:
On Sun, Dec 14, 2014 at 03:51:13PM +, Laurent Pinchart wrote:
On Monday 01 December 2014 16:57:12 Will Deacon wrote:
+ of_dma_configure(dev-dev);
On Tue, Dec 16, 2014 at 12:08:15PM +, Arnd Bergmann wrote:
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
Using a single domain is a bit of a waste of resources in my case, so an
evolution would be to create four domains and assign devices to them
based on
a policy. The
On Wednesday 17 December 2014 12:09:49 Will Deacon wrote:
On Tue, Dec 16, 2014 at 12:08:15PM +, Arnd Bergmann wrote:
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
Using a single domain is a bit of a waste of resources in my case, so
an
evolution would be to create
Hi Will,
On 17/12/14 12:09, Will Deacon wrote:
On Tue, Dec 16, 2014 at 12:08:15PM +, Arnd Bergmann wrote:
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
Using a single domain is a bit of a waste of resources in my case, so an
evolution would be to create four domains and assign
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver from being compiled as a module can't we just
rely on deferred probing ? The bus master driver will just be reprobed after
the IOMMU gets probed, like for other devices.
This could fail in case
Hi Arnd,
On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver from being compiled as a module can't we
just rely on deferred probing ? The bus master driver will just be
reprobed after the
On Wed, Dec 17, 2014 at 02:27:30PM +, Robin Murphy wrote:
On 17/12/14 12:09, Will Deacon wrote:
On Tue, Dec 16, 2014 at 12:08:15PM +, Arnd Bergmann wrote:
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
Using a single domain is a bit of a waste of resources in my case, so an
Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver from being compiled as a module can't we just
rely on deferred probing ? The bus master driver will just be reprobed
after
the
On Wednesday 17 December 2014 15:01:58 Will Deacon wrote:
On Wed, Dec 17, 2014 at 02:27:30PM +, Robin Murphy wrote:
On 17/12/14 12:09, Will Deacon wrote:
I think that's a slightly different case. The `grouping' in the DT, is on
a
per-master basis where a master may have a set of
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver from being compiled as a module can't we
just rely on deferred probing
On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote:
Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver from being compiled as a module can't we
just
rely on deferred
Hi Arnd,
On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
If we forbid the IOMMU driver
On 12/12/2014 16:14, Feng Wu wrote:
This patch updates the Posted-Interrupts Descriptor when vCPU
is blocked.
pre-block:
- Add the vCPU to the blocked per-CPU list
- Clear 'SN'
Should SN be already clear (and NV set to POSTED_INTR_VECTOR)? Can it
happen that you go from sched-out to
On 12/12/2014 16:14, Feng Wu wrote:
+ if (irq_remapping_cap(IRQ_POSTING_CAP)) {
+ struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+ struct pi_desc old, new;
+ unsigned int dest;
+
+ memset(old, 0, sizeof(old));
+ memset(new,
On Wed, Dec 17, 2014 at 03:35:29PM +, Arnd Bergmann wrote:
On Wednesday 17 December 2014 14:45:18 Will Deacon wrote:
On Wed, Dec 17, 2014 at 02:15:12PM +, Arnd Bergmann wrote:
On Wednesday 17 December 2014 12:09:49 Will Deacon wrote:
The icky part is that an ARM SMMU can have one
On Wed, Dec 17, 2014 at 03:38:22PM +, Arnd Bergmann wrote:
On Wednesday 17 December 2014 15:01:58 Will Deacon wrote:
On Wed, Dec 17, 2014 at 02:27:30PM +, Robin Murphy wrote:
I thoroughly dislike the idea, but one /could/ simply abuse the generic
bindings well within the current
On 12/12/2014 16:14, Feng Wu wrote:
Make kvm_set_msi_irq() public, we can use this function outside.
Signed-off-by: Feng Wu feng.wu-ral2jqcrhueavxtiumw...@public.gmane.org
---
include/linux/kvm_host.h | 2 ++
virt/kvm/irq_comm.c | 2 +-
2 files changed, 3 insertions(+), 1
On 12/12/2014 16:14, Feng Wu wrote:
Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.
Can this happen? If the vcpu is in guest mode, it cannot have been
scheduled out, and that's the only
On Wed, Dec 17, 2014 at 11:43:36AM +0100, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
Since commit 1196c2f a domain is only destroyed in the
notifier path if it is hot-unplugged. This caused a
domain leakage in iommu_attach_device when a driver was
unbound from the device and
On Wed, Dec 17, 2014 at 11:43:37AM +0100, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
This code only runs when action == BUS_NOTIFY_REMOVED_DEVICE,
so it can't be BUS_NOTIFY_DEL_DEVICE.
Signed-off-by: Joerg Roedel jroe...@suse.de
---
drivers/iommu/intel-iommu.c | 8
On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote:
On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
On Wednesday 17 December 2014 01:24:42
Hi Arnd,
On Wednesday 17 December 2014 22:58:47 Arnd Bergmann wrote:
On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote:
On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
On Wednesday 17 December 2014
On Wednesday, December 17, 2014 02:15:31 AM Laurent Pinchart wrote:
Hi Tomasz,
On Tuesday 16 December 2014 11:18:33 Tomasz Figa wrote:
On Tue, Dec 16, 2014 at 4:53 AM, Laurent Pinchart wrote:
On Monday 15 December 2014 11:39:01 Tomasz Figa wrote:
On Sat, Dec 13, 2014 at 5:47 AM,
-Original Message-
From: linux-kernel-ow...@vger.kernel.org
[mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Paolo Bonzini
Sent: Thursday, December 18, 2014 1:43 AM
To: Wu, Feng; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x...@kernel.org;
Gleb Natapov; Paolo Bonzini;
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Sent: Thursday, December 18, 2014 1:11 AM
To: Wu, Feng; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x...@kernel.org;
Gleb Natapov; Paolo Bonzini; dw...@infradead.org;
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Paolo Bonzini
Sent: Thursday, December 18, 2014 1:10 AM
To: Wu, Feng; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x...@kernel.org;
Gleb Natapov; Paolo Bonzini; dw...@infradead.org;
28 matches
Mail list logo
