Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

Thanks to Bronek and everyone else who gave me tips on solving this
networking issue.  I ditched Network Manager, and just used
systemd-networkd and this worked.

On Tue, Apr 19, 2016 at 4:40 AM, Bronek Kozicki  wrote:

> First xml is a network definition file - as said earlier, they are one way
> for managing libvirt networking, which I do not use. Meaning, you do not
> need it if you want to do it "Bronek's way". However you may need to ensure
> that qemu helper is defined in libvirt configuration - look my messages
> from past few days.
>
> Second xml is part of VM definition, a sibling to hostdev nodes etc. You
> can create this part in virt-manager GUI, no need to edit xml by hand -
> just make sure to select the bridge you have created.
>
>
>
> B.
>
>
>
> *From: *Garland Key
> *Sent: *Monday, 18 April 2016 23:41
> *To: *Bronek Kozicki
> *Cc: *vfio-users
> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
> article
> ‎
> Sorry to pester you with so many questions.  I appreciate your help.
> ‎
> *Where should the following configuration be placed?  What is the config
> filename and path?*
>
>
> I've done the same. Bridge created with NM and used by the VM. You
> should be able to just select the bridge device. That's the resulting
> XML for me:
>
> 
>   default
>   278badf4-d33e-493e-b604-083b3dcc2804
>   
>   
> 
> ‎
>
>
> *Is this placed into your VM XML via virsh?*
> ‎
> 
>   
>   
>   
>   
>function='0x0'/>
> 
>
> On Mon, Apr 18, 2016 at 5:57 PM, Bronek Kozicki  wrote:
>
>> For me setting up networking with an existing bridge "just works", I
>> wrote few days ago on this lis how I've set it up on my machine. Hint: I do
>> not use virsh "networks" capabilities at all - none defined (undefined the
>> default one) and none started. Just my, manually crafted bridge, explicitly
>> used in VM definitions.
>>
>>
>> B.
>>
>> *From: *Garland Key
>> *Sent: *Monday, 18 April 2016 22:21
>> *To: *Nicolas Roy-Renaud; vfio-users
>> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
>> article
>>
>> I'm an intermediate Linux user, so this this stuff can be complicated to
>> me sometimes.  Right now I'm having trouble setting up a network bridge
>> that virt-manager will recognize.  I've arrived at the conclusion that this
>> simply isn't possible on Arch.  That said, I can't find any documentation
>> on how to convince qemu to use an existing network bridge.  If you're
>> willing, please add this information as well.  If you already know how, any
>> pointers would be greatly appreciated.
>>
>> Best,
>> Garland
>>
>> On Mon, Apr 18, 2016 at 5:14 PM, Garland Key > > wrote:
>>
>>> Please add what to do if you have two identical GPUs.  Here is exactly
>>> what is needed to make it work.
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> */etc/modprobe.d/vfio.conf*
>>>
>>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> */sbin/vfio-pci-override-vga.sh*
>>>
>>> #!/bin/sh
>>>
>>> for i in $(find /sys/devices/pci* -name boot_vga); do
>>> if [ $(cat $i) -eq 0 ]; then
>>> GPU=$(dirname $i)
>>> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>>>echo "vfio-pci" > $GPU/driver_override
>>> if [ -d $AUDIO ]; then
>>> echo "vfio-pci" > $AUDIO/driver_override
>>> fi
>>> fi
>>> done
>>>
>>> modprobe -i vfio-pci
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
>>> linux*
>>>
>>> BINARIES="/usr/bin/find /usr/bin/dirname"
>>> FILES="/sbin/vfio-pci-override-vga.sh"
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> *Tested Hardware:*
&g

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Bronek Kozicki]

  First xml is a network definition file - as said earlier, they are one way for managing libvirt networking, which I do not use. Meaning, you do not need it if you want to do it "Bronek's way". However you may need to ensure that qemu helper is defined in libvirt configuration - look my messages from past few days.Second xml is part of VM definition, a sibling to hostdev nodes etc. You can create this part in virt-manager GUI, no need to edit xml by hand - just make sure to select the bridge you have created.B.From: Garland KeySent: Monday, 18 April 2016 23:41To: Bronek KozickiCc: vfio-usersSubject: Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article‎Sorry to pester you with so many questions.  I appreciate your help.‎Where should the following configuration be placed?  What is the config filename and path? I've done the same. Bridge created with NM and used by the VM. Youshould be able to just select the bridge device. That's the resultingXML for me:  default  278badf4-d33e-493e-b604-083b3dcc2804    ‎Is this placed into your VM XML via virsh?‎                                      On Mon, Apr 18, 2016 at 5:57 PM, Bronek Kozicki  wrote:  For me setting up networking with an existing bridge "just works", I wrote few days ago on this lis how I've set it up on my machine. Hint: I do not use virsh "networks" capabilities at all - none defined (undefined the default one) and none started. Just my, manually crafted bridge, explicitly used in VM definitions.B.From: Garland KeySent: Monday, 18 April 2016 22:21To: Nicolas Roy-Renaud; vfio-usersSubject: Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki articleI'm an intermediate Linux user, so this this stuff can be complicated to me sometimes.  Right now I'm having trouble setting up a network bridge that virt-manager will recognize.  I've arrived at the conclusion that this simply isn't possible on Arch.  That said, I can't find any documentation on how to convince qemu to use an existing network bridge.  If you're willing, please add this information as well.  If you already know how, any pointers would be greatly appreciated.Best,GarlandOn Mon, Apr 18, 2016 at 5:14 PM, Garland Key  wrote:Please add what to do if you have two identical GPUs.  Here is exactly what is needed to make it work.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  /etc/modprobe.d/vfio.conf    install vfio-pci /sbin/vfio-pci-override-vga.sh
    options vfio-pci disable_vga=1 allow_unsafe_interrupts=1- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /sbin/vfio-pci-override-vga.sh    #!/bin/sh

        for i in $(find /sys/devices/pci* -name boot_vga); do
            if [ $(cat $i) -eq 0 ]; then
                    GPU=$(dirname $i)
                    AUDIO=$(echo $GPU | sed -e "s/0$/1/")
                   echo "vfio-pci" > $GPU/driver_override
                    if [ -d $AUDIO ]; then
                            echo "vfio-pci" > $AUDIO/driver_override
                    fi
            fi
    done

        modprobe -i vfio-pci- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Add the following to /etc/mkinitcpio.conf and then run mkinitcpio -p linux    BINARIES="/usr/bin/find /usr/bin/dirname"    FILES="/sbin/vfio-pci-override-vga.sh"- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tested Hardware:Motherboard: Asus Sabertooth X99CPU: Intel Core i7-5930KGPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC EditionGPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC EditionRAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud 

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[thibaut noah]

Correct me if i'm wrong but i think the only thing you need to do in order
to have a bridge on the virtual machine is to create a bridge in your xml
with the  in it. (if you have a bridge
set on the host with said name of course)
If i'm right even the mac adress on it is rubbish and can be anything as
long as it can be a valid mac adress?

If that's the case what we need on a wiki is a simple how to do a bridge on
the host with something not cumbersome and easy to setup like netctl and an
example of a bridge as it should be in the xml, thus people could just copy
paste the code, modify the bridge name to their needs and have something
that works out of the box without bothering themselves.


2016-04-19 1:03 GMT+02:00 Nicolas Roy-Renaud <
nicolas.roy-renau...@ens.etsmtl.ca>:

