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
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
>> fol
gt; not possible. We can therefore claim that they support a
> subset of ACS.
>
> Signed-off-by: Alex Williamson
Tested-by: Andreas Hartmann
> Cc: Joerg Roedel
> ---
>
> Two things about this patch make me a little nervous. The
> first is that I'd really like to
Avi Kivity wrote:
> On 07/25/2012 10:53 PM, Alex Williamson wrote:
>> On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
>>> On 07/25/2012 08:03 PM, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver interface. After setting up VF
Avi Kivity schrieb:
> On 07/26/2012 12:28 PM, Andreas Hartmann wrote:
>> Avi Kivity wrote:
>>> On 07/25/2012 10:53 PM, Alex Williamson wrote:
>>>> On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
>>>>> On 07/25/2012 08:03 PM, Alex Williamson wrote:
Alex Williamson wrote:
[I removed qemu-devel because I'm not registered there]
> On Thu, 2012-07-26 at 19:40 +0300, Avi Kivity wrote:
>> On 07/26/2012 07:33 PM, Alex Williamson wrote:
In the common case, on x86 (but I'm repeating myself), the iommu group
includes just one device, y
Hello,
I managed to run this PCI (not PCIe(!)) device
06:07.0 Network controller [0280]: Ralink corp. RT2800 802.11n PCI [1814:0601]
Subsystem: Linksys Device [1737:0067]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
2012
(awilliam-qemu-vfio-v0.14.0-rc0-6402-g323cf9f.tar.gz). I didn't
encounter any problem so far.
If you like, I could compile a more actual version, too (if there have
been any changes).
To see more about my use case:
http://permalink.gmane.org/gmane.linux.drivers.rt2x00.user/1051
You may a
Alex Williamson schrieb:
> On Mon, 2012-08-13 at 17:48 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Mon, 2012-08-13 at 08:27 -0500, Anthony Liguori wrote:
>>>> Alex Williamson writes:
>>>>
>>>>> VFIO kernel support
Alex Williamson wrote:
> On Mon, 2012-08-13 at 18:36 +0200, Andreas Hartmann wrote:
[...]
>> If I'm using your qemu instead of qemu from kvm-0.15 (opensuse package),
>> this error comes up when passing through a PCIe device, which works
>> absolutely fine with kvm 0.15. I
er PCI slot as there are just 2 PCI slots on the board.)
2. Is there any fix to prevent the host crash - maybe in a newer version of kvm
or kernel?
Thank you very much for your help,
kind regards,
Andreas Hartmann
--
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
Am Mon, 12 Dec 2011 13:36:36 -0500
schrieb Don Dutile :
> On 12/12/2011 06:15 AM, Andreas Hartmann wrote:
> > Hello!
> >
> > I've got a few questions to a problem, which already was analyzed here
> > sometime ago:
> > http://markmail.org/message/dspovwvzp3wtd
Hello Don!
Am Tue, 13 Dec 2011 01:21:41 +0100
schrieb Andreas Hartmann :
> Am Mon, 12 Dec 2011 13:36:36 -0500
> schrieb Don Dutile :
>
> > On 12/12/2011 06:15 AM, Andreas Hartmann wrote:
> > > Hello!
> > >
> > > I've got a few question
Hello Don!
Some additional information about the bridge device 00:14.4 itself
(both legacy PCI cards are behind this bridge device - it's an output with both
legacy devices plugged in):
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
(prog-if 01 [Subtractive decode])
Hello Don!
Am Tue, 13 Dec 2011 01:21:41 +0100
schrieb Andreas Hartmann :
[...]
> Ok. If I remove the intel card and put in instead a 32 bit PCIe card
> like TP-Link TG-3468, I could assign each of these two cards to
> different VMs.
>
> Is this correct?
No - it isn't cor
Hello kvm-list!
I sent the following text to Don with some additional detailed log
files. If somebody else need them too, I can provide them with pn.
Kind regards,
Andreas Hartmann
Andreas Hartmann schrieb:
> Hello Don,
>
> thank you for your reply!
>
> I just want to descri
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 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
> >
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-x8
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
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.
>>
>> Y
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 previo
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
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
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 previ
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:
> > > [...]
> > > > Y
Alex Williamson wrote:
> Passes pci_intx_mask_supported but continues to send interrupts as
> discovered through VFIO-based device assignment.
>
> http://www.spinics.net/lists/kvm/msg73738.html
>
> Signed-off-by: Alex Williamson
Tested-by: Andreas Hartmann
> ---
>
Hello Alex,
what about a module parameter to achieve this behaviour manually by
the user without recompiling? I fear, there are much more candidates
out there needing this "feature".
Kind regards and thank you,
Andreas
Alex Williamson wrote:
> Passes pci_intx_mask_supported but continues to se
Alex Williamson wrote:
> On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote:
>> Hello Alex,
>>
>> what about a module parameter to achieve this behaviour manually by
>> the user without recompiling? I fear, there are much more candidates
>> out there
Alex Williamson wrote:
> On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote:
>>>> Hello Alex,
>>>>
>>>> what about a module parameter to ac
Alex Williamson wrote:
> On Thu, 2012-06-07 at 23:42 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote:
[...]
>>>> May I have please another question?
>>>> Unfortunately I can't c
Andreas Hartmann wrote:
> Alex Williamson wrote:
[...]
>> I just pushed a vfio-3.4 branch to my tree at
>> git://github.com/awilliam/linux-vfio.git. Please let me know what you
>> find with this.
>
> Works fine :-) vfio and fglrx and PCIe passthrough.
I rebuild the
Hi Dominic,
Dominic Eschweiler wrote:
> Am Freitag, den 08.06.2012, 08:16 -0600 schrieb Alex Williamson:
>> Yes, thanks Jan. This is exactly what VFIO does. VFIO provides
>> secure config space access, resource access, DMA mapping services, and
>> full interrupt support to userspace.
>
> I kn
Hello Alex,
You can probably say, what this message on host side means:
kernel: [ 3902.124109] vfio_dma_do_map: RLIMIT_MEMLOCK (65536) exceeded
The WLAN card in the VM doesn't work any more. It came up after a few
times of restarting the VM (with unbinding / rebinding - procedures).
I'll see if
Andreas Hartmann wrote:
> Hello Alex,
>
> You can probably say, what this message on host side means:
>
> kernel: [ 3902.124109] vfio_dma_do_map: RLIMIT_MEMLOCK (65536) exceeded
>
> The WLAN card in the VM doesn't work any more. It came up after a few
> tim
Alex Williamson wrote:
> On Fri, 2012-06-08 at 19:39 +0200, Andreas Hartmann wrote:
[...]
>> - What size should be used for ulimit -l?
>
> It should be about the size of memory assigned to the guest.
Ok, I'm using 256MB, this means, I should try to set ulimit -l to 256M
Alex Williamson wrote:
> On Fri, 2012-06-08 at 19:39 +0200, Andreas Hartmann wrote:
>> Andreas Hartmann wrote:
>>> Hello Alex,
>>>
>>> You can probably say, what this message on host side means:
>>>
>>> kernel: [ 3902.124109] vfio_dma_do_map:
Alex Williamson wrote:
> On Fri, 2012-06-08 at 18:16 +0200, Andreas Hartmann wrote:
[...]
>> Besides the problem with AMD IOMMU, which requires to unbind a whole
>> group of devices in some cases (PCI passthrough - not PCIe), it's really
>> cool! And it's usa
On Fri, 08 Jun 2012 11:35:07 -0600
Alex Williamson wrote:
> On Fri, 2012-06-08 at 18:58 +0200, Andreas Hartmann wrote:
> > Hello Alex,
> >
> > You can probably say, what this message on host side means:
> >
> > kernel: [ 3902.124109] vfio_dma_do_map: RLIMIT_ME
Andreas Hartmann wrote:
> On Fri, 08 Jun 2012 11:35:07 -0600
> Alex Williamson wrote:
[...]
>> I'm definitely curious if there's anything cumulative about the locked
>> memory problem above. Thanks,
>
> Ok, I managed to get it reproducible. I'll describ
Alex Williamson wrote:
> On Sat, 2012-06-09 at 15:42 +0200, Andreas Hartmann wrote:
>> On Fri, 08 Jun 2012 11:35:07 -0600
>> Alex Williamson wrote:
>>
>>> On Fri, 2012-06-08 at 18:58 +0200, Andreas Hartmann wrote:
>>>> Hello Alex,
>>>>
>
Alex Williamson wrote:
> On Sat, 2012-06-09 at 11:28 +0200, Andreas Hartmann wrote:
[...]
>> What's the risk of this patch? Machine crash? Data loss for an active
>> file in an application? Complete filesystem damage? The latter would be
>> worse.
>
> What we
Alex Williamson wrote:
> On Sat, 2012-06-09 at 18:25 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Sat, 2012-06-09 at 11:28 +0200, Andreas Hartmann wrote:
>>
>> [...]
>>
>>>> What's the risk of this patch? Machine crash
Andreas Hartmann wrote:
> Alex Williamson wrote:
>> On Sat, 2012-06-09 at 18:25 +0200, Andreas Hartmann wrote:
>>> Alex Williamson wrote:
>>>> On Sat, 2012-06-09 at 11:28 +0200, Andreas Hartmann wrote:
>>>
>>> [...]
>>>
>>>>&g
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
Hello!
I do have a question regarding the following VM (running on a linux
3.1.10 host with kvm 1.0). In the VM runs openSUSE 12.1 / 64bit.
The defined vnc interface is not used!
How much memory should this VM maximally use on the host (-> memory
usage of the kvm-qemu process), as long as the cu
Hello,
please, could somebody explain the difference in behaviour between
setting the boot option iommu=pt and not setting it?
I can see the following differences:
w/ iommu=pt:
[0.832946] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40
[0.883983] AMD-Vi: Initialized for Passthrough Mode
Bjorn Helgaas wrote:
> [fix Joerg's email address]
>
> On Tue, Jun 25, 2013 at 10:15 PM, Bjorn Helgaas wrote:
>> On Wed, Jul 11, 2012 at 11:18 PM, Alex Williamson
>> wrote:
>>> We've confirmed that peer-to-peer between these devices is
>>> not possible. We can therefore claim that they support
Alex Williamson wrote:
> On Wed, 2013-06-26 at 17:14 +0200, Andreas Hartmann wrote:
>> Bjorn Helgaas wrote:
>>> [fix Joerg's email address]
>>>
>>> On Tue, Jun 25, 2013 at 10:15 PM, Bjorn Helgaas wrote:
>>>> On Wed, Jul 11, 2012 at 11:18 PM, Al
d regards,
Andreas Hartmann
--
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
Alex Williamson wrote:
> On Thu, 2012-10-04 at 17:13 +0200, Andreas Hartmann wrote:
>> Hello Alex,
>>
>> I just tested vfio as part of linux 3.6 and detected, that it
>> doesn't work because of the following missing patch:
>>
>> http://news.gmane.or
ment about the peer-2-peer safety is
> true for all south-bridges that you can find in an AMD IOMMU capable
> system.
http://news.gmane.org/find-root.php?group=gmane.linux.kernel.pci&article=16422
I think, Joerg wrote clearly that there is no problem any more to apply
this patch. I run it since
52 matches
Mail list logo
