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/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 i
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. Ev
On Mon, Jun 24, 2013 at 3:01 PM, Christoffer Dall
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 Pas
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
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 d
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 discu
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
Use the new iommu_commit() function in the KVM device
passthrough code.
Signed-off-by: Joerg Roedel
---
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
--- a/virt/kvm/iommu.c
+++ b
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Florian Mickler changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Florian Mickler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Jay Ren changed:
What|Removed |Added
CC||yongjie@intel.com
--- Comment #2 from J
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Rafael J. Wysocki changed:
What|Removed |Added
CC||flor...@mickler.org,
https://bugzilla.kernel.org/show_bug.cgi?id=29232
alex.william...@redhat.com changed:
What|Removed |Added
CC||alex.william...@redhat.com
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
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: Cl
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: Cl
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 wi
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 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 ass
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 forw
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 devi
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
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 reg
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 Embedd
> - 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 http://vge
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 threade
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
* 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
sol.org]
> Sent: 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 P
* 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 allo
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
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
> 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
Hi,
I'm trying to pass a pcie-device into a kvm guest. qemu-kvm is started
by libvirt with this command:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root
QEMU_AUDIO_DRV=none
/usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 2048 -smp
2,sockets=2,cores=1,threads=1 -nam
Am 29.03.2010 um 18:46 schrieb Chris Wright :
* 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 from this list: send
* 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 ma
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 ix
* 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
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 advanc
* 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.
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 a
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
&g
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 Corpora
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
c
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 mem
ssthrough for the PCI device 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 sup
esses
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 devi
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,
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
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 easie
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
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 e
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
On Wed, Dec 10, 2008 at 06:48:23PM +, David Woodhouse wrote:
> 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.
Ok, here is what I applied, fyi.
--
| A
Joerg Roedel wrote:
> 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 upd
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 majordo
On Wed, Dec 10, 2008 at 06:24:35PM +, David Woodhouse wrote:
> On Wed, 2008-12-10 at 15:25 +0100, Joerg Roedel wrote:
> > I already did it on-top of your tree because Han Weidong's patches 1-17
> > were rebased to your tree and my IOMMU-API patches apply on-top of his
> > patches.
>
> OK, than
On Wed, 2008-12-10 at 15:25 +0100, Joerg Roedel wrote:
> I already did it on-top of your tree because Han Weidong's patches 1-17
> were rebased to your tree and my IOMMU-API patches apply on-top of his
> patches.
OK, thanks. Looks like you still need this though, as Mike Day pointed
out:
diff --g
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 happe
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 that order).
The other option is to merge this all with one pull-request I send to
Linus. It should not con
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 that order).
> The other option is to merge this all with one pull-r
On Wed, Dec 10, 2008 at 11:36:16AM +0200, Avi Kivity wrote:
> 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 b
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
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 exported to KVM into a
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.
J
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 astat
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 into
68 matches
Mail list logo