> I'd put the networking stuff, synergy and all that into some sort of
> "Potential improvements" section and link to related pages instead, to
> avoid filling the vfio page with unrelated content for the sake of having
> an entire guide in one place.
>
> About the bridge, double-check the output of `ip a` or `networkctl` if
> you're using systemd-networkd, to make sure that your bridge is properly
> setup as the primary network interface and that nothing else is trying to
> use eth0/enp0s0.
>
> Nicolas
>
>
> On 2016-04-18 18:56, Garland Key wrote:
>
> I just tried this and as soon as I start the VM, my bridge on the host
> fails and defaults to the wired connection.
>
> I think that if the pci-passthrough wiki is going to talk about synergy as
> an input solution, then it should also discuss creating a bridge, since
> it's necessary in order to accomplish said goal.
>
> On Mon, Apr 18, 2016 at 6:22 PM, Jonas Camillus Jeppesen <
> jona...@sdu.dk> wrote:
>
>> On a fresh Arch install (no desktop environment, no network manager) I
>> added a bridge like this with systemd's networkd service:
>> https://wiki.archlinux.org/index.php/Systemd-networkd#DHCP_with_two_distinct_IP
>> . Then in virt-manager under network adapter I just choose "Specify shared
>> device name" as "Network source" and type in "br0" which is the name I gave
>> my bridge.
>>
>> This page is unnecessarily complicated it seems to me:
>> <https://wiki.archlinux.org/index.php/QEMU#Networking>
>> https://wiki.archlinux.org/index.php/QEMU#Networking
>>
>> The Arch wiki page on vfio isn't really about networking in qemu/kvm, but
>> a note could be added to visit the KVM and QEMU pages, and those could then
>> be updated to mention this systemd-networkd example.
>>
>> On 04/18/2016 11:57 PM, Bronek Kozicki wrote:
>>
>> For me setting up networking with an existing bridge "just works", I
>> wrote few days ago on this lis how I've set it up on my machine. Hint: I do
>> not use virsh "networks" capabilities at all - none defined (undefined the
>> default one) and none started. Just my, manually crafted bridge, explicitly
>> used in VM definitions.
>>
>>
>> B.
>>
>> *From: *Garland Key
>> *Sent: *Monday, 18 April 2016 22:21
>> *To: *Nicolas Roy-Renaud; vfio-users
>> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
>> article
>>
>> I'm an intermediate Linux user, so this this stuff can be complicated to
>> me sometimes.  Right now I'm having trouble setting up a network bridge
>> that virt-manager will recognize.  I've arrived at the conclusion that this
>> simply isn't possible on Arch.  That said, I can't find any documentation
>> on how to convince qemu to use an existing network bridge.  If you're
>> willing, please add this information as well.  If you already know how, any
>> pointers would be greatly appreciated.
>>
>> Best,
>> Garland
>>
>> On Mon, Apr 18, 2016 at 5:14 PM, Garland Key <
>> david.garland@gmail.com> wrote:
>>
>>> Please add what to do if you have two identical GPUs.  Here is exactly
>>> what is needed to make it work.
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> * /etc/modprobe.d/vfio.conf*
>>>
>>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> - - - -
>>>
>>> */sbin/vfio-pci-override-vga.sh*
>>>
>>> #!/bin/sh
>>>
>>> for i in $(find /sys/devices/pc

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

I'd put the networking stuff, synergy and all that into some sort of 
"Potential improvements" section and link to related pages instead, to 
avoid filling the vfio page with unrelated content for the sake of 
having an entire guide in one place.


About the bridge, double-check the output of `ip a` or `networkctl` if 
you're using systemd-networkd, to make sure that your bridge is properly 
setup as the primary network interface and that nothing else is trying 
to use eth0/enp0s0.


Nicolas

On 2016-04-18 18:56, Garland Key wrote:
I just tried this and as soon as I start the VM, my bridge on the host 
fails and defaults to the wired connection.


I think that if the pci-passthrough wiki is going to talk about 
synergy as an input solution, then it should also discuss creating a 
bridge, since it's necessary in order to accomplish said goal.


On Mon, Apr 18, 2016 at 6:22 PM, Jonas Camillus Jeppesen 
mailto:jona...@sdu.dk>> wrote:


On a fresh Arch install (no desktop environment, no network
manager) I added a bridge like this with systemd's networkd
service:

https://wiki.archlinux.org/index.php/Systemd-networkd#DHCP_with_two_distinct_IP
. Then in virt-manager under network adapter I just choose
"Specify shared device name" as "Network source" and type in "br0"
which is the name I gave my bridge.

This page is unnecessarily complicated it seems to me:
https://wiki.archlinux.org/index.php/QEMU#Networking

The Arch wiki page on vfio isn't really about networking in
qemu/kvm, but a note could be added to visit the KVM and QEMU
pages, and those could then be updated to mention this
systemd-networkd example.

On 04/18/2016 11:57 PM, Bronek Kozicki wrote:

For me setting up networking with an existing bridge "just
works", I wrote few days ago on this lis how I've set it up on my
machine. Hint: I do not use virsh "networks" capabilities at all
- none defined (undefined the default one) and none started. Just
my, manually crafted bridge, explicitly used in VM definitions.


B.

*From: *Garland Key
*Sent: *Monday, 18 April 2016 22:21
*To: *Nicolas Roy-Renaud; vfio-users
*Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch
wiki article


I'm an intermediate Linux user, so this this stuff can be
complicated to me sometimes. Right now I'm having trouble setting
up a network bridge that virt-manager will recognize.  I've
arrived at the conclusion that this simply isn't possible on
Arch.  That said, I can't find any documentation on how to
convince qemu to use an existing network bridge.  If you're
willing, please add this information as well.  If you already
know how, any pointers would be greatly appreciated.

Best,
Garland

On Mon, Apr 18, 2016 at 5:14 PM, Garland Key
mailto:david.garland@gmail.com>> wrote:

Please add what to do if you have two identical GPUs.  Here
is exactly what is needed to make it work.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
/
*/etc/modprobe.d/vfio.conf*/

install vfio-pci /sbin/vfio-pci-override-vga.sh
options vfio-pci disable_vga=1 allow_unsafe_interrupts=1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -

*//sbin/vfio-pci-override-vga.sh/*

#!/bin/sh

for i in $(find /sys/devices/pci* -name boot_vga); do
if [ $(cat $i) -eq 0 ]; then
GPU=$(dirname $i)
AUDIO=$(echo $GPU | sed -e "s/0$/1/")
   echo "vfio-pci" > $GPU/driver_override
if [ -d $AUDIO ]; then
echo "vfio-pci" >
$AUDIO/driver_override
fi
fi
done

modprobe -i vfio-pci

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -

Add the following to /*/etc/mkinitcpio.**conf*/and then run
*/mkinitcpio -p linux/**
*
BINARIES="/usr/bin/find /usr/bin/dirname"
FILES="/sbin/vfio-pci-override-vga.sh"

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -

*Tested Hardware:*

Motherboard: Asus Sabertooth X99
<https://www.asus.com/us/Motherboards/SABERTOOTH_X99/>
CPU: Intel Core i7-5930K

<http://ark.intel.com/products/82931/Intel-Core-i7-5930K-Processor-15M-Cache-up-to-3_70-GHz>
GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
<http://www.newegg.com/Product/Product.aspx?Item=N8

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

I just tried this and as soon as I start the VM, my bridge on the host
fails and defaults to the wired connection.

I think that if the pci-passthrough wiki is going to talk about synergy as
an input solution, then it should also discuss creating a bridge, since
it's necessary in order to accomplish said goal.

On Mon, Apr 18, 2016 at 6:22 PM, Jonas Camillus Jeppesen 
wrote:

> On a fresh Arch install (no desktop environment, no network manager) I
> added a bridge like this with systemd's networkd service:
> https://wiki.archlinux.org/index.php/Systemd-networkd#DHCP_with_two_distinct_IP
> . Then in virt-manager under network adapter I just choose "Specify shared
> device name" as "Network source" and type in "br0" which is the name I gave
> my bridge.
>
> This page is unnecessarily complicated it seems to me:
> https://wiki.archlinux.org/index.php/QEMU#Networking
>
> The Arch wiki page on vfio isn't really about networking in qemu/kvm, but
> a note could be added to visit the KVM and QEMU pages, and those could then
> be updated to mention this systemd-networkd example.
>
> On 04/18/2016 11:57 PM, Bronek Kozicki wrote:
>
> For me setting up networking with an existing bridge "just works", I wrote
> few days ago on this lis how I've set it up on my machine. Hint: I do not
> use virsh "networks" capabilities at all - none defined (undefined the
> default one) and none started. Just my, manually crafted bridge, explicitly
> used in VM definitions.
>
>
> B.
>
> *From: *Garland Key
> *Sent: *Monday, 18 April 2016 22:21
> *To: *Nicolas Roy-Renaud; vfio-users
> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
> article
>
> I'm an intermediate Linux user, so this this stuff can be complicated to
> me sometimes.  Right now I'm having trouble setting up a network bridge
> that virt-manager will recognize.  I've arrived at the conclusion that this
> simply isn't possible on Arch.  That said, I can't find any documentation
> on how to convince qemu to use an existing network bridge.  If you're
> willing, please add this information as well.  If you already know how, any
> pointers would be greatly appreciated.
>
> Best,
> Garland
>
> On Mon, Apr 18, 2016 at 5:14 PM, Garland Key 
> wrote:
>
>> Please add what to do if you have two identical GPUs.  Here is exactly
>> what is needed to make it work.
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> * /etc/modprobe.d/vfio.conf*
>>
>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */sbin/vfio-pci-override-vga.sh*
>>
>> #!/bin/sh
>>
>> for i in $(find /sys/devices/pci* -name boot_vga); do
>> if [ $(cat $i) -eq 0 ]; then
>> GPU=$(dirname $i)
>> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>>echo "vfio-pci" > $GPU/driver_override
>> if [ -d $AUDIO ]; then
>> echo "vfio-pci" > $AUDIO/driver_override
>> fi
>> fi
>> done
>>
>> modprobe -i vfio-pci
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
>> linux*
>>
>> BINARIES="/usr/bin/find /usr/bin/dirname"
>> FILES="/sbin/vfio-pci-override-vga.sh"
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> *Tested Hardware:*
>>
>> Motherboard: Asus Sabertooth X99
>> <https://www.asus.com/us/Motherboards/SABERTOOTH_X99/>
>> CPU: Intel Core i7-5930K
>> <http://ark.intel.com/products/82931/Intel-Core-i7-5930K-Processor-15M-Cache-up-to-3_70-GHz>
>> GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16820233709>
>>
>>
>> On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud <
>> nicolas.roy-renau...@ens.etsmt

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

Sorry to pester you with so many questions.  I appreciate your help.

*Where should the following configuration be placed?  What is the config
filename and path?*


> I've done the same. Bridge created with NM and used by the VM. You
> should be able to just select the bridge device. That's the resulting
> XML for me:
>
> 
>   default
>   278badf4-d33e-493e-b604-083b3dcc2804
>   
>   
> 
>
>
*Is this placed into your VM XML via virsh?*


  
  
  
  
  


On Mon, Apr 18, 2016 at 5:57 PM, Bronek Kozicki  wrote:

> For me setting up networking with an existing bridge "just works", I wrote
> few days ago on this lis how I've set it up on my machine. Hint: I do not
> use virsh "networks" capabilities at all - none defined (undefined the
> default one) and none started. Just my, manually crafted bridge, explicitly
> used in VM definitions.
>
>
> B.
>
> *From: *Garland Key
> *Sent: *Monday, 18 April 2016 22:21
> *To: *Nicolas Roy-Renaud; vfio-users
> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
> article
>
> I'm an intermediate Linux user, so this this stuff can be complicated to
> me sometimes.  Right now I'm having trouble setting up a network bridge
> that virt-manager will recognize.  I've arrived at the conclusion that this
> simply isn't possible on Arch.  That said, I can't find any documentation
> on how to convince qemu to use an existing network bridge.  If you're
> willing, please add this information as well.  If you already know how, any
> pointers would be greatly appreciated.
>
> Best,
> Garland
>
> On Mon, Apr 18, 2016 at 5:14 PM, Garland Key 
> wrote:
>
>> Please add what to do if you have two identical GPUs.  Here is exactly
>> what is needed to make it work.
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */etc/modprobe.d/vfio.conf*
>>
>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */sbin/vfio-pci-override-vga.sh*
>>
>> #!/bin/sh
>>
>> for i in $(find /sys/devices/pci* -name boot_vga); do
>> if [ $(cat $i) -eq 0 ]; then
>> GPU=$(dirname $i)
>> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>>echo "vfio-pci" > $GPU/driver_override
>> if [ -d $AUDIO ]; then
>> echo "vfio-pci" > $AUDIO/driver_override
>> fi
>> fi
>> done
>>
>> modprobe -i vfio-pci
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
>> linux*
>>
>> BINARIES="/usr/bin/find /usr/bin/dirname"
>> FILES="/sbin/vfio-pci-override-vga.sh"
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> *Tested Hardware:*
>>
>> Motherboard: Asus Sabertooth X99
>> <https://www.asus.com/us/Motherboards/SABERTOOTH_X99/>
>> CPU: Intel Core i7-5930K
>> <http://ark.intel.com/products/82931/Intel-Core-i7-5930K-Processor-15M-Cache-up-to-3_70-GHz>
>> GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16820233709>
>>
>>
>> On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud <
>> nicolas.roy-renau...@ens.etsmtl.ca> wrote:
>>
>>> I'm currently planning a full rewrite of the article on Arch wiki about
>>> PCI passthroughs
>>> <https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF> and, as
>>> per Arch wiki guidelines, I'm supposed get the approval of other users
>>> before undergoing such comlex edits. If anyone on this mailing list is an
>>> Arch wiki collaborator or frequent user, I would appreciate if you could 
>>> give
>>> me some feedback on the planned structure
>>> <https://wiki.archlinux.org/index.php/Talk:PCI_passthrough_

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

I found the

On Mon, Apr 18, 2016 at 5:57 PM, Bronek Kozicki  wrote:

> For me setting up networking with an existing bridge "just works", I wrote
> few days ago on this lis how I've set it up on my machine. Hint: I do not
> use virsh "networks" capabilities at all - none defined (undefined the
> default one) and none started. Just my, manually crafted bridge, explicitly
> used in VM definitions.
>
>
> B.
>
> *From: *Garland Key
> *Sent: *Monday, 18 April 2016 22:21
> *To: *Nicolas Roy-Renaud; vfio-users
> *Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki
> article
>
> I'm an intermediate Linux user, so this this stuff can be complicated to
> me sometimes.  Right now I'm having trouble setting up a network bridge
> that virt-manager will recognize.  I've arrived at the conclusion that this
> simply isn't possible on Arch.  That said, I can't find any documentation
> on how to convince qemu to use an existing network bridge.  If you're
> willing, please add this information as well.  If you already know how, any
> pointers would be greatly appreciated.
>
> Best,
> Garland
>
> On Mon, Apr 18, 2016 at 5:14 PM, Garland Key 
> wrote:
>
>> Please add what to do if you have two identical GPUs.  Here is exactly
>> what is needed to make it work.
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */etc/modprobe.d/vfio.conf*
>>
>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */sbin/vfio-pci-override-vga.sh*
>>
>> #!/bin/sh
>>
>> for i in $(find /sys/devices/pci* -name boot_vga); do
>> if [ $(cat $i) -eq 0 ]; then
>> GPU=$(dirname $i)
>> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>>echo "vfio-pci" > $GPU/driver_override
>> if [ -d $AUDIO ]; then
>> echo "vfio-pci" > $AUDIO/driver_override
>> fi
>> fi
>> done
>>
>> modprobe -i vfio-pci
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
>> linux*
>>
>> BINARIES="/usr/bin/find /usr/bin/dirname"
>> FILES="/sbin/vfio-pci-override-vga.sh"
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> *Tested Hardware:*
>>
>> Motherboard: Asus Sabertooth X99
>> <https://www.asus.com/us/Motherboards/SABERTOOTH_X99/>
>> CPU: Intel Core i7-5930K
>> <http://ark.intel.com/products/82931/Intel-Core-i7-5930K-Processor-15M-Cache-up-to-3_70-GHz>
>> GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
>> RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)
>> <http://www.newegg.com/Product/Product.aspx?Item=N82E16820233709>
>>
>>
>> On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud <
>> nicolas.roy-renau...@ens.etsmtl.ca> wrote:
>>
>>> I'm currently planning a full rewrite of the article on Arch wiki about
>>> PCI passthroughs
>>> <https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF> and, as
>>> per Arch wiki guidelines, I'm supposed get the approval of other users
>>> before undergoing such comlex edits. If anyone on this mailing list is an
>>> Arch wiki collaborator or frequent user, I would appreciate if you could 
>>> give
>>> me some feedback on the planned structure
>>> <https://wiki.archlinux.org/index.php/Talk:PCI_passthrough_via_OVMF#Page_rewrite>
>>> and propose additional sections or potential user mistakes to highlight. My
>>> primary objective here is to make most of what's on Alex Williamson's blog
>>> more straightforward and concise.
>>>
>>> I've already rewritten the first two sections ("Prerequisites" and
>>> "Setting up IOMMU"), and the rest of the article should essentially follow
>>> the same basic structure and style. Replies here or on the wiki's
>>> discussion page would be much appreciated.
>>>
>>> -Nicolas
>>>
>>> ___
>>> vfio-users mailing list
>>> vfio-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>
>>>
>>
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Jonas Camillus Jeppesen]

