- Original Message -
From: "Alex Williamson"
To: "Phil Daws"
Cc: kvm@vger.kernel.org
Sent: Wednesday, 4 December, 2013 6:46:18 PM
Subject: Re: KVM & PCI Passthrough
On Wed, 2013-12-04 at 18:08 +, Phil Daws wrote:
> Hello all,
>
> as performing s
On Wed, 2013-12-04 at 18:08 +, Phil Daws wrote:
> Hello all,
>
> as performing some tests in my lab with PCI pass-through and not really
> understanding it. Here is what I have done so far:
>
> lspci -nn:
>
> 06:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS
> 21
Hello all,
as performing some tests in my lab with PCI pass-through and not really
understanding it. Here is what I have done so far:
lspci -nn:
06:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2108
[Liberator] [1000:0079] (rev 05)
modprobe pci_stub
echo "1000 0079
https://bugzilla.kernel.org/show_bug.cgi?id=23692
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Wed, 2012-07-11 at 21:32 +0200, Andreas Hartmann wrote:
> Hello Joerg,
>
> Joerg Roedel wrote:
> > Hi Andreas,
> >
> > On Wed, Jul 11, 2012 at 04:26:30PM +0200, Andreas Hartmann wrote:
> >> May I please ask, if you meanwhile could get any information about
> >> potential peer-to-peer communica
Hello Joerg,
Joerg Roedel wrote:
> Hi Andreas,
>
> On Wed, Jul 11, 2012 at 04:26:30PM +0200, Andreas Hartmann wrote:
>> May I please ask, if you meanwhile could get any information about
>> potential peer-to-peer communication between the functions of the
>> following multifunction device:
>
> G
Hi Andreas,
On Wed, Jul 11, 2012 at 04:26:30PM +0200, Andreas Hartmann wrote:
> May I please ask, if you meanwhile could get any information about
> potential peer-to-peer communication between the functions of the
> following multifunction device:
Good news: I actually found the right person to
Hello Joerg,
Joerg Roedel wrote:
> On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote:
>> Joerg, the question is whether the multifunction device above allows
>> peer-to-peer between functions that could bypass the iommu. If not, we
>> can make it the first entry in device specific a
On Mon, Jun 25, 2012 at 07:55:55AM +0200, Andreas Hartmann wrote:
> Hello Joerg,
>
> Joerg Roedel wrote:
> > On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote:
> >> Joerg, the question is whether the multifunction device above allows
> >> peer-to-peer between functions that could byp
Hello Joerg,
Joerg Roedel wrote:
> On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote:
>> Joerg, the question is whether the multifunction device above allows
>> peer-to-peer between functions that could bypass the iommu. If not, we
>> can make it the first entry in device specific a
On Wed, 06 Jun 2012 10:39:30 -0600
Alex Williamson wrote:
> On Wed, 2012-06-06 at 10:12 +0200, Andreas Hartmann wrote:
> > On Tue, 05 Jun 2012 18:55:42 +0200
> > Andreas Hartmann wrote:
> >
> > > Alex Williamson wrote:
> > > [...]
> > > > Yep, I think the previous suggestion about reloading vfi
On Wed, 2012-06-06 at 10:12 +0200, Andreas Hartmann wrote:
> On Tue, 05 Jun 2012 18:55:42 +0200
> Andreas Hartmann wrote:
>
> > Alex Williamson wrote:
> > [...]
> > > Yep, I think the previous suggestion about reloading vfio_iommu_type1
> > > with allow_unsafe_interrupts=1 will solve it.
> >
> >
On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote:
> Joerg, the question is whether the multifunction device above allows
> peer-to-peer between functions that could bypass the iommu. If not, we
> can make it the first entry in device specific acs enabled function I
> proposed:
>
>
Andreas Hartmann wrote:
> On Wed, 6 Jun 2012 10:12:27 +0200
> Andreas Hartmann wrote:
>
>> On Tue, 05 Jun 2012 18:55:42 +0200
>> Andreas Hartmann wrote:
>>
>>> Alex Williamson wrote:
>>> [...]
Yep, I think the previous suggestion about reloading vfio_iommu_type1
with allow_unsafe_inter
On Wed, 6 Jun 2012 10:12:27 +0200
Andreas Hartmann wrote:
> On Tue, 05 Jun 2012 18:55:42 +0200
> Andreas Hartmann wrote:
>
> > Alex Williamson wrote:
> > [...]
> > > Yep, I think the previous suggestion about reloading vfio_iommu_type1
> > > with allow_unsafe_interrupts=1 will solve it.
> >
>
On Tue, 05 Jun 2012 18:55:42 +0200
Andreas Hartmann wrote:
> Alex Williamson wrote:
> [...]
> > Yep, I think the previous suggestion about reloading vfio_iommu_type1
> > with allow_unsafe_interrupts=1 will solve it.
>
> Yes! Works now. Success!
>
> Works means: Device is seen in VM. I could
On Tue, 2012-06-05 at 22:31 -0500, Chris Sanders wrote:
> > Great, glad to hear it. You can expect performance to get better once
> > we get this upstream. Interrupts are currently getting bounced through
> > Qemu which adds overhead. Eventually we'll accelerate them through KVM.
> > I'm still a
> Great, glad to hear it. You can expect performance to get better once
> we get this upstream. Interrupts are currently getting bounced through
> Qemu which adds overhead. Eventually we'll accelerate them through KVM.
> I'm still able to play static directly from the device using mplayer, so
>
On Tue, 2012-06-05 at 22:07 -0500, Chris Sanders wrote:
> Alex,
>
> This solution appears to be working for me as well on a GA-970-D3.
>
> I've been able to pass the Hauppauge 350 through to a Windows XP guest
> which has installed drivers and loaded it into my recording software
> (SageTV). I'v
Alex,
This solution appears to be working for me as well on a GA-970-D3.
I've been able to pass the Hauppauge 350 through to a Windows XP guest
which has installed drivers and loaded it into my recording software
(SageTV). I've got a few more things I want to clean up on my qemu
start command bu
test
On Tue, Jun 5, 2012 at 5:39 AM, Andreas Hartmann
wrote:
> Hello Alex,
>
> thanks for your efforts!
>
> Maybe, you already know that I'm suffering the same problem :-( with a
> GA-990XA-UD3 (990X chipset).
>
>
> On Mon, 04 Jun 2012 21:44:05 -0600
> Alex Williamson wrote:
> [...]
>> I have a
Alex Williamson wrote:
> On Tue, 2012-06-05 at 22:37 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote:
Alex Williamson wrote:
[...]
> Yep, I think the previous suggestion about reloading vfio_iommu_type1
> with
On Tue, 2012-06-05 at 22:37 +0200, Andreas Hartmann wrote:
> Alex Williamson wrote:
> > On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote:
> >> Alex Williamson wrote:
> >> [...]
> >>> Yep, I think the previous suggestion about reloading vfio_iommu_type1
> >>> with allow_unsafe_interrupts=1
Alex Williamson wrote:
> On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>> [...]
>>> Yep, I think the previous suggestion about reloading vfio_iommu_type1
>>> with allow_unsafe_interrupts=1 will solve it.
>>
>> Yes! Works now. Success!
>>
>> Works means: De
On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote:
> Alex Williamson wrote:
> [...]
> > Yep, I think the previous suggestion about reloading vfio_iommu_type1
> > with allow_unsafe_interrupts=1 will solve it.
>
> Yes! Works now. Success!
>
> Works means: Device is seen in VM. I couldn'
Alex Williamson wrote:
[...]
> Yep, I think the previous suggestion about reloading vfio_iommu_type1
> with allow_unsafe_interrupts=1 will solve it.
Yes! Works now. Success!
Works means: Device is seen in VM. I couldn't test it up to now, because
I don't have any driver in the VM for this dev
On Tue, 2012-06-05 at 17:58 +0200, Andreas Hartmann wrote:
> Andreas Hartmann wrote:
> [...]
> > I tried to run qemu-system-x86_64 but got this error on startup:
> >
> > qemu-system-x86_64: -device
> > vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to set
> > iommu for contai
Andreas Hartmann wrote:
[...]
> I tried to run qemu-system-x86_64 but got this error on startup:
>
> qemu-system-x86_64: -device
> vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to set
> iommu for container: Operation not permitted
>
> qemu-system-x86_64: -device
> vfio-pci
On Tue, 2012-06-05 at 17:17 +0200, Andreas Hartmann wrote:
> On Tue, 05 Jun 2012 08:27:05 -0600
> Alex Williamson wrote:
>
> > On Tue, 2012-06-05 at 12:39 +0200, Andreas Hartmann wrote:
> > > Hello Alex,
> > >
> > > thanks for your efforts!
> > >
> > > Maybe, you already know that I'm suffering
On Tue, 05 Jun 2012 08:27:05 -0600
Alex Williamson wrote:
> On Tue, 2012-06-05 at 12:39 +0200, Andreas Hartmann wrote:
> > Hello Alex,
> >
> > thanks for your efforts!
> >
> > Maybe, you already know that I'm suffering the same problem :-( with a
> > GA-990XA-UD3 (990X chipset).
>
> My system
On Tue, 2012-06-05 at 12:39 +0200, Andreas Hartmann wrote:
> Hello Alex,
>
> thanks for your efforts!
>
> Maybe, you already know that I'm suffering the same problem :-( with a
> GA-990XA-UD3 (990X chipset).
My system is a GA-990FXA-UD3, so just a slightly different version of
the chipset.
> On
Hello Alex,
thanks for your efforts!
Maybe, you already know that I'm suffering the same problem :-( with a
GA-990XA-UD3 (990X chipset).
On Mon, 04 Jun 2012 21:44:05 -0600
Alex Williamson wrote:
[...]
> I have a setup with an AMD 990FX system and a spare PVR-350 card that I
> installed to repr
On Mon, 2012-06-04 at 16:11 -0500, Chris Sanders wrote:
> Hello, I've been working for several days trying to get Pci
> Passthrough to work. So far the #kvm IRC channel has helped me with a
> few suggestions, though that hasn't yet solved the problem. I'm
> running CentOS 6.2 and was suggested I
Hi,
I have been trying to get the PCI pass through working on my Asus Crosshair IV
Formula motherboard.
The motherboard does support IOMMU (AMD-Vi), and IOMMU as well as SVM are
enabled in the BIOS.
PCI pass through does seem to work just fine when it comes to with built in
network device (Ma
On Wednesday 04 March 2009 09:15:57 Jason Kwon wrote:
> Chris Wright wrote:
> > * Jason Kwon (jk...@redback.com) wrote:
> >> pci :02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> >> IRQ handler type mismatch for IRQ 16
> >> current handler: uhci_hcd:usb3
> >
> > This is a shared interrupt
* Jason Kwon (jk...@redback.com) wrote:
> Does it make any difference whether the device is MSI-capable or not?
Well, does it work with msi2intx=0 kvm module parameter?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majo
Chris Wright wrote:
* Jason Kwon (jk...@redback.com) wrote:
pci :02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
IRQ handler type mismatch for IRQ 16
current handler: uhci_hcd:usb3
This is a shared interrupt (and pci device assignment will request a
non-shared interrupt). Are you usin
* Jason Kwon (jk...@redback.com) wrote:
> pci :02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> IRQ handler type mismatch for IRQ 16
> current handler: uhci_hcd:usb3
This is a shared interrupt (and pci device assignment will request a
non-shared interrupt). Are you using that usb host co
Chris Wright wrote:
* Jason Kwon (jk...@redback.com) wrote:
I am attempting to make use of '-pcidevice' on my system, but have run
into some problems. First, my setup:
Fedora 10 x86_64 host system
2.6.28.1-19.fc10 kernel from Koji
KVM-84
You mean both userspace and kernel module built exte
* Jason Kwon (jk...@redback.com) wrote:
> I am attempting to make use of '-pcidevice' on my system, but have run
> into some problems. First, my setup:
>
> Fedora 10 x86_64 host system
> 2.6.28.1-19.fc10 kernel from Koji
> KVM-84
You mean both userspace and kernel module built externally?
> %
Hello,
I am attempting to make use of '-pcidevice' on my system, but have run
into some problems. First, my setup:
Fedora 10 x86_64 host system
2.6.28.1-19.fc10 kernel from Koji
KVM-84
Debian Lenny guest VM
I am attempting to passthrough a Xilinx FPGA device to the Lenny guest.
No driver f
刘晓建 wrote:
> 2008-12-16，"Han, Weidong" wrote：
>> Pls note that multiple devices may share one page for their MMIO,
>> and they may be assigned to different guests, there is potential
>> isolation issue. So we don't allow to assign these devices.
>
> In my view, we can modify the get_real_device()
2008-12-16，"Han, Weidong" wrote：
>Pls note that multiple devices may share one page for their MMIO, and they may
> be
> assigned to different guests, there is potential isolation issue. So we don't
> allow to assign these devices.
In my view, we can modify the get_real_device() to open the file /
> In my view, we can modify the get_real_device() to open the file /dev/iomem to
> find out whether the "potential issue" is a real one, instead of disabling
> this
> feature all the times.
Sorry, I made a mistake. I mean the file /proc/iomem, not /dev/iomem.
Regards,
Xiaojian Liu
--
To unsubs
刘晓建 wrote:
> the following patches apply to KVM-79. however, just now I viewed the
> code in KVM-81, and saw the problem remains.
>
> when assigning a pci device to guest os, the qemu can not guarantee
> the device's virtual iomem address has the same page offset with the
> real one.
> for exampl
Xiaojian,
For generating the patches for kvm module, you needs to use kvm.git as
development tree instead of kvm's release tarball. The source files in release
tarball have been hacked before release out, and maybe different with kernel's.
So please clone kvm.git through git.kernel.org first
the KVM79 doesn't support the case of running pci passthrough on a machine w/o
VT-d. The following fixes it
---
diff -uNr kvm-79/kernel/x86/kvm_main.c kvm-79-fixed/kernel/x86/kvm_main.c
--- kvm-79/kernel/x86/kvm_main.c 2008-11-12 20:24:04.0 +0800
+++ kvm-79-fixed/kernel/x86/kvm_main.c 2008-
KVM doesn't permit the device's iomem size smaller than 1 page. In fact, this is
not necessary. For my via-rhine nic, the size of iomem is only 0x200, but we can
still use pci passthrough.
And, because un-page-aligned iomem is permitted, sanity check should be adjusted
too.
---
diff -uNr kvm-79/ker
the following patches apply to KVM-79. however, just now I viewed the code in
KVM-81, and saw the problem remains.
when assigning a pci device to guest os, the qemu can not guarantee the device's
virtual iomem address has the same page offset with the real one.
for example: in native linux, the th
* On Wednesday 05 Nov 2008 03:50:17 Chris Jones wrote:
> Muli,
>
> > The kind where you *do* have VT-d is now included in the kernel and
> > userspace trees, and should "just work" (tell us if it doesn't). You
> > should clone the kernel and userspace trees, verify that the device
> > assignment pa
Muli,
> The kind where you *do* have VT-d is now included in the kernel and
> userspace trees, and should "just work" (tell us if it doesn't). You
> should clone the kernel and userspace trees, verify that the device
> assignment patches are included in the userspace tree (they were
> applied just
On Thu, Oct 30, 2008 at 08:42:50AM -0700, David Brown wrote:
> Thanks, glad to know progress is being made. However, around here
> we're mostly an AMD shop and as far as I know they don't have a
> working IOMMU yet.
I believe it's working, just not shipping yet :-)
> Has there been any testing w
On Thu, Oct 30, 2008 at 5:26 AM, Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 29, 2008 at 05:44:54PM -0700, David Brown wrote:
>
>> I was wondering what the status of kvm pci passthrough is?
>> Especially the kind where I don't have vt-d? Where are the pa
On Wed, Oct 29, 2008 at 05:44:54PM -0700, David Brown wrote:
> I was wondering what the status of kvm pci passthrough is?
> Especially the kind where I don't have vt-d? Where are the parts to
> play with? Is there any documentation you can point me to?
Hi David,
The kind where yo
I was wondering what the status of kvm pci passthrough is? Especially
the kind where I don't have vt-d? Where are the parts to play with? Is
there any documentation you can point me to?
Thanks,
- David Brown
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
55 matches
Mail list logo
