https://bugzilla.kernel.org/show_bug.cgi?id=77871
Bug ID: 77871
Summary: USB device passthrough to Virtual GUEST system from
Linux
Product: Virtualization
Version: unspecified
Kernel Version: 3.14.6 or 3.14.7
Hardware
On 6/24/2013 10:01 PM, Christoffer Dall wrote:
There are many other latency/perf. reqs for NFV related to RT,
essentially Guest must run near native. In the end it may turn out this
may need to be outside of main tree we'll see.
It doesn't sound like this will be the end result. Everything
On 6/25/2013 12:27 AM, Stuart Yoder wrote:
We should avoid creating an environment with important functionality
outside of the main tree, if at all possible.
Also, as we architect that generic infrastructure we need to keep in mind that
there are important use cases for doing I/O in user
On 6/15/2013 5:47 PM, Paolo Bonzini wrote:
Il 13/06/2013 11:19, Mario Smarduch ha scritto:
Updated Device Passthrough Patch.
- optimized IRQ-CPU-vCPU binding, irq is installed once
- added dynamic IRQ affinity on schedule in
- added documentation and few other coding recommendations.
Per
On Mon, Jun 24, 2013 at 10:08:08AM +0200, Mario Smarduch wrote:
On 6/15/2013 5:47 PM, Paolo Bonzini wrote:
Il 13/06/2013 11:19, Mario Smarduch ha scritto:
Updated Device Passthrough Patch.
- optimized IRQ-CPU-vCPU binding, irq is installed once
- added dynamic IRQ affinity on schedule
On Mon, Jun 24, 2013 at 3:01 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Jun 24, 2013 at 10:08:08AM +0200, Mario Smarduch wrote:
On 6/15/2013 5:47 PM, Paolo Bonzini wrote:
Il 13/06/2013 11:19, Mario Smarduch ha scritto:
Updated Device Passthrough Patch.
- optimized
Il 13/06/2013 11:19, Mario Smarduch ha scritto:
Updated Device Passthrough Patch.
- optimized IRQ-CPU-vCPU binding, irq is installed once
- added dynamic IRQ affinity on schedule in
- added documentation and few other coding recommendations.
Per earlier discussion VFIO is our target but we
Updated Device Passthrough Patch.
- optimized IRQ-CPU-vCPU binding, irq is installed once
- added dynamic IRQ affinity on schedule in
- added documentation and few other coding recommendations.
Per earlier discussion VFIO is our target but we like
something earlier to work with to tackle
Use the new iommu_commit() function in the KVM device
passthrough code.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
virt/kvm/iommu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 62a9caf..87ef85a 100644
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Florian Mickler flor...@mickler.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Florian Mickler flor...@mickler.org changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Jay Ren yongjie@intel.com changed:
What|Removed |Added
CC||yongjie@intel.com
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Rafael J. Wysocki r...@sisk.pl changed:
What|Removed |Added
CC||flor...@mickler.org,
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Summary: [VT-d] VT-d device passthrough fail to guest
Product: Virtualization
Version: unspecified
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
https://bugzilla.kernel.org/show_bug.cgi?id=29232
alex.william...@redhat.com changed:
What|Removed |Added
CC||alex.william...@redhat.com
On 11/16/2010 08:26 PM, Jan Kiszka wrote:
Am 16.11.2010 17:55, Marcelo Tosatti wrote:
On Mon, Nov 08, 2010 at 12:21:44PM +0100, Jan Kiszka wrote:
Nine patches (yeah, it's getting more and more) to improve classic
device assigment /wrt IRQs. Highlight is the last one that resolves the
On 11/16/2010 11:30 PM, Jan Kiszka wrote:
This is the rebased light version of the previous series, i.e. without
PCI-2.3-based IRQ masking or any SRCU conversion. PCI-2.3 support is
under rework to explore options for automatic mode switches.
Looks good, especially the threaded irq - a real
On Tue, Nov 16, 2010 at 10:30:01PM +0100, Jan Kiszka wrote:
This is the rebased light version of the previous series, i.e. without
PCI-2.3-based IRQ masking or any SRCU conversion. PCI-2.3 support is
under rework to explore options for automatic mode switches.
Jan Kiszka (6):
KVM: Clear
On Tue, Nov 16, 2010 at 10:30:01PM +0100, Jan Kiszka wrote:
This is the rebased light version of the previous series, i.e. without
PCI-2.3-based IRQ masking or any SRCU conversion. PCI-2.3 support is
under rework to explore options for automatic mode switches.
Jan Kiszka (6):
KVM: Clear
On Mon, Nov 08, 2010 at 12:21:44PM +0100, Jan Kiszka wrote:
Nine patches (yeah, it's getting more and more) to improve classic
device assigment /wrt IRQs. Highlight is the last one that resolves the
host IRQ sharing issue for all PCI 2.3 devices. Quite essential when
passing non-MSI-ready
Am 16.11.2010 17:55, Marcelo Tosatti wrote:
On Mon, Nov 08, 2010 at 12:21:44PM +0100, Jan Kiszka wrote:
Nine patches (yeah, it's getting more and more) to improve classic
device assigment /wrt IRQs. Highlight is the last one that resolves the
host IRQ sharing issue for all PCI 2.3 devices.
This is the rebased light version of the previous series, i.e. without
PCI-2.3-based IRQ masking or any SRCU conversion. PCI-2.3 support is
under rework to explore options for automatic mode switches.
Jan Kiszka (6):
KVM: Clear assigned guest IRQ on release
KVM: Switch assigned device IRQ
On Tue, 2010-11-16 at 22:30 +0100, Jan Kiszka wrote:
This is the rebased light version of the previous series, i.e. without
PCI-2.3-based IRQ masking or any SRCU conversion. PCI-2.3 support is
under rework to explore options for automatic mode switches.
Jan Kiszka (6):
KVM: Clear assigned
Nine patches (yeah, it's getting more and more) to improve classic
device assigment /wrt IRQs. Highlight is the last one that resolves the
host IRQ sharing issue for all PCI 2.3 devices. Quite essential when
passing non-MSI-ready devices like many USB host controllers.
As there were concerns
Four patches to improve classic device assigment /wrt IRQs. Highlight
is the last one that resolves the host IRQ sharing issue for all PCI 2.3
devices. Quite essential when passing non-MSI-ready devices like many
USB host controllers.
Changes in v2:
- Reworked IRQ forwarding path to use threaded
- Refactored PCI-2.3 patch (but still no control knob for shared mode -
is that a must?)
I think it's the prudent thing to do.
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Am 02.11.2010 18:11, Michael S. Tsirkin wrote:
- Refactored PCI-2.3 patch (but still no control knob for shared mode -
is that a must?)
I think it's the prudent thing to do.
What a pity...
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded
Three patches to improve classic device assigment /wrt IRQs. Highlight
is the last one that resolves the host IRQ sharing issue for all PCI 2.3
devices. Quite essential when passing non-MSI-ready devices like many
USB host controllers.
Jan Kiszka (3):
KVM: Fold assigned interrupt work into IRQ
Hi, All:
Is there any method to directly assign a device to Guest OS without VT-d?
Thanks
Mu--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Mu Lin (m...@juniper.net) wrote:
Is there any method to directly assign a device to Guest OS without VT-d?
Assuming you mean a PCI device, no, there isn't.
Without an IOMMU[1] you can't directly assign a PCI device to a guest
(nor is it safe). There have been patches floating around to
: Friday, May 28, 2010 12:33 PM
To: Mu Lin
Cc: kvm@vger.kernel.org
Subject: Re: device passthrough
* Mu Lin (m...@juniper.net) wrote:
Is there any method to directly assign a device to Guest OS
without VT-d?
Assuming you mean a PCI device, no, there isn't.
Without an IOMMU[1] you can't
* Mu Lin (m...@juniper.net) wrote:
Do you know where is the patch, I just need something quick and dirty
for now, my shining new board does have VT-d but the BIOS is not ready
yet, I want to have something working now.
Sorry, I don't have a handy pointer. You can search for either pv dma
Hi, Folks:
Could you provide pointer to the kvm device passthrough howto/FAQ?
I have two questions:
1. my host os, the Linux doesn't have the native device driver for some home
grown pci devices, the driver is in the guest os, does device passthrough work
in this case? Assuming I have VT-d
I'm trying to pass a pcie-device into a kvm guest. qemu-kvm is started
by libvirt with this command:
[...]
Failed to assign irq for hostdev0: Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Found out what was causing the issue:
Current
Chris Wright wrote:
* Hannes Reinecke (h...@suse.de) wrote:
Chris Wright wrote:
* Hannes Reinecke (h...@suse.de) wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features
* Hannes Reinecke (h...@suse.de) wrote:
Ah. So I'll have to shout at Alex Graf.
No problems there :-)
I like that, when in doubt, shout at Alex ;-)
thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
Am 29.03.2010 um 18:46 schrieb Chris Wright chr...@sous-sol.org:
* Hannes Reinecke (h...@suse.de) wrote:
Ah. So I'll have to shout at Alex Graf.
No problems there :-)
I like that, when in doubt, shout at Alex ;-)
Yep, whenever in doubt, just shout at me :).
Alex
--
To unsubscribe
Chris Wright wrote:
* Hannes Reinecke (h...@suse.de) wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB offloading etc
won't work.
Please send
* Hannes Reinecke (h...@suse.de) wrote:
Chris Wright wrote:
* Hannes Reinecke (h...@suse.de) wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB
Sheng Yang wrote:
On Wednesday 24 March 2010 23:54:15 Hannes Reinecke wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB offloading etc
won't work.
How
* Hannes Reinecke (h...@suse.de) wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB offloading etc
won't work.
Please send the relevant dmesg from
On 03/19/2010 12:46 AM, Fede wrote:
I'm currently working to enable vga passthrough in kvm.
assigned_dev_iomem_map: e_phys=1000 r_virt=0x7fa64af0e000 type=0
len=0200 region_num=3
kvm_register_phys_mem:580 memory: gpa: 1000, size: 200, uaddr:
7fa64af0e000, slot: 7,flags: 0
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB offloading etc
won't work.
lspci output of the device:
07:00.0 Ethernet controller: Intel Corporation 82599EB 10
On Wednesday 24 March 2010 23:54:15 Hannes Reinecke wrote:
Hi all,
I'm trying to setup a system with device-passthrough for
an ixgbe NIC.
The device itself seems to work, but it isn't using MSI-X.
So some more advanced features like DCB offloading etc
won't work.
How about lspci result
I'm currently working to enable vga passthrough in kvm.
This is a current git qemu-kvm run with some debug printings:
slash...@fidel ~/kvm/vms $ qemu-system-x86_64 -hda i386ubuntu904.img
-boot c -m 1024 -net nic -net user,hostfwd=tcp::-:22 -pcidevice
host=01:00.0
vm_register_phys_mem:580
somehow.
Possible problems I'd have to solve:
- According to
http://www.linux-kvm.org/wiki/images/d/d0/KvmForum2008$kdf2008_14.pdf
PCI device passthrough needs a CPU with VT-d/IOMMU support.
- http://www.linux-kvm.org/page/TODO says passthrough won't work for
conventional PCI devices (I assume
I'm interested in and log the accesses
somehow.
Possible problems I'd have to solve:
- According to
http://www.linux-kvm.org/wiki/images/d/d0/KvmForum2008$kdf2008_14.pdf
PCI device passthrough needs a CPU with VT-d/IOMMU support.
- http://www.linux-kvm.org/page/TODO says passthrough won't work
On Wed, 2009-05-06 at 11:51 +0800, Sheng Yang wrote:
On Wednesday 06 May 2009 01:45:47 Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 04:28 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 03:43 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao
On Tue, 2009-05-05 at 03:43 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao wrote:
Hi,
The VF also works in the host if the VF driver is programed properly.
So it would be easier to develop the VF driver in the host and then
verify the VF driver in the
On Tue, 2009-05-05 at 04:28 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 03:43 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao wrote:
Hi,
The VF also works in the host if the VF driver is programed properly.
So it would be easier to
On Tuesday 05 May 2009 18:43:46 Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao wrote:
Hi,
The VF also works in the host if the VF driver is programed properly.
So it would be easier to develop the VF driver in the host and then
verify the VF driver in the guest.
On Tuesday 05 May 2009 19:28:15 Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 03:43 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao wrote:
Hi,
The VF also works in the host if the VF driver is programed properly.
So it would be easier to develop
On Wednesday 06 May 2009 01:45:47 Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 04:28 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 03:43 -0700, Nicholas A. Bellinger wrote:
On Tue, 2009-05-05 at 09:42 +0800, Yu Zhao wrote:
Hi,
The VF also works in the host if
Joerg Roedel wrote:
Hi,
the two patchsets posted as reply to this email implement KVM device
passthrough support for AMD IOMMU hardware. The changes to the previous
posts are descibed below
The first patchset is version 4 of the generic iommu api patchset which
generalizes the VT-d functions
On Wed, Dec 10, 2008 at 02:22:08PM +, David Woodhouse wrote:
On Wed, 2008-12-10 at 15:11 +0100, Joerg Roedel wrote:
So now its open how this will be merged alltogether. We can merge it in
three steps (first from Dave's tree, then Avi and at last my IOMMU
updates which has to happen in
On Wed, 2008-12-10 at 19:42 +0100, Joerg Roedel wrote:
Ok, I add it, thanks. Who is the author, Mike or you?
Might as well attribute it to Mike; he spotted it.
--
dwmw2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo
Hi,
passing a device through to a guest I sometimes get the following WARN
message on the host:
Dec 8 12:28:52 astat kernel: [ 248.472109] WARNING: at
kernel/irq/manage.c:225 enable_irq+0x6b/0x90()
Dec 8 12:28:52 astat kernel: [ 248.472114] Unbalanced enable for IRQ 488
Dec 8 12:28:52
On Thu, Dec 04, 2008 at 06:21:42PM +0100, Joerg Roedel wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu.git
kvm-amd-iommu
FYI, I just updated the branch above. I added a cleanup function which
removes the devices from a protection domain before it is released.
Hi,
the two patchsets posted as reply to this email implement KVM device
passthrough support for AMD IOMMU hardware.
The first patchset is version 3 of the generic iommu api patchset which
generalizes the VT-d functions exported to KVM into a common api where
the AMD IOMMU code can plug
59 matches
Mail list logo