On a fresh Arch install (no desktop environment, no network manager) I 
added a bridge like this with systemd's networkd service: 
https://wiki.archlinux.org/index.php/Systemd-networkd#DHCP_with_two_distinct_IP 
. Then in virt-manager under network adapter I just choose "Specify 
shared device name" as "Network source" and type in "br0" which is the 
name I gave my bridge.


This page is unnecessarily complicated it seems to me: 
https://wiki.archlinux.org/index.php/QEMU#Networking


The Arch wiki page on vfio isn't really about networking in qemu/kvm, 
but a note could be added to visit the KVM and QEMU pages, and those 
could then be updated to mention this systemd-networkd example.


On 04/18/2016 11:57 PM, Bronek Kozicki wrote:
For me setting up networking with an existing bridge "just works", I 
wrote few days ago on this lis how I've set it up on my machine. Hint: 
I do not use virsh "networks" capabilities at all - none defined 
(undefined the default one) and none started. Just my, manually 
crafted bridge, explicitly used in VM definitions.



B.

*From: *Garland Key
*Sent: *Monday, 18 April 2016 22:21
*To: *Nicolas Roy-Renaud; vfio-users
*Subject: *Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki 
article



I'm an intermediate Linux user, so this this stuff can be complicated 
to me sometimes.  Right now I'm having trouble setting up a network 
bridge that virt-manager will recognize.  I've arrived at the 
conclusion that this simply isn't possible on Arch.  That said, I 
can't find any documentation on how to convince qemu to use an 
existing network bridge.  If you're willing, please add this 
information as well.  If you already know how, any pointers would be 
greatly appreciated.


Best,
Garland

On Mon, Apr 18, 2016 at 5:14 PM, Garland Key 
mailto:david.garland@gmail.com>> wrote:


Please add what to do if you have two identical GPUs.  Here is
exactly what is needed to make it work.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -
/
*/etc/modprobe.d/vfio.conf*/

install vfio-pci /sbin/vfio-pci-override-vga.sh
options vfio-pci disable_vga=1 allow_unsafe_interrupts=1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -

*//sbin/vfio-pci-override-vga.sh/*

#!/bin/sh

for i in $(find /sys/devices/pci* -name boot_vga); do
if [ $(cat $i) -eq 0 ]; then
GPU=$(dirname $i)
AUDIO=$(echo $GPU | sed -e "s/0$/1/")
   echo "vfio-pci" > $GPU/driver_override
if [ -d $AUDIO ]; then
echo "vfio-pci" > $AUDIO/driver_override
fi
fi
done

modprobe -i vfio-pci

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -

