From: Weidong Han [EMAIL PROTECTED]
In order to support multiple device assignment for KVM, this patch does
following main changes:
- extend dmar_domain to own multiple devices from different iommus,
use a bitmap of iommus to replace iommu pointer in dmar_domain.
- implement independent low
Hmm, I get these errors using git-am:
Applying VT-d: Support multiple device assignment for KVM
.dotest/patch:1344: space before tab in indent.
clflush_cache_range(addr, size);
.dotest/patch:1350: space before tab in indent
Sorry, this patch has style problem. I will update it and also split it to
smaller patches for easy reviewing.
Regards,
Weidong
'Joerg Roedel' wrote:
Hmm, I get these errors using git-am:
Applying VT-d: Support multiple device assignment for KVM
.dotest/patch:1344: space before tab
, this patch has style problem. I will update it and also split it to
smaller patches for easy reviewing.
Regards,
Weidong
'Joerg Roedel' wrote:
Hmm, I get these errors using git-am:
Applying VT-d: Support multiple device assignment for KVM
.dotest/patch:1344: space before tab in indent
these errors using git-am:
Applying VT-d: Support multiple device assignment for KVM
.dotest/patch:1344: space before tab in indent.
clflush_cache_range(addr, size);
.dotest/patch:1350: space before tab in indent.
clflush_cache_range(addr, size
It's developed based on commit 0f7d3ee6 on avi/master, but it still can be
applied on latest avi/master (commit 90755652).
Regards,
Weidong
Joerg Roedel wrote:
Hmm, I tried to apply this patch against avi/master and linus/master
but get merge conflicts. Where do these patches apply cleanly?
Avi Kivity wrote:
Han, Weidong wrote:
In order to support multiple device assignment for KVM, this patch
does following main changes:
- extend dmar_domain to own multiple devices from different
iommus, use a bitmap of iommus to replace iommu pointer in
dmar_domain.
- add a flag
(sorry for joining this late, I returned from a 3-week vacation this
monday)
On Tue, Oct 07, 2008 at 03:29:21PM +0200, Avi Kivity wrote:
Oh, I see it now. Different devices may need to go under different iommus.
This really feels like it should be handled by the iommu API. Users
shouldn't
Han, Weidong wrote:
It's hard to move kvm_vtd_domain inside current iommu API. It's kvm
specific. It's not elegant to include kvm_vtd_domain stuffs in native
VT-d code.
It's cleaner than adding knowledge of how the iommu works to kvm.
I think leave it in kvm side is more clean at this
Avi Kivity wrote:
Han, Weidong wrote:
It's hard to move kvm_vtd_domain inside current iommu API. It's kvm
specific. It's not elegant to include kvm_vtd_domain stuffs in native
VT-d code.
It's cleaner than adding knowledge of how the iommu works to kvm.
I will try to move kvm_vtd_domain
Han, Weidong wrote:
2.6.27 is out, so anything we do will be for 2.6.29.
Do you mean the VT-d patches which haven't been checked in won't be
pushed into 2.6.28?
Yes. The only exception is the guest interrupt sharing patch, which is
awaiting testing.
--
I have a truly marvellous
Avi Kivity wrote:
Han, Weidong wrote:
2.6.27 is out, so anything we do will be for 2.6.29.
Do you mean the VT-d patches which haven't been checked in won't be
pushed into 2.6.28?
Yes. The only exception is the guest interrupt sharing patch, which
is awaiting testing.
Ok, I
Avi Kivity wrote:
Han, Weidong wrote:
If we devolve this to the iommu API, the same io page table can be
shared by all iommus, so long as they all use the same page table
format.
I don't understand how to handle this by iommu API. Let me explain
my thoughts more clearly:
VT-d spec
Han, Weidong wrote:
There is a missed optimization here. Suppose we have two devices each
under a different iommu. With the patch, each will be in a different
dmar_domain and so will have a different page table. The amount of
memory used is doubled.
You cannot let two devices each
Han, Weidong wrote:
I don't want then to share dmar_domains (these are implementation
details anyway), just io page tables.
kvm --- something (owns io page table) --- dmar_domain (uses shared
io page table) --- device
Let dmar_domains share io page table is not allowed. VT-d spec
Avi Kivity wrote:
Han, Weidong wrote:
I don't want then to share dmar_domains (these are implementation
details anyway), just io page tables.
kvm --- something (owns io page table) --- dmar_domain (uses
shared io page table) --- device
Let dmar_domains share io page table is not
Avi Kivity wrote:
Han, Weidong wrote:
There is a missed optimization here. Suppose we have two devices
each under a different iommu. With the patch, each will be in a
different dmar_domain and so will have a different page table. The
amount of memory used is doubled.
You cannot let
Han, Weidong wrote:
Avi Kivity wrote:
Han, Weidong wrote:
I don't want then to share dmar_domains (these are implementation
details anyway), just io page tables.
kvm --- something (owns io page table) --- dmar_domain (uses
shared io page table) --- device
Let dmar_domains share
Han, Weidong wrote:
Oh, I see it now. Different devices may need to go under different
iommus.
This really feels like it should be handled by the iommu API. Users
shouldn't need to bother with it.
Why do you say it should be handled by iommu API?
Because the logic of which iommu
Avi Kivity wrote:
Han, Weidong wrote:
Oh, I see it now. Different devices may need to go under different
iommus.
This really feels like it should be handled by the iommu API. Users
shouldn't need to bother with it.
Why do you say it should be handled by iommu API?
Because the
Han, Weidong wrote:
If we devolve this to the iommu API, the same io page table can be
shared by all iommus, so long as they all use the same page table
format.
I don't understand how to handle this by iommu API. Let me explain my
thoughts more clearly:
VT-d spec says:
Han, Weidong wrote:
[Rebased the patch due to my mmio's patch (commit: 0d679782) was checked
in]
From 9e68fc762358cc44cfec3968ac5ec65324ce04d7 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Mon, 6 Oct 2008 14:02:18 +0800
Subject: [PATCH] Support multiple device assignment to
Zhang, Xiantao wrote:
Han, Weidong wrote:
#ifdef CONFIG_DMAR
int intel_iommu_found(void);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 73b7c52..7a3e1b6 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -293,6 +293,11 @@ struct
On Sat, Sep 27, 2008 at 02:28:03PM +0800, Han, Weidong wrote:
From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Sat, 27 Sep 2008 14:28:07 +0800
Subject: [PATCH] Support multiple device assignment to one guest
Current VT-d
Muli Ben-Yehuda wrote:
On Sat, Sep 27, 2008 at 02:28:03PM +0800, Han, Weidong wrote:
From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00
2001
From: Weidong Han [EMAIL PROTECTED]
Date: Sat, 27 Sep 2008 14:28:07 +0800
Subject: [PATCH] Support multiple device assignment to one
On Sun, Sep 28, 2008 at 02:43:26PM +0800, Han, Weidong wrote:
For pvdma, why each BDF will need its own domain for intra-guest
protection?
Because if more than one BDF shares an address space, BDFa will be
able to DMA to BDFb's buffers, and vice versa. The point of
intra-guest (not
On Sun, Sep 28, 2008 at 02:34:19PM +0800, Han, Weidong wrote:
I don't understand why this approach reduces IOTLB utility. How to
say unrelated devices with unrelated buffers competing for the same
resource? Multiple devices shares one page table should improve
IOTLB utility, because some
From f2f722515135d95016f2d2ab55cc2aaf23d2fd80 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Sat, 27 Sep 2008 14:28:07 +0800
Subject: [PATCH] Support multiple device assignment to one guest
Current VT-d patches in kvm only support one device assignment to one
guest due to
On Saturday, September 13, 2008 5:46 pm Avi Kivity wrote:
Amit Shah wrote:
Sorry for the resends; this one fixes two compile errors introduced by me
and a warning.
Applied both, thanks.
You can add my s-o-b to the IOMMU patch if you want Avi, it's fine with me if
you push those particular
Amit Shah wrote:
Sorry for the resends; this one fixes two compile errors introduced by me and a
warning.
Applied both, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line
These are based on the patches Weidong just sent, with some whitespace cleanups
and one checkpatch fix for the 2/2 patch.
Please apply.
Amit.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Aug 22, 2008 at 10:10:52AM +0300, Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM.
I've updated
Amit Shah wrote:
The following two patches contain VT-d support for device assignment for KVM
guests.
The first patch contains the changes that are required to the generic VT-d code.
The second patch contains the changes to KVM.
Since the last send, I've updated the 2nd patch to expose
* On Tuesday 26 Aug 2008 14:40:57 Avi Kivity wrote:
Amit Shah wrote:
The following two patches contain VT-d support for device assignment for
KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM
Amit Shah wrote:
-pcidevice dev=00:13.0,dma=iommu
Why not default to iommu if one is available?
I've set that as default now.
What should the parameter be to disable just the iommu? dma=noiommu looks
ugly.
dma=none ?
Or do we not want to disable an iommu at all (even for
Amit Shah wrote:
So long as there is no potential for performance or security impact,
having pvdma turned on automatically is better. We could still have
dma=noparavirt to disable it.
So we fail the hypercalls once the guest tries to contact us?
Yes. Also don't expose the feature
Muli Ben-Yehuda wrote:
On Sat, Aug 23, 2008 at 12:33:46PM +0300, Avi Kivity wrote:
So long as there is no potential for performance or security impact,
having pvdma turned on automatically is better. We could still have
dma=noparavirt to disable it.
pvdma has advantages and
* On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote:
Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM
Amit Shah wrote:
* On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote:
Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains
* On Saturday 23 Aug 2008 15:03:46 Avi Kivity wrote:
Amit Shah wrote:
* On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote:
Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required
On Fri, Aug 22, 2008 at 10:10:52AM +0300, Amit Shah wrote:
The second patch contains the changes to KVM.
I've updated the 2nd patch to use VT-d only when requested by a
parameter on the command line, making it easier to support iommu
with pvdma and multiple iommu types.
The command line
* On Saturday 23 Aug 2008 15:27:47 Muli Ben-Yehuda wrote:
On Fri, Aug 22, 2008 at 10:10:52AM +0300, Amit Shah wrote:
The second patch contains the changes to KVM.
I've updated the 2nd patch to use VT-d only when requested by a
parameter on the command line, making it easier to support
On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote:
The authorship info and the commit log stays the same; just contains
my signoff.
Actually, unless you add an explicit 'From:' header, the email From
header is used by git as the author of the patch.
Cheers,
Muli
--
Workshop on I/O
* On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote:
On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote:
The authorship info and the commit log stays the same; just contains
my signoff.
Actually, unless you add an explicit 'From:' header, the email From
header is used by git as
On Sat, Aug 23, 2008 at 04:41:02PM +0530, Amit Shah wrote:
* On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote:
On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote:
The authorship info and the commit log stays the same; just contains
my signoff.
Actually, unless you add an
* On Saturday 23 Aug 2008 17:41:32 Muli Ben-Yehuda wrote:
On Sat, Aug 23, 2008 at 04:41:02PM +0530, Amit Shah wrote:
* On Saturday 23 Aug 2008 16:10:54 Muli Ben-Yehuda wrote:
On Sat, Aug 23, 2008 at 03:55:25PM +0530, Amit Shah wrote:
The authorship info and the commit log stays the same;
On Fri, 22 Aug 2008, Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM.
I've updated the 2nd patch to use VT-d
* On Friday 22 Aug 2008 19:24:13 Byron Stanoszek wrote:
On Fri, 22 Aug 2008, Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch
On Fri, Aug 22, 2008 at 09:54:13AM -0400, Byron Stanoszek wrote:
Is it possible to log any physical PCI accesses from the guest?
This could be handy for reverse-engineering device drivers, among
other things.
With PCI passthrough It is possible in theory to log mmio's and pio's
executed by
Amit Shah wrote:
The following two patches contain VT-d support for device assignment
for KVM guests.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM.
I've updated the 2nd patch to use VT-d only when requested
On Fri, Aug 22, 2008 at 09:12:32PM +0300, Avi Kivity wrote:
Muli Ben-Yehuda wrote:
With PCI passthrough It is possible in theory to log mmio's and pio's
executed by the guest, as well as interrupts delivered to the guest,
although it will have a performance impact. It is not possible to log
On Fri, Aug 22, 2008 at 09:21:15PM +0300, Avi Kivity wrote:
You mean, iommu=on.
Agreed. This should also be the default if not dma=xxx is specfied and
a capable IOMMU is found.
Or rather
dma=iommu
dma=none (1:1 mapping, or dma-less devices, or I'm Feeling Lucky)
dma=cooperative
On Fri, Aug 22, 2008 at 09:02:33PM +0530, Amit Shah wrote:
All the PCI accesses happen from the userspace components in qemu;
it's certainly possible to log activity.
Actually, with direct-mmio we bypass QEMU and get a nice boost in
performance, and it should be possible to bypass QEMU for
On Fri, Aug 22, 2008 at 09:37:16PM +0300, Avi Kivity wrote:
Actually, with direct-mmio we bypass QEMU and get a nice boost in
performance, and it should be possible to bypass QEMU for (most)
PIO's too.
Since there is no pio remapping, there's no way to ensure there's a
free pio range
Avi,
I am re-sending the VT-d patches, please apply.
The following two patches contains the VT-d support for device
assignment.
The first patch contains the changes that are required to the generic
VT-d code.
The second patch contains the changes to KVM.
Regards,
Ben
--
To unsubscribe from
55 matches
Mail list logo