Add the following to /*/etc/mkinitcpio.**conf*/and then run
*/mkinitcpio -p linux/**
*
BINARIES="/usr/bin/find /usr/bin/dirname"
FILES="/sbin/vfio-pci-override-vga.sh"

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -

*Tested Hardware:*

Motherboard: Asus Sabertooth X99
<https://www.asus.com/us/Motherboards/SABERTOOTH_X99/>
CPU: Intel Core i7-5930K

<http://ark.intel.com/products/82931/Intel-Core-i7-5930K-Processor-15M-Cache-up-to-3_70-GHz>
GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
<http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
<http://www.newegg.com/Product/Product.aspx?Item=N82E16814125684>
RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)
<http://www.newegg.com/Product/Product.aspx?Item=N82E16820233709>


On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud
mailto:nicolas.roy-renau...@ens.etsmtl.ca>> wrote:

I'm currently planning a full rewrite of the article on Arch
wiki about PCI passthroughs
<https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF> and,
as per Arch wiki guidelines, I'm supposed get the approval of
other users before undergoing such comlex edits. If anyone on
this mailing list is an Arch wiki collaborator or frequent
user, I would appreciate if you could give me some feedback on
the planned structure

<https://wiki.archlinux.org/index.php/Talk:PCI_passthrough_via_OVMF#Page_rewrite>
and propose additional sections or potential user mistakes to
highlight. My primary objective here is to make most of what's
on Alex Williamson's blog more straightforward and concise.

I'

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Bronek Kozicki]

  For me setting up networking with an existing bridge "just works", I wrote few days ago on this lis how I've set it up on my machine. Hint: I do not use virsh "networks" capabilities at all - none defined (undefined the default one) and none started. Just my, manually crafted bridge, explicitly used in VM definitions.B.From: Garland KeySent: Monday, 18 April 2016 22:21To: Nicolas Roy-Renaud; vfio-usersSubject: Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki articleI'm an intermediate Linux user, so this this stuff can be complicated to me sometimes.  Right now I'm having trouble setting up a network bridge that virt-manager will recognize.  I've arrived at the conclusion that this simply isn't possible on Arch.  That said, I can't find any documentation on how to convince qemu to use an existing network bridge.  If you're willing, please add this information as well.  If you already know how, any pointers would be greatly appreciated.Best,GarlandOn Mon, Apr 18, 2016 at 5:14 PM, Garland Key  wrote:Please add what to do if you have two identical GPUs.  Here is exactly what is needed to make it work.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  /etc/modprobe.d/vfio.conf    install vfio-pci /sbin/vfio-pci-override-vga.sh
    options vfio-pci disable_vga=1 allow_unsafe_interrupts=1- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /sbin/vfio-pci-override-vga.sh    #!/bin/sh

        for i in $(find /sys/devices/pci* -name boot_vga); do
            if [ $(cat $i) -eq 0 ]; then
                    GPU=$(dirname $i)
                    AUDIO=$(echo $GPU | sed -e "s/0$/1/")
                   echo "vfio-pci" > $GPU/driver_override
                    if [ -d $AUDIO ]; then
                            echo "vfio-pci" > $AUDIO/driver_override
                    fi
            fi
    done

        modprobe -i vfio-pci- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Add the following to /etc/mkinitcpio.conf and then run mkinitcpio -p linux    BINARIES="/usr/bin/find /usr/bin/dirname"    FILES="/sbin/vfio-pci-override-vga.sh"- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tested Hardware:Motherboard: Asus Sabertooth X99CPU: Intel Core i7-5930KGPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC EditionGPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC EditionRAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud  wrote:
  

  
  
I'm currently planning a full rewrite of the
  article on Arch wiki about PCI passthroughs and, as per Arch
wiki guidelines, I'm supposed get the approval of other users before
undergoing such comlex edits. If anyone on this mailing list is an
Arch wiki collaborator or frequent user, I would appreciate if you
could give
  me some feedback on the planned structure and propose
additional sections or potential user mistakes to highlight. My
primary objective here is to make most of what's on Alex
Williamson's blog more straightforward and concise.

I've already rewritten the first two sections ("Prerequisites" and
"Setting up IOMMU"), and the rest of the article should essentially
follow the same basic structure and style. Replies here or on the
wiki's discussion page would be much appreciated.

-Nicolas
  

___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users




___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

>
> This last options line is not relevant to the specific task you're trying
> to accomplish here.  Please don't blindly include examples in the wiki that
> may not be relevant to all users (disable_vga) or may not be advised or
> even needed for all users (allow_unsafe_interrupts).


You're right - my bad.  That was an error in editing my email :P

 mkinitcpio is already including the vfio modules by default?


I didn't add this because it's assumed in the guide that you'd be adding
the vfio modules to mkinitcpio.conf anyway - kind of redundant.  For the
sake of being thorough, you would need to add *MODULES="vfio vfio-pci"*

On Mon, Apr 18, 2016 at 5:27 PM, Alex Williamson <
alex.l.william...@gmail.com> wrote:

> On Mon, Apr 18, 2016 at 3:14 PM, Garland Key 
> wrote:
>
>> Please add what to do if you have two identical GPUs.  Here is exactly
>> what is needed to make it work.
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */etc/modprobe.d/vfio.conf*
>>
>> install vfio-pci /sbin/vfio-pci-override-vga.sh
>> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>>
>
> This last options line is not relevant to the specific task you're trying
> to accomplish here.  Please don't blindly include examples in the wiki that
> may not be relevant to all users (disable_vga) or may not be advised or
> even needed for all users (allow_unsafe_interrupts).
>
>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> */sbin/vfio-pci-override-vga.sh*
>>
>> #!/bin/sh
>>
>> for i in $(find /sys/devices/pci* -name boot_vga); do
>> if [ $(cat $i) -eq 0 ]; then
>> GPU=$(dirname $i)
>> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>>echo "vfio-pci" > $GPU/driver_override
>> if [ -d $AUDIO ]; then
>> echo "vfio-pci" > $AUDIO/driver_override
>> fi
>> fi
>> done
>>
>> modprobe -i vfio-pci
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>>
>> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
>> linux*
>>
>> BINARIES="/usr/bin/find /usr/bin/dirname"
>> FILES="/sbin/vfio-pci-override-vga.sh"
>>
>
> mkinitcpio is already including the vfio modules by default?
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Alex Williamson]

On Mon, Apr 18, 2016 at 3:14 PM, Garland Key 
wrote:

> Please add what to do if you have two identical GPUs.  Here is exactly
> what is needed to make it work.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> */etc/modprobe.d/vfio.conf*
>
> install vfio-pci /sbin/vfio-pci-override-vga.sh
> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>

This last options line is not relevant to the specific task you're trying
to accomplish here.  Please don't blindly include examples in the wiki that
may not be relevant to all users (disable_vga) or may not be advised or
even needed for all users (allow_unsafe_interrupts).


> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> */sbin/vfio-pci-override-vga.sh*
>
> #!/bin/sh
>
> for i in $(find /sys/devices/pci* -name boot_vga); do
> if [ $(cat $i) -eq 0 ]; then
> GPU=$(dirname $i)
> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>echo "vfio-pci" > $GPU/driver_override
> if [ -d $AUDIO ]; then
> echo "vfio-pci" > $AUDIO/driver_override
> fi
> fi
> done
>
> modprobe -i vfio-pci
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
> linux*
>
> BINARIES="/usr/bin/find /usr/bin/dirname"
> FILES="/sbin/vfio-pci-override-vga.sh"
>

mkinitcpio is already including the vfio modules by default?
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

I'm an intermediate Linux user, so this this stuff can be complicated to me
sometimes.  Right now I'm having trouble setting up a network bridge that
virt-manager will recognize.  I've arrived at the conclusion that this
simply isn't possible on Arch.  That said, I can't find any documentation
on how to convince qemu to use an existing network bridge.  If you're
willing, please add this information as well.  If you already know how, any
pointers would be greatly appreciated.

Best,
Garland

On Mon, Apr 18, 2016 at 5:14 PM, Garland Key 
wrote:

> Please add what to do if you have two identical GPUs.  Here is exactly
> what is needed to make it work.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> */etc/modprobe.d/vfio.conf*
>
> install vfio-pci /sbin/vfio-pci-override-vga.sh
> options vfio-pci disable_vga=1 allow_unsafe_interrupts=1
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> */sbin/vfio-pci-override-vga.sh*
>
> #!/bin/sh
>
> for i in $(find /sys/devices/pci* -name boot_vga); do
> if [ $(cat $i) -eq 0 ]; then
> GPU=$(dirname $i)
> AUDIO=$(echo $GPU | sed -e "s/0$/1/")
>echo "vfio-pci" > $GPU/driver_override
> if [ -d $AUDIO ]; then
> echo "vfio-pci" > $AUDIO/driver_override
> fi
> fi
> done
>
> modprobe -i vfio-pci
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
> linux*
>
> BINARIES="/usr/bin/find /usr/bin/dirname"
> FILES="/sbin/vfio-pci-override-vga.sh"
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> *Tested Hardware:*
>
> Motherboard: Asus Sabertooth X99
> 
> CPU: Intel Core i7-5930K
> 
> GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
> 
> GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition
> 
> RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)
> 
>
>
> On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud <
> nicolas.roy-renau...@ens.etsmtl.ca> wrote:
>
>> I'm currently planning a full rewrite of the article on Arch wiki about
>> PCI passthroughs
>>  and, as
>> per Arch wiki guidelines, I'm supposed get the approval of other users
>> before undergoing such comlex edits. If anyone on this mailing list is an
>> Arch wiki collaborator or frequent user, I would appreciate if you could give
>> me some feedback on the planned structure
>> 
>> and propose additional sections or potential user mistakes to highlight. My
>> primary objective here is to make most of what's on Alex Williamson's blog
>> more straightforward and concise.
>>
>> I've already rewritten the first two sections ("Prerequisites" and
>> "Setting up IOMMU"), and the rest of the article should essentially follow
>> the same basic structure and style. Replies here or on the wiki's
>> discussion page would be much appreciated.
>>
>> -Nicolas
>>
>> ___
>> vfio-users mailing list
>> vfio-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

Please add what to do if you have two identical GPUs.  Here is exactly what
is needed to make it work.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -

*/etc/modprobe.d/vfio.conf*

install vfio-pci /sbin/vfio-pci-override-vga.sh
options vfio-pci disable_vga=1 allow_unsafe_interrupts=1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -

*/sbin/vfio-pci-override-vga.sh*

#!/bin/sh

for i in $(find /sys/devices/pci* -name boot_vga); do
if [ $(cat $i) -eq 0 ]; then
GPU=$(dirname $i)
AUDIO=$(echo $GPU | sed -e "s/0$/1/")
   echo "vfio-pci" > $GPU/driver_override
if [ -d $AUDIO ]; then
echo "vfio-pci" > $AUDIO/driver_override
fi
fi
done

modprobe -i vfio-pci

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -

Add the following to */etc/mkinitcpio.conf* and then run *mkinitcpio -p
linux*

BINARIES="/usr/bin/find /usr/bin/dirname"
FILES="/sbin/vfio-pci-override-vga.sh"

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -

*Tested Hardware:*

Motherboard: Asus Sabertooth X99

CPU: Intel Core i7-5930K

GPU 1: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition

GPU 2: GIGABYTE GeForce GTX 970 4GB G1 Gaming OC Edition

RAM: 32GB Corsair Dominator Platinum DDR4 (CMD16GX4M2A2666C15)



On Tue, Apr 12, 2016 at 3:36 PM, Nicolas Roy-Renaud <
nicolas.roy-renau...@ens.etsmtl.ca> wrote:

> I'm currently planning a full rewrite of the article on Arch wiki about
> PCI passthroughs
>  and, as
> per Arch wiki guidelines, I'm supposed get the approval of other users
> before undergoing such comlex edits. If anyone on this mailing list is an
> Arch wiki collaborator or frequent user, I would appreciate if you could give
> me some feedback on the planned structure
> 
> and propose additional sections or potential user mistakes to highlight. My
> primary objective here is to make most of what's on Alex Williamson's blog
> more straightforward and concise.
>
> I've already rewritten the first two sections ("Prerequisites" and
> "Setting up IOMMU"), and the rest of the article should essentially follow
> the same basic structure and style. Replies here or on the wiki's
> discussion page would be much appreciated.
>
> -Nicolas
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

On 2016-04-15 18:51, Hristo Iliev wrote:

On Tue, 12 Apr 2016 14:50:55 -0600 Will Marler  wrote:


"options kvm ignore_msrs=1"

On the wiki page as it stands now there is a warning, "Silently ignoring
unknown MSR accesses could potentially break other software within the VM
or other VMs." I'm not clear on all of the ramifications, though it came up
on the mailing list before. I basically decided "not important enough for
me to do it" and forgot all the details. But I wouldn't remove this warning
or suggest this as a performance gain unless the risks have been eliminated
(or are only applicable to specific edge cases or something).


As I've probably said before, I wrote this section of the wiki. ignore_msrs=1
stops KVM from injecting #GPs when unknown MSRs are accessed and simply makes
the reads return 0 and turns the writes into no-ops. While it stops certain
software from crashing as a result of the unexpected protection faults, it
could result in the same software silently making wrong decisions based on the
zero return value and it might break legitimate software that is already
properly handling the faults. It basically replaces a well-defined exception
with a junk value.

In my case, I'm doing CPUID passthrough with my Haswell-E CPU and the unknown
MSRs are always Intel power and frequency management registers, which are
supposed to exist on the real Haswell chip. Ignoring them workes for the
NVIDIA tool, but I would not make a general case out of a specific one,
therefore the warning.

Regards,
Hristo
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
I've changed it to make it clearer that it doesn't simply apply to 
Geforce Experience, as others have suggested, and reworded the warning 
to mention that it should /normally/ be safe to do this.


Nicolas
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Hristo Iliev]

On Tue, 12 Apr 2016 14:50:55 -0600 Will Marler  wrote:

> "options kvm ignore_msrs=1"
> 
> On the wiki page as it stands now there is a warning, "Silently ignoring
> unknown MSR accesses could potentially break other software within the VM
> or other VMs." I'm not clear on all of the ramifications, though it came up
> on the mailing list before. I basically decided "not important enough for
> me to do it" and forgot all the details. But I wouldn't remove this warning
> or suggest this as a performance gain unless the risks have been eliminated
> (or are only applicable to specific edge cases or something).
> 

As I've probably said before, I wrote this section of the wiki. ignore_msrs=1
stops KVM from injecting #GPs when unknown MSRs are accessed and simply makes
the reads return 0 and turns the writes into no-ops. While it stops certain
software from crashing as a result of the unexpected protection faults, it
could result in the same software silently making wrong decisions based on the
zero return value and it might break legitimate software that is already
properly handling the faults. It basically replaces a well-defined exception
with a junk value.

In my case, I'm doing CPUID passthrough with my Haswell-E CPU and the unknown
MSRs are always Intel power and frequency management registers, which are
supposed to exist on the real Haswell chip. Ignoring them workes for the
NVIDIA tool, but I would not make a general case out of a specific one,
therefore the warning.

Regards,
Hristo

> On Tue, Apr 12, 2016 at 2:35 PM, Blank Field 
> wrote:
> 
> > TL;DR point 2. is wrong, pcie-port, vfio-pci or pci-stub are allowed, see
> > "IOMMU groups inside and out" blog post.
> > On Apr 12, 2016 11:30 PM, "Bronek Kozicki"  wrote:
> >  
> >> On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:
> >>  
> >>> I've already rewritten the first two sections ("Prerequisites" and
> >>> "Setting up IOMMU"), and the rest of the article should essentially
> >>> follow the same basic structure and style. Replies here or on the wiki's
> >>> discussion page would be much appreciated.
> >>>  
> >>
> >> Hope Alex can clear any misconception I am about to present below
> >>
> >>
> >> 1. I am using option iommu=pt, under impression this is expected to
> >> improve performance (my CPU is Xeon IvyBridge)
> >>
> >> 2. does PCI bridge have to be in a separate IOMMU group than
> >> passed-through device?
> >>
> >> 3. would be nice to provide hints for headless host. FWIW, I use
> >> combination of
> >> 3.1. kernel options:
> >> console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
> >> 3.2.following line in /etc/modprobe.d/vfio.conf:
> >> options vfio-pci disable_vga=1
> >> 3.3. large list of blacklisted modules (all framebuffers and nvidia and
> >> AMD drivers) in /etc/modprobe.d/blacklist.conf:
> >> # This host is headless, prevent any modules from attaching to video
> >> hardware
> >> # NVIDIA
> >> blacklist nouveau
> >> blacklist nvidia
> >> # AMD
> >> blacklist radeon
> >> blacklist amdgpu
> >> blacklist amdkfd
> >> blacklist fglrx
> >> # HDMI sound on a GPU
> >> blacklist snd_hda_intel
> >> # Framebuffers (ALL of them)
> >> blacklist vesafb
> >> blacklist aty128fb
> >> blacklist atyfb
> >> blacklist radeonfb
> >> blacklist cirrusfb
> >> blacklist cyber2000fb
> >> blacklist cyblafb
> >> blacklist gx1fb
> >> blacklist hgafb
> >> blacklist i810fb
> >> blacklist intelfb
> >> blacklist kyrofb
> >> blacklist lxfb
> >> blacklist matroxfb_base
> >> blacklist neofb
> >> blacklist nvidiafb
> >> blacklist pm2fb
> >> blacklist rivafb
> >> blacklist s1d13xxxfb
> >> blacklist savagefb
> >> blacklist sisfb
> >> blacklist sstfb
> >> blacklist tdfxfb
> >> blacklist tridentfb
> >> blacklist vfb
> >> blacklist viafb
> >> blacklist vt8623fb
> >> blacklist udlfb
> >>
> >> 4. ignore_msrs=1 also helps running Linux guests
> >>
> >> 5. do not use qemu:arg for binding host device to guest, here is example
> >> how to do it properly:
> >> 
> >>   
> >>   
> >> 
> >>   
> >>>> function='0x0'/>  
> >> 
> >> 5.1. for nVidia Quadro, add just below 
> >> 
> >>
> >> 6. if guest is started from BIOS rather than UEFI, keep the above
> >>  but replace emulator with a script, e.g.
> >> # virsh dumpxml gdynia-vfio1 | grep emulator
> >> /usr/bin/qemu-system-x86_64.xvga.sh
> >> # cat /usr/bin/qemu-system-x86_64.xvga.sh
> >> #!/bin/sh
> >> exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
> >> sed 's/-device vfio-pci,host=82:00.0/-device
> >> vfio-pci,host=82:00.0,x-vga=on/g' | \
> >> sed 's/-device vfio-pci,host=03:00.0/-device
> >> vfio-pci,host=03:00.0,x-vga=on/g'`
> >>
> >>
> >> 7. performance optimizations
> >> 7.1. use huge pages
> >> 7.2. use isolcpus
> >> 7.3. use vCPU pinnig
> >> 7.4. use virtio-scsi with multiple queues (depending on number of
> >> available CPUs, after removing these dedicated to guest)
> >> 7.5. use multiple queues for virtio-net
> >> 7.6. for Linux  guests, use P

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

On 2016-04-13 12:05, Will Marler wrote:


On Wed, Apr 13, 2016 at 9:18 AM, Ivan Volosyuk 
mailto:ivan.volos...@gmail.com>> wrote:


Windows specific sound tweaks can be useful (audio crackles is a
pain) - enable MSI as per Alex blog. Might be out of scope for the
article though.


Oh this is a great idea. I don't think it's out of scope, in fact 
quite the opposite. I think it belongs in the "Troubleshooting" part, 
as some people will have problems here and others won't.


Which also reminds me: in the "Troubleshooting" section I think it is 
worth mentioning that a $10 or $15 PCI USB card that is to be passed 
through to the guest can be a big headache saver. It's maybe a 
"workaround" and not a "solution," but it's definitely something that 
might not occur to people, and is worth mentioning. USB passthrough 
works really well most of the time, but in some cases it doesn't; I 
have a Logitech mouse, for example, that required a firmware update. 
The Logitech software running in the Windows guest said "unplug & 
re-plug the mouse to initiate the firmware update." No amount of 
plugging/unplugging, disabling/re-enabling passthrough would get the 
right signals sent to the guest to trigger the firmware update. 
Passing through the PCI USB card though, and plugging/unplugging the 
mouse from there worked without issue. Plugging in USB headphones to 
the passed-through PCI card fixed audio problems that were present 
when passing the headphones through via USB passthrough too.
Yeah, I get what you mean. I had to run a firmware restoration on an old 
iPhone once, and since the device changes USB ID multiple times during 
the operation, libvirt wouldn't recognize that and unmapped the device 
whenever it did that. Passing through a spare usb controller if your 
groupings allow it is a big step up from manual USB passthroughs. I'm 
not sure if it fits the scope of that specific article, though (might be 
more of a KVM/libvirt thing), but I'll see if I can fit it anywhere. I 
might go with the wikipedia solution of linking towards another article 
and simply provide a quick summary.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Will Marler]

On Wed, Apr 13, 2016 at 9:18 AM, Ivan Volosyuk 
wrote:

> Windows specific sound tweaks can be useful (audio crackles is a pain) -
> enable MSI as per Alex blog. Might be out of scope for the article though.


Oh this is a great idea. I don't think it's out of scope, in fact quite the
opposite. I think it belongs in the "Troubleshooting" part, as some people
will have problems here and others won't.

Which also reminds me: in the "Troubleshooting" section I think it is worth
mentioning that a $10 or $15 PCI USB card that is to be passed through to
the guest can be a big headache saver. It's maybe a "workaround" and not a
"solution," but it's definitely something that might not occur to people,
and is worth mentioning. USB passthrough works really well most of the
time, but in some cases it doesn't; I have a Logitech mouse, for example,
that required a firmware update. The Logitech software running in the
Windows guest said "unplug & re-plug the mouse to initiate the firmware
update." No amount of plugging/unplugging, disabling/re-enabling
passthrough would get the right signals sent to the guest to trigger the
firmware update. Passing through the PCI USB card though, and
plugging/unplugging the mouse from there worked without issue. Plugging in
USB headphones to the passed-through PCI card fixed audio problems that
were present when passing the headphones through via USB passthrough too.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Ivan Volosyuk]

Windows specific sound tweaks can be useful (audio crackles is a pain) -
enable MSI as per Alex blog. Might be out of scope for the article though.

On Wed, Apr 13, 2016 at 5:47 AM Nicolas Roy-Renaud <
nicolas.roy-renau...@ens.etsmtl.ca> wrote:

> I'm currently planning a full rewrite of the article on Arch wiki about
> PCI passthroughs
>  and, as
> per Arch wiki guidelines, I'm supposed get the approval of other users
> before undergoing such comlex edits. If anyone on this mailing list is an
> Arch wiki collaborator or frequent user, I would appreciate if you could give
> me some feedback on the planned structure
> 
> and propose additional sections or potential user mistakes to highlight. My
> primary objective here is to make most of what's on Alex Williamson's blog
> more straightforward and concise.
>
> I've already rewritten the first two sections ("Prerequisites" and
> "Setting up IOMMU"), and the rest of the article should essentially follow
> the same basic structure and style. Replies here or on the wiki's
> discussion page would be much appreciated.
>
> -Nicolas
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Jonathan Scruggs]

Hi,

Qemu 4.6 will have the new input patches by Gerd. You should add a section
on how to set that up. I can forward the needed emails on how to set it up
if need be. It's a little confusing.

Jon
On 12 Apr 2016 8:47 pm, "Nicolas Roy-Renaud" <
nicolas.roy-renau...@ens.etsmtl.ca> wrote:

> I'm currently planning a full rewrite of the article on Arch wiki about
> PCI passthroughs
>  and, as
> per Arch wiki guidelines, I'm supposed get the approval of other users
> before undergoing such comlex edits. If anyone on this mailing list is an
> Arch wiki collaborator or frequent user, I would appreciate if you could give
> me some feedback on the planned structure
> 
> and propose additional sections or potential user mistakes to highlight. My
> primary objective here is to make most of what's on Alex Williamson's blog
> more straightforward and concise.
>
> I've already rewritten the first two sections ("Prerequisites" and
> "Setting up IOMMU"), and the rest of the article should essentially follow
> the same basic structure and style. Replies here or on the wiki's
> discussion page would be much appreciated.
>
> -Nicolas
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

On 2016-04-12 18:32, Alex Williamson wrote:


On 2016-04-12 17:24, Alex Williamson wrote:

On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki mailto:b...@spamcop.net>> wrote:

2. does PCI bridge have to be in a separate IOMMU group than
passed-through device?


No.  Blank is mostly correct on this, newer kernel remove the
pcieport driver test and presumes any driver attached to a bridge
device is ok.

Really? From what I understood reading your IOMMU article, plus
from the issues I had getting my own GPU to work on the CPU-based
PCIe slot on my E3-1200, I thought having a PCIe root port grouped
with a PCI device made the GPU unsuited for passthrougs. What
reccomendations should I give here

,
then?


The statement "(there's generally only one)" is completely incorrect 
regarding processor based root port slots.  That $30k PC that 
LinuxTechTips did has 7 processor based root ports between the 2 sockets.
You're right, I shouldn't have extrapolated from the fact that most of 
the consumer hardware I have access to works that way, I'll remove that 
line on my next edit.
IOMMU group isolation requires that a group is never shared between 
host and guest or between different guests.  However we assume that 
bridge devices only do DMA on behalf of the devices downstream of 
them, so we allow the bridge to be managed by a host driver.  So in 
your example, it's possible that the bridge could do redirections, but 
the only affected party would be the VM itself.  The same is true for 
a multi-function device like the GPU itself, internal routing may 
allow the devices to perform peer-to-peer internally.  So it's not 
ideal when the bridge is part of the group, but it generally works and 
is allowed because it can't interfere with anyone else.
Ah, I see. I suppose the issues i was having with my 970 were due to 
something else, then. Now that I look back at it, it's probably because 
my CPU-based PCIe slot was the only one that could be set as a boot GPU 
. 
I'll try to rework that part and mention that it adresses a much more 
specific case than what I iniaially thought, then.

I have the identical setup on my E3-1245v2 and haven't had any problems.
The line is actually copy-pasted from your IOMMU blog-articles, since my 
own machine no longer follows that configuration and I needed a snippet 
for that specific exemple.


On 2016-04-12 18:57, Alex Williamson wrote:

Skimming...

Most of those AMD CPUs in the amd.com  link do not 
support AMD-Vi
I should have double-checked, I was under the impression that RVI and 
AMD-Vi were the same thing. The fact that AMD doesn't really maintain 
any sort of public centralized database like Intel ARK makes it really 
complicated to give advices on this.
User-level access to devices... No, don't do this.  System mode 
libvirt manages device permissions.  If you want unprivileged, session 
mode libvirt you need a whole other wiki page.


Binding to VFIO... Gosh I wish those vfio-bind scripts would die.  
Just use libvirt, virsh nodedev-detach


QEMU permissions... WRONG!  Don't touch any of this.

Complete example for QEMU with libvirtd... No, qemu:args are the 
worst.  This hides the assigned device from libvirt and is what causes 
you to need to do the QEMU permissions hacks that are completely 
wrong.  Use a wrapper script!


As others have said, ignore_msrs makes lots of things work, not just 
GeForce Experience

Yeah, I think you're starting to see why a rewrite is in order here. ;)
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Alex Williamson]

Skimming...

Most of those AMD CPUs in the amd.com link do not support AMD-Vi

User-level access to devices... No, don't do this.  System mode libvirt
manages device permissions.  If you want unprivileged, session mode libvirt
you need a whole other wiki page.

Binding to VFIO... Gosh I wish those vfio-bind scripts would die.  Just use
libvirt, virsh nodedev-detach

QEMU permissions... WRONG!  Don't touch any of this.

Complete example for QEMU with libvirtd... No, qemu:args are the worst.
This hides the assigned device from libvirt and is what causes you to need
to do the QEMU permissions hacks that are completely wrong.  Use a wrapper
script!

As others have said, ignore_msrs makes lots of things work, not just
GeForce Experience
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Alex Williamson]

>
> On 2016-04-12 17:24, Alex Williamson wrote:
>
> On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki < 
> b...@spamcop.net> wrote:
>
>
>> 2. does PCI bridge have to be in a separate IOMMU group than
>> passed-through device?
>>
>
> No.  Blank is mostly correct on this, newer kernel remove the pcieport
> driver test and presumes any driver attached to a bridge device is ok.
>
> Really? From what I understood reading your IOMMU article, plus from the
> issues I had getting my own GPU to work on the CPU-based PCIe slot on my
> E3-1200, I thought having a PCIe root port grouped with a PCI device made
> the GPU unsuited for passthrougs. What reccomendations should I give here
> ,
> then?
>

The statement "(there's generally only one)" is completely incorrect
regarding processor based root port slots.  That $30k PC that LinuxTechTips
did has 7 processor based root ports between the 2 sockets.

IOMMU group isolation requires that a group is never shared between host
and guest or between different guests.  However we assume that bridge
devices only do DMA on behalf of the devices downstream of them, so we
allow the bridge to be managed by a host driver.  So in your example, it's
possible that the bridge could do redirections, but the only affected party
would be the VM itself.  The same is true for a multi-function device like
the GPU itself, internal routing may allow the devices to perform
peer-to-peer internally.  So it's not ideal when the bridge is part of the
group, but it generally works and is allowed because it can't interfere
with anyone else.  I have the identical setup on my E3-1245v2 and haven't
had any problems.

Where the isolation problem with root ports explodes is when another
non-ACS root port is added at 01.x or there are many devices downsteam of
the root port (SR-IOV).  Then we end up with an even bigger IOMMU group and
the user generally doesn't want to assign all those endpoints to a single
VM.

Your recommendation isn't entirely wrong, we should be doing device
assignment on hardware with full isolation, but it excludes a very typical
use case that often works well enough.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[thibaut noah]

"options kvm ignore_msrs=1"

If you guys don't need it that is because you don't game.
Launch metal gear solid phantom pain on a windows guest without this option
and your virtual machine will crash, period.
This is mandatory for every gamer who plays recent games.

2016-04-12 23:24 GMT+02:00 Alex Williamson :

> On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki  wrote:
>
>> On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:
>>
>>> I've already rewritten the first two sections ("Prerequisites" and
>>> "Setting up IOMMU"), and the rest of the article should essentially
>>> follow the same basic structure and style. Replies here or on the wiki's
>>> discussion page would be much appreciated.
>>>
>>
>> Hope Alex can clear any misconception I am about to present below
>>
>>
>> 1. I am using option iommu=pt, under impression this is expected to
>> improve performance (my CPU is Xeon IvyBridge)
>>
>
> It only affects the performance of host devices.  There's less latency if
> host DMAs don't do dynamic mappings through the IOMMU, also less isolation
> between drivers.
>
>
>> 2. does PCI bridge have to be in a separate IOMMU group than
>> passed-through device?
>>
>
> No.  Blank is mostly correct on this, newer kernel remove the pcieport
> driver test and presumes any driver attached to a bridge device is ok.
>
>
>> 3. would be nice to provide hints for headless host. FWIW, I use
>> combination of
>> 3.1. kernel options:
>> console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
>> 3.2.following line in /etc/modprobe.d/vfio.conf:
>> options vfio-pci disable_vga=1
>> 3.3. large list of blacklisted modules (all framebuffers and nvidia and
>> AMD drivers) in /etc/modprobe.d/blacklist.conf:
>> # This host is headless, prevent any modules from attaching to video
>> hardware
>> # NVIDIA
>> blacklist nouveau
>> blacklist nvidia
>> # AMD
>> blacklist radeon
>> blacklist amdgpu
>> blacklist amdkfd
>> blacklist fglrx
>> # HDMI sound on a GPU
>> blacklist snd_hda_intel
>> # Framebuffers (ALL of them)
>> blacklist vesafb
>> blacklist aty128fb
>> blacklist atyfb
>> blacklist radeonfb
>> blacklist cirrusfb
>> blacklist cyber2000fb
>> blacklist cyblafb
>> blacklist gx1fb
>> blacklist hgafb
>> blacklist i810fb
>> blacklist intelfb
>> blacklist kyrofb
>> blacklist lxfb
>> blacklist matroxfb_base
>> blacklist neofb
>> blacklist nvidiafb
>> blacklist pm2fb
>> blacklist rivafb
>> blacklist s1d13xxxfb
>> blacklist savagefb
>> blacklist sisfb
>> blacklist sstfb
>> blacklist tdfxfb
>> blacklist tridentfb
>> blacklist vfb
>> blacklist viafb
>> blacklist vt8623fb
>> blacklist udlfb
>>
>
> I suspect that blacklisting framebuffer drivers doesn't actually do
> anything.
>
>
>> 4. ignore_msrs=1 also helps running Linux guests
>>
>
> Never been needed in my experience.
>
>
>> 5. do not use qemu:arg for binding host device to guest, here is example
>> how to do it properly:
>> 
>>   
>>   
>> 
>>   
>>   > function='0x0'/>
>> 
>> 5.1. for nVidia Quadro, add just below 
>> 
>>
>
> Shouldn't be necessary to hide the ROM, Quadro should never be the primary
> graphics device and thus its ROM should never get executed.
>
>
>>
>> 6. if guest is started from BIOS rather than UEFI, keep the above
>>  but replace emulator with a script, e.g.
>> # virsh dumpxml gdynia-vfio1 | grep emulator
>> /usr/bin/qemu-system-x86_64.xvga.sh
>> # cat /usr/bin/qemu-system-x86_64.xvga.sh
>> #!/bin/sh
>> exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
>> sed 's/-device vfio-pci,host=82:00.0/-device
>> vfio-pci,host=82:00.0,x-vga=on/g' | \
>> sed 's/-device vfio-pci,host=03:00.0/-device
>> vfio-pci,host=03:00.0,x-vga=on/g'`
>>
>>
>> 7. performance optimizations
>> 7.1. use huge pages
>> 7.2. use isolcpus
>> 7.3. use vCPU pinnig
>> 7.4. use virtio-scsi with multiple queues (depending on number of
>> available CPUs, after removing these dedicated to guest)
>> 7.5. use multiple queues for virtio-net
>> 7.6. for Linux  guests, use P9 for mounting host filesystems in guest
>
>
> There are numerous ways to do this, that's one.   Hard to make any
> universal recommendation there, NFS, sshfs, SMB are also options.
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

On 2016-04-12 16:11, Garland Key wrote:
Please add what to do if both of your gpus are identical.  This is an 
issue that was a huge headache for me. I actually gave up and went to 
fedora over it.  I missed Arch after two weeks and went back.  I was 
able to get it to work in fedora on the first go.  I haven't given it 
another go just yet. I'll report back in a few days as I'll be trying 
it again.
From what I've gathered, it's mostly about using a stript to bind the 
GPUs you want to vfio-pci using the driver_override mecanism. Is that 
correct?



On 2016-04-12 17:24, Alex Williamson wrote:

On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki  wrote:

2. does PCI bridge have to be in a separate IOMMU group than
passed-through device?


No.  Blank is mostly correct on this, newer kernel remove the pcieport 
driver test and presumes any driver attached to a bridge device is ok.
Really? From what I understood reading your IOMMU article, plus from the 
issues I had getting my own GPU to work on the CPU-based PCIe slot on my 
E3-1200, I thought having a PCIe root port grouped with a PCI device 
made the GPU unsuited for passthrougs. What reccomendations should I 
give here 
, 
then?



___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Alex Williamson]

On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki  wrote:

> On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:
>
>> I've already rewritten the first two sections ("Prerequisites" and
>> "Setting up IOMMU"), and the rest of the article should essentially
>> follow the same basic structure and style. Replies here or on the wiki's
>> discussion page would be much appreciated.
>>
>
> Hope Alex can clear any misconception I am about to present below
>
>
> 1. I am using option iommu=pt, under impression this is expected to
> improve performance (my CPU is Xeon IvyBridge)
>

It only affects the performance of host devices.  There's less latency if
host DMAs don't do dynamic mappings through the IOMMU, also less isolation
between drivers.


> 2. does PCI bridge have to be in a separate IOMMU group than
> passed-through device?
>

No.  Blank is mostly correct on this, newer kernel remove the pcieport
driver test and presumes any driver attached to a bridge device is ok.


> 3. would be nice to provide hints for headless host. FWIW, I use
> combination of
> 3.1. kernel options:
> console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
> 3.2.following line in /etc/modprobe.d/vfio.conf:
> options vfio-pci disable_vga=1
> 3.3. large list of blacklisted modules (all framebuffers and nvidia and
> AMD drivers) in /etc/modprobe.d/blacklist.conf:
> # This host is headless, prevent any modules from attaching to video
> hardware
> # NVIDIA
> blacklist nouveau
> blacklist nvidia
> # AMD
> blacklist radeon
> blacklist amdgpu
> blacklist amdkfd
> blacklist fglrx
> # HDMI sound on a GPU
> blacklist snd_hda_intel
> # Framebuffers (ALL of them)
> blacklist vesafb
> blacklist aty128fb
> blacklist atyfb
> blacklist radeonfb
> blacklist cirrusfb
> blacklist cyber2000fb
> blacklist cyblafb
> blacklist gx1fb
> blacklist hgafb
> blacklist i810fb
> blacklist intelfb
> blacklist kyrofb
> blacklist lxfb
> blacklist matroxfb_base
> blacklist neofb
> blacklist nvidiafb
> blacklist pm2fb
> blacklist rivafb
> blacklist s1d13xxxfb
> blacklist savagefb
> blacklist sisfb
> blacklist sstfb
> blacklist tdfxfb
> blacklist tridentfb
> blacklist vfb
> blacklist viafb
> blacklist vt8623fb
> blacklist udlfb
>

I suspect that blacklisting framebuffer drivers doesn't actually do
anything.


> 4. ignore_msrs=1 also helps running Linux guests
>

Never been needed in my experience.


> 5. do not use qemu:arg for binding host device to guest, here is example
> how to do it properly:
> 
>   
>   
> 
>   
>function='0x0'/>
> 
> 5.1. for nVidia Quadro, add just below 
> 
>

Shouldn't be necessary to hide the ROM, Quadro should never be the primary
graphics device and thus its ROM should never get executed.


>
> 6. if guest is started from BIOS rather than UEFI, keep the above  ...> but replace emulator with a script, e.g.
> # virsh dumpxml gdynia-vfio1 | grep emulator
> /usr/bin/qemu-system-x86_64.xvga.sh
> # cat /usr/bin/qemu-system-x86_64.xvga.sh
> #!/bin/sh
> exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
> sed 's/-device vfio-pci,host=82:00.0/-device
> vfio-pci,host=82:00.0,x-vga=on/g' | \
> sed 's/-device vfio-pci,host=03:00.0/-device
> vfio-pci,host=03:00.0,x-vga=on/g'`
>
>
> 7. performance optimizations
> 7.1. use huge pages
> 7.2. use isolcpus
> 7.3. use vCPU pinnig
> 7.4. use virtio-scsi with multiple queues (depending on number of
> available CPUs, after removing these dedicated to guest)
> 7.5. use multiple queues for virtio-net
> 7.6. for Linux  guests, use P9 for mounting host filesystems in guest


There are numerous ways to do this, that's one.   Hard to make any
universal recommendation there, NFS, sshfs, SMB are also options.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Will Marler]

"options kvm ignore_msrs=1"

On the wiki page as it stands now there is a warning, "Silently ignoring
unknown MSR accesses could potentially break other software within the VM
or other VMs." I'm not clear on all of the ramifications, though it came up
on the mailing list before. I basically decided "not important enough for
me to do it" and forgot all the details. But I wouldn't remove this warning
or suggest this as a performance gain unless the risks have been eliminated
(or are only applicable to specific edge cases or something).

On Tue, Apr 12, 2016 at 2:35 PM, Blank Field 
wrote:

> TL;DR point 2. is wrong, pcie-port, vfio-pci or pci-stub are allowed, see
> "IOMMU groups inside and out" blog post.
> On Apr 12, 2016 11:30 PM, "Bronek Kozicki"  wrote:
>
>> On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:
>>
>>> I've already rewritten the first two sections ("Prerequisites" and
>>> "Setting up IOMMU"), and the rest of the article should essentially
>>> follow the same basic structure and style. Replies here or on the wiki's
>>> discussion page would be much appreciated.
>>>
>>
>> Hope Alex can clear any misconception I am about to present below
>>
>>
>> 1. I am using option iommu=pt, under impression this is expected to
>> improve performance (my CPU is Xeon IvyBridge)
>>
>> 2. does PCI bridge have to be in a separate IOMMU group than
>> passed-through device?
>>
>> 3. would be nice to provide hints for headless host. FWIW, I use
>> combination of
>> 3.1. kernel options:
>> console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
>> 3.2.following line in /etc/modprobe.d/vfio.conf:
>> options vfio-pci disable_vga=1
>> 3.3. large list of blacklisted modules (all framebuffers and nvidia and
>> AMD drivers) in /etc/modprobe.d/blacklist.conf:
>> # This host is headless, prevent any modules from attaching to video
>> hardware
>> # NVIDIA
>> blacklist nouveau
>> blacklist nvidia
>> # AMD
>> blacklist radeon
>> blacklist amdgpu
>> blacklist amdkfd
>> blacklist fglrx
>> # HDMI sound on a GPU
>> blacklist snd_hda_intel
>> # Framebuffers (ALL of them)
>> blacklist vesafb
>> blacklist aty128fb
>> blacklist atyfb
>> blacklist radeonfb
>> blacklist cirrusfb
>> blacklist cyber2000fb
>> blacklist cyblafb
>> blacklist gx1fb
>> blacklist hgafb
>> blacklist i810fb
>> blacklist intelfb
>> blacklist kyrofb
>> blacklist lxfb
>> blacklist matroxfb_base
>> blacklist neofb
>> blacklist nvidiafb
>> blacklist pm2fb
>> blacklist rivafb
>> blacklist s1d13xxxfb
>> blacklist savagefb
>> blacklist sisfb
>> blacklist sstfb
>> blacklist tdfxfb
>> blacklist tridentfb
>> blacklist vfb
>> blacklist viafb
>> blacklist vt8623fb
>> blacklist udlfb
>>
>> 4. ignore_msrs=1 also helps running Linux guests
>>
>> 5. do not use qemu:arg for binding host device to guest, here is example
>> how to do it properly:
>> 
>>   
>>   
>> 
>>   
>>   > function='0x0'/>
>> 
>> 5.1. for nVidia Quadro, add just below 
>> 
>>
>> 6. if guest is started from BIOS rather than UEFI, keep the above
>>  but replace emulator with a script, e.g.
>> # virsh dumpxml gdynia-vfio1 | grep emulator
>> /usr/bin/qemu-system-x86_64.xvga.sh
>> # cat /usr/bin/qemu-system-x86_64.xvga.sh
>> #!/bin/sh
>> exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
>> sed 's/-device vfio-pci,host=82:00.0/-device
>> vfio-pci,host=82:00.0,x-vga=on/g' | \
>> sed 's/-device vfio-pci,host=03:00.0/-device
>> vfio-pci,host=03:00.0,x-vga=on/g'`
>>
>>
>> 7. performance optimizations
>> 7.1. use huge pages
>> 7.2. use isolcpus
>> 7.3. use vCPU pinnig
>> 7.4. use virtio-scsi with multiple queues (depending on number of
>> available CPUs, after removing these dedicated to guest)
>> 7.5. use multiple queues for virtio-net
>> 7.6. for Linux  guests, use P9 for mounting host filesystems in guest
>>
>>
>>
>>
>> B.
>>
>> ___
>> vfio-users mailing list
>> vfio-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Blank Field]

TL;DR point 2. is wrong, pcie-port, vfio-pci or pci-stub are allowed, see
"IOMMU groups inside and out" blog post.
On Apr 12, 2016 11:30 PM, "Bronek Kozicki"  wrote:

> On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:
>
>> I've already rewritten the first two sections ("Prerequisites" and
>> "Setting up IOMMU"), and the rest of the article should essentially
>> follow the same basic structure and style. Replies here or on the wiki's
>> discussion page would be much appreciated.
>>
>
> Hope Alex can clear any misconception I am about to present below
>
>
> 1. I am using option iommu=pt, under impression this is expected to
> improve performance (my CPU is Xeon IvyBridge)
>
> 2. does PCI bridge have to be in a separate IOMMU group than
> passed-through device?
>
> 3. would be nice to provide hints for headless host. FWIW, I use
> combination of
> 3.1. kernel options:
> console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
> 3.2.following line in /etc/modprobe.d/vfio.conf:
> options vfio-pci disable_vga=1
> 3.3. large list of blacklisted modules (all framebuffers and nvidia and
> AMD drivers) in /etc/modprobe.d/blacklist.conf:
> # This host is headless, prevent any modules from attaching to video
> hardware
> # NVIDIA
> blacklist nouveau
> blacklist nvidia
> # AMD
> blacklist radeon
> blacklist amdgpu
> blacklist amdkfd
> blacklist fglrx
> # HDMI sound on a GPU
> blacklist snd_hda_intel
> # Framebuffers (ALL of them)
> blacklist vesafb
> blacklist aty128fb
> blacklist atyfb
> blacklist radeonfb
> blacklist cirrusfb
> blacklist cyber2000fb
> blacklist cyblafb
> blacklist gx1fb
> blacklist hgafb
> blacklist i810fb
> blacklist intelfb
> blacklist kyrofb
> blacklist lxfb
> blacklist matroxfb_base
> blacklist neofb
> blacklist nvidiafb
> blacklist pm2fb
> blacklist rivafb
> blacklist s1d13xxxfb
> blacklist savagefb
> blacklist sisfb
> blacklist sstfb
> blacklist tdfxfb
> blacklist tridentfb
> blacklist vfb
> blacklist viafb
> blacklist vt8623fb
> blacklist udlfb
>
> 4. ignore_msrs=1 also helps running Linux guests
>
> 5. do not use qemu:arg for binding host device to guest, here is example
> how to do it properly:
> 
>   
>   
> 
>   
>function='0x0'/>
> 
> 5.1. for nVidia Quadro, add just below 
> 
>
> 6. if guest is started from BIOS rather than UEFI, keep the above  ...> but replace emulator with a script, e.g.
> # virsh dumpxml gdynia-vfio1 | grep emulator
> /usr/bin/qemu-system-x86_64.xvga.sh
> # cat /usr/bin/qemu-system-x86_64.xvga.sh
> #!/bin/sh
> exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
> sed 's/-device vfio-pci,host=82:00.0/-device
> vfio-pci,host=82:00.0,x-vga=on/g' | \
> sed 's/-device vfio-pci,host=03:00.0/-device
> vfio-pci,host=03:00.0,x-vga=on/g'`
>
>
> 7. performance optimizations
> 7.1. use huge pages
> 7.2. use isolcpus
> 7.3. use vCPU pinnig
> 7.4. use virtio-scsi with multiple queues (depending on number of
> available CPUs, after removing these dedicated to guest)
> 7.5. use multiple queues for virtio-net
> 7.6. for Linux  guests, use P9 for mounting host filesystems in guest
>
>
>
>
> B.
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Bronek Kozicki]

On 12/04/2016 20:36, Nicolas Roy-Renaud wrote:

I've already rewritten the first two sections ("Prerequisites" and
"Setting up IOMMU"), and the rest of the article should essentially
follow the same basic structure and style. Replies here or on the wiki's
discussion page would be much appreciated.


Hope Alex can clear any misconception I am about to present below


1. I am using option iommu=pt, under impression this is expected to 
improve performance (my CPU is Xeon IvyBridge)


2. does PCI bridge have to be in a separate IOMMU group than 
passed-through device?


3. would be nice to provide hints for headless host. FWIW, I use 
combination of

3.1. kernel options:
console=ttyS0,115200N8R nomodest video=vesa:off video=efifb:off vga=normal
3.2.following line in /etc/modprobe.d/vfio.conf:
options vfio-pci disable_vga=1
3.3. large list of blacklisted modules (all framebuffers and nvidia and 
AMD drivers) in /etc/modprobe.d/blacklist.conf:
# This host is headless, prevent any modules from attaching to video 
hardware

# NVIDIA
blacklist nouveau
blacklist nvidia
# AMD
blacklist radeon
blacklist amdgpu
blacklist amdkfd
blacklist fglrx
# HDMI sound on a GPU
blacklist snd_hda_intel
# Framebuffers (ALL of them)
blacklist vesafb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist cyblafb
blacklist gx1fb
blacklist hgafb
blacklist i810fb
blacklist intelfb
blacklist kyrofb
blacklist lxfb
blacklist matroxfb_base
blacklist neofb
blacklist nvidiafb
blacklist pm2fb
blacklist rivafb
blacklist s1d13xxxfb
blacklist savagefb
blacklist sisfb
blacklist sstfb
blacklist tdfxfb
blacklist tridentfb
blacklist vfb
blacklist viafb
blacklist vt8623fb
blacklist udlfb

4. ignore_msrs=1 also helps running Linux guests

5. do not use qemu:arg for binding host device to guest, here is example 
how to do it properly:


  
  

  
  function='0x0'/>


5.1. for nVidia Quadro, add just below 


6. if guest is started from BIOS rather than UEFI, keep the above 
 but replace emulator with a script, e.g.

# virsh dumpxml gdynia-vfio1 | grep emulator
/usr/bin/qemu-system-x86_64.xvga.sh
# cat /usr/bin/qemu-system-x86_64.xvga.sh
#!/bin/sh
exec nice --adjustment=-5 /usr/bin/qemu-system-x86_64 `echo "$@" | \
sed 's/-device vfio-pci,host=82:00.0/-device 
vfio-pci,host=82:00.0,x-vga=on/g' | \
sed 's/-device vfio-pci,host=03:00.0/-device 
vfio-pci,host=03:00.0,x-vga=on/g'`



7. performance optimizations
7.1. use huge pages
7.2. use isolcpus
7.3. use vCPU pinnig
7.4. use virtio-scsi with multiple queues (depending on number of 
available CPUs, after removing these dedicated to guest)

7.5. use multiple queues for virtio-net
7.6. for Linux  guests, use P9 for mounting host filesystems in guest




B.

___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Garland Key]

Please add what to do if both of your gpus are identical.  This is an issue
that was a huge headache for me.  I actually gave up and went to fedora
over it.  I missed Arch after two weeks and went back.  I was able to get
it to work in fedora on the first go.  I haven't given it another go just
yet. I'll report back in a few days as I'll be trying it again.

On Tue, Apr 12, 2016, 3:47 PM Nicolas Roy-Renaud <
nicolas.roy-renau...@ens.etsmtl.ca> wrote:

> I'm currently planning a full rewrite of the article on Arch wiki about
> PCI passthroughs
>  and, as
> per Arch wiki guidelines, I'm supposed get the approval of other users
> before undergoing such comlex edits. If anyone on this mailing list is an
> Arch wiki collaborator or frequent user, I would appreciate if you could give
> me some feedback on the planned structure
> 
> and propose additional sections or potential user mistakes to highlight. My
> primary objective here is to make most of what's on Alex Williamson's blog
> more straightforward and concise.
>
> I've already rewritten the first two sections ("Prerequisites" and
> "Setting up IOMMU"), and the rest of the article should essentially follow
> the same basic structure and style. Replies here or on the wiki's
> discussion page would be much appreciated.
>
> -Nicolas
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Will Marler]

I like your proposed new structure. I think the wiki page as it is now
still has a lot of useful and still-valid information on it, so I hope your
restructure/rewrite doesn't cut too much.

On Tue, Apr 12, 2016 at 1:36 PM, Nicolas Roy-Renaud <
nicolas.roy-renau...@ens.etsmtl.ca> wrote:

> I'm currently planning a full rewrite of the article on Arch wiki about
> PCI passthroughs
>  and, as
> per Arch wiki guidelines, I'm supposed get the approval of other users
> before undergoing such comlex edits. If anyone on this mailing list is an
> Arch wiki collaborator or frequent user, I would appreciate if you could give
> me some feedback on the planned structure
> 
> and propose additional sections or potential user mistakes to highlight. My
> primary objective here is to make most of what's on Alex Williamson's blog
> more straightforward and concise.
>
> I've already rewritten the first two sections ("Prerequisites" and
> "Setting up IOMMU"), and the rest of the article should essentially follow
> the same basic structure and style. Replies here or on the wiki's
> discussion page would be much appreciated.
>
> -Nicolas
>
> ___
> vfio-users mailing list
> vfio-users@redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

[vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article

[Nicolas Roy-Renaud]

I'm currently planning a full rewrite of the article on Arch wiki about 
PCI passthroughs 
 and, as 
per Arch wiki guidelines, I'm supposed get the approval of other users 
before undergoing such comlex edits. If anyone on this mailing list is 
an Arch wiki collaborator or frequent user, I would appreciate if you 
could give me some feedback on the planned structure 
 
and propose additional sections or potential user mistakes to highlight. 
My primary objective here is to make most of what's on Alex Williamson's 
blog more straightforward and concise.


I've already rewritten the first two sections ("Prerequisites" and 
"Setting up IOMMU"), and the rest of the article should essentially 
follow the same basic structure and style. Replies here or on the wiki's 
discussion page would be much appreciated.


-Nicolas
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users