Re: [vfio-users] UEFI Windows and SWTPM

2022-08-21 Thread Brett Peckinpaugh
Might want to now create a new disk image and try again now that your system 
details are tied to a key now.  Might work. 

On Aug 21, 2022, 3:49 PM, at 3:49 PM, Roger Lawhorn  wrote:
>well, i tried that, but i ran into several issues:
>it wouldnt let me do anything but win11 home edition
>it demaned i create a microsoft account
>it wouldnt keep my license number
>
>so i gave up, recovered from a backup and did the upgrade process
>
>
>On 8/21/22 11:16 AM, Brett Peckinpaugh wrote:
>> Honestly your better off doing a fresh install. From what I see and 
>> hear performance is effected with an in place upgrade
>> On Aug 21, 2022, at 6:19 AM, Roger Lawhorn  wrote:
>>
>> i got it all worked out
>> i had to emulate TPM 2.0, boot win10 and convert my mbr hard
>drive
>> to GPT, shutdown and switch to uefi and boot win10, and manually
>> run the win11 setup from a thumbdrive
>> i had previously told qemu i had an amd EPYC cpu due to issues
>> with threadrippers at the time.
>> win11 wont accept EPYC so i had to uninstall the epyc processors
>> one at a time, tell qemu to pass through the host cpu instead
>> (-cpu host).
>>
>> i was allowed to keep my win10 license and did not have to make a
>> microsoft account
>> overall, not pleasant but doable
>>
>>
>> On 8/20/22 9:20 PM, Brett Peckinpaugh wrote:
>>> You also need secure boot enabled bios even if you do not fully
>>> use it. Have it working on a VM as well
>>> On Aug 20, 2022, at 4:55 PM, Roger Lawhorn < r...@twc.com> wrote:
>>>
>>> i added tmp 2.0 support to my virt machine.
>>> windows pc health check says i dont qualify for windows 11.
>>> my amd epyc cpu is not supported and i dont use secure boot
>>> says tpm not detected and yet the device manager shows tpm
>2.0 installed
>>> i can add secure boot if needed
>>>
>>> On 8/4/21 10:24 AM, Roger Lawhorn wrote:
>>>
>>>  
>>>
>>> i found this:
>>>
>https://titanwolf.org/Network/Articles/Article?AID=61faf297-0fb8-4dac-babc-877e889b896e#gsc.tab=0
>>> On 8/3/21 8:36 PM, Ivan Volosyuk wrote:
>>>
>>> It's a package, just run in your gentoo box: emerge
>>> swtpm And setup using:
>>> https://qemu-project.gitlab.io/qemu/specs/tpm.html
>On
>>> Wed, Aug 4, 2021 at 2:49 AM Roger Lawhorn
>>>  wrote:
>>>
>>>     how do i install swtpm? is it a package in my
>>> repo or do i need to compile the source code? i
>>> dont use libvert, i run a qemu script to launch
>>> windows 10 how do i tell qemu that it needs to
>>> use it? is it an additional switch on the
>command
>>> line? thanks On 8/3/21 2:20 AM, Brett
>Peckinpaugh
>>> wrote: I found my issue, it was mainly I was
>>> still using the i440fx and needed to switch to
>>> q35.  Which required a bit more work, and as I
>>> had to rebuild and reinstall windows I used the
>>> secure boot OVMF and with that I should be if I
>>> decide to 100% windows 11 compliant.  You will
>>> need to install swtpm and might have to correct
>>> some permissions based on your install, and what
>>>         user and it's permissions that are running your
>>> qemu and libvirt. On Mon, Aug 2, 2021 at 9:39 PM
>>> Roger Lawhorn  wrote:
>>>
>>> We are all facing a forced upgrade to
>windows
>>> 11 so we must answer this question. Thanks
>>> for asking it. I am not familiar with TPM in
>>> virt machines so I decline to comment. On
>>> 7/2/21 2:03 AM, Brett Peckinpaugh wrote:
>With
>>> Win 11 coming I figured I would spend a bit
>>> of time tinkering and see I could be ready
>if
>>> I decided it isn't the junk OS that every
>>> other windows OS is.  I run a guest with
>

Re: [vfio-users] UEFI Windows and SWTPM

2022-08-21 Thread Brett Peckinpaugh
Honestly your better off doing a fresh install. From what I see and hear 
performance is effected with an in place upgrade 

On Aug 21, 2022, 6:19 AM, at 6:19 AM, Roger Lawhorn  wrote:
>i got it all worked out
>i had to emulate TPM 2.0, boot win10 and convert my mbr hard drive to 
>GPT, shutdown and switch to uefi and boot win10, and manually run the 
>win11 setup from a thumbdrive
>i had previously told qemu i had an amd EPYC cpu due to issues with 
>threadrippers at the time.
>win11 wont accept EPYC so i had to uninstall the epyc processors one at
>
>a time, tell qemu to pass through the host cpu instead (-cpu host).
>
>i was allowed to keep my win10 license and did not have to make a 
>microsoft account
>overall, not pleasant but doable
>
>
>On 8/20/22 9:20 PM, Brett Peckinpaugh wrote:
>> You also need secure boot enabled bios even if you do not fully use 
>> it. Have it working on a VM as well
>> On Aug 20, 2022, at 4:55 PM, Roger Lawhorn  wrote:
>>
>> i added tmp 2.0 support to my virt machine.
>> windows pc health check says i dont qualify for windows 11.
>> my amd epyc cpu is not supported and i dont use secure boot
>> says tpm not detected and yet the device manager shows tpm 2.0
>installed
>> i can add secure boot if needed
>>
>> On 8/4/21 10:24 AM, Roger Lawhorn wrote:
>>
>> i found this:
>>
>https://titanwolf.org/Network/Articles/Article?AID=61faf297-0fb8-4dac-babc-877e889b896e#gsc.tab=0
>> On 8/3/21 8:36 PM, Ivan Volosyuk wrote:
>>
>> It's a package, just run in your gentoo box: emerge swtpm
>> And setup using:
>> https://qemu-project.gitlab.io/qemu/specs/tpm.html On
>Wed,
>> Aug 4, 2021 at 2:49 AM Roger Lawhorn  wrote:
>>
>> how do i install swtpm? is it a package in my repo or
>> do i need to compile the source code? i dont use
>> libvert, i run a qemu script to launch windows 10 how
>> do i tell qemu that it needs to use it? is it an
>> additional switch on the command line? thanks On
>> 8/3/21 2:20 AM, Brett Peckinpaugh wrote: I found my
>> issue, it was mainly I was still using the i440fx and
>> needed to switch to q35.  Which required a bit more
>> work, and as I had to rebuild and reinstall windows I
>> used the secure boot OVMF and with that I should be
>if
>> I decide to 100% windows 11 compliant.  You will need
>> to install swtpm and might have to correct some
>> permissions based on your install, and what user and
>> it's permissions that are running your qemu and
>> libvirt. On Mon, Aug 2, 2021 at 9:39 PM Roger Lawhorn
>>  wrote:
>>
>>     We are all facing a forced upgrade to windows 11
>> so we must answer this question. Thanks for
>asking
>> it. I am not familiar with TPM in virt machines
>so
>> I decline to comment. On 7/2/21 2:03 AM, Brett
>> Peckinpaugh wrote: With Win 11 coming I figured I
>> would spend a bit of time tinkering and see I
>> could be ready if I decided it isn't the junk OS
>> that every other windows OS is.  I run a guest
>> with OVMF for UEFI and pass through a PCIE video
>> card. Everything works fine. Challenge I am
>> running into is I installed swtpm, then added a
>> software TPM to my guest.  System boots and runs
>> fine but the TPM fails to start in the Windows
>> guest with a code of 10.  From Linux it all looks
>> good.  Windows events just say generic failure
>> messages. To confuse me more, I have a server
>with
>> a guest running windows that is just virtual. 
>> Added the TPM and it shows up and is working on
>> that guest.  Host is Manjaro flavor of Arch.
>Linux
>> logs for the TPM seems good.  Any ideas?  I tried
>> to boot using a secure boot enabled version of
>> OVMF and guest would not even start. Starting
>vTPM
>> manufacturing as root:root @ Thu 01 Jul 2021
>>   

Re: [vfio-users] UEFI Windows and SWTPM

2022-08-20 Thread Brett Peckinpaugh
You also need secure boot enabled bios even if you do not fully use it. Have it 
working on a VM as well

On Aug 20, 2022, 4:55 PM, at 4:55 PM, Roger Lawhorn  wrote:
>
>i added tmp 2.0 support to my virt machine.
>windows pc health check says i dont qualify for windows 11.
>my amd epyc cpu is not supported and i dont use secure boot
>says tpm not detected and yet the device manager shows tpm 2.0
>installed
>i can add secure boot if needed
>
>On 8/4/21 10:24 AM, Roger Lawhorn wrote:
>> i found this:
>>
>https://titanwolf.org/Network/Articles/Article?AID=61faf297-0fb8-4dac-babc-877e889b896e#gsc.tab=0
>
>>
>>
>>
>> On 8/3/21 8:36 PM, Ivan Volosyuk wrote:
>>> It's a package, just run in your gentoo box:
>>> emerge swtpm
>>>
>>> And setup using:
>>> https://qemu-project.gitlab.io/qemu/specs/tpm.html
>>>
>>> On Wed, Aug 4, 2021 at 2:49 AM Roger Lawhorn  wrote:
>>>> how do i install swtpm?
>>>> is it a package in my repo or do i need to compile the source code?
>>>> i dont use libvert, i run a qemu script to launch windows 10
>>>> how do i tell qemu that it needs to use it?
>>>> is it an additional switch on the command line?
>>>> thanks
>>>>
>>>>
>>>> On 8/3/21 2:20 AM, Brett Peckinpaugh wrote:
>>>>
>>>> I found my issue, it was mainly I was still using the i440fx and 
>>>> needed to switch to q35.  Which required a bit more work, and as I 
>>>> had to rebuild and reinstall windows I used the secure boot OVMF
>and 
>>>> with that I should be if I decide to 100% windows 11 compliant. 
>You 
>>>> will need to install swtpm and might have to correct some 
>>>> permissions based on your install, and what user and it's 
>>>> permissions that are running your qemu and libvirt.
>>>>
>>>> On Mon, Aug 2, 2021 at 9:39 PM Roger Lawhorn  wrote:
>>>>> We are all facing a forced upgrade to windows 11 so we must answer
>
>>>>> this question.
>>>>> Thanks for asking it.
>>>>> I am not familiar with TPM in virt machines so I decline to
>comment.
>>>>>
>>>>> On 7/2/21 2:03 AM, Brett Peckinpaugh wrote:
>>>>>
>>>>> With Win 11 coming I figured I would spend a bit of time tinkering
>
>>>>> and see I could be ready if I decided it isn't the junk OS that 
>>>>> every other windows OS is.  I run a guest with OVMF for UEFI and 
>>>>> pass through a PCIE video card. Everything works fine.
>>>>>
>>>>> Challenge I am running into is I installed swtpm, then added a 
>>>>> software TPM to my guest.  System boots and runs fine but the TPM 
>>>>> fails to start in the Windows guest with a code of 10.  From Linux
>
>>>>> it all looks good.  Windows events just say generic failure
>messages.
>>>>>
>>>>> To confuse me more, I have a server with a guest running windows 
>>>>> that is just virtual.  Added the TPM and it shows up and is
>working 
>>>>> on that guest.  Host is Manjaro flavor of Arch.
>>>>>
>>>>> Linux logs for the TPM seems good.  Any ideas?  I tried to boot 
>>>>> using a secure boot enabled version of OVMF and guest would not 
>>>>> even start.
>>>>>
>>>>> Starting vTPM manufacturing as root:root @ Thu 01 Jul 2021
>10:48:40 
>>>>> PM PDT
>>>>> Successfully created RSA 2048 EK with handle 0x81010001.
>>>>>    Invoking /usr/share/swtpm/swtpm-localca --type ek --ek 
>>>>>
>ac3b97418acfd724aed5d9dcc0f0e10a1a90b04ab21525115e7bb9b9ea63525acc5ac367deef59d99620f129417f21e1419edaebd8b1f385a5b874b463d744c609b2f4c6fc00bfe5712bea7d7506e29ba8b4cb34e1b3c90d3f5a1805ba52628751aef659959d12a33d5238ec82bfa0b04ebab52bde403c9291f80a949de6303af04aa1a706ca4b054f45e94d4749b729ddf2b50849abaae1f681c3bb48ddfce1166fd804b9197d14af5fff9a52e48b0707916091516ed67c4c1e519b51478ecc25c89d9ad7a6f1e29e263b35cb54ca75ebe8bc2d7a82a3f262108abc75592467ccf5defe9e46f3706cc90ae67a4b38910e61a05ff62a9d3ec383bd352143
>
>>>>> --dir 
>>>>> /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2 
>>>>> --logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid 
>>>>> Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
>
>>>>> --tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer 
>>>>> id:1014 --tpm-mode

Re: [vfio-users] UEFI Windows and SWTPM

2021-08-02 Thread Brett Peckinpaugh
I found my issue, it was mainly I was still using the i440fx and needed to
switch to q35.  Which required a bit more work, and as I had to rebuild and
reinstall windows I used the secure boot OVMF and with that I should be if
I decide to 100% windows 11 compliant.  You will need to install swtpm and
might have to correct some permissions based on your install, and what user
and it's permissions that are running your qemu and libvirt.

On Mon, Aug 2, 2021 at 9:39 PM Roger Lawhorn  wrote:

> We are all facing a forced upgrade to windows 11 so we must answer this
> question.
> Thanks for asking it.
> I am not familiar with TPM in virt machines so I decline to comment.
>
> On 7/2/21 2:03 AM, Brett Peckinpaugh wrote:
>
> With Win 11 coming I figured I would spend a bit of time tinkering and see
> I could be ready if I decided it isn't the junk OS that every other windows
> OS is.  I run a guest with OVMF for UEFI and pass through a PCIE video
> card.  Everything works fine.
>
> Challenge I am running into is I installed swtpm, then added a software
> TPM to my guest.  System boots and runs fine but the TPM fails to start in
> the Windows guest with a code of 10.  From Linux it all looks good.
> Windows events just say generic failure messages.
>
> To confuse me more, I have a server with a guest running windows that is
> just virtual.  Added the TPM and it shows up and is working on that guest.
> Host is Manjaro flavor of Arch.
>
> Linux logs for the TPM seems good.  Any ideas?  I tried to boot using a
> secure boot enabled version of OVMF and guest would not even start.
>
> Starting vTPM manufacturing as root:root @ Thu 01 Jul 2021 10:48:40 PM PDT
> Successfully created RSA 2048 EK with handle 0x81010001.
>   Invoking /usr/share/swtpm/swtpm-localca --type ek --ek
> ac3b97418acfd724aed5d9dcc0f0e10a1a90b04ab21525115e7bb9b9ea63525acc5ac367deef59d99620f129417f21e1419edaebd8b1f385a5b874b463d744c609b2f4c6fc00bfe5712bea7d7506e29ba8b4cb34e1b3c90d3f5a1805ba52628751aef659959d12a33d5238ec82bfa0b04ebab52bde403c9291f80a949de6303af04aa1a706ca4b054f45e94d4749b729ddf2b50849abaae1f681c3bb48ddfce1166fd804b9197d14af5fff9a52e48b0707916091516ed67c4c1e519b51478ecc25c89d9ad7a6f1e29e263b35cb54ca75ebe8bc2d7a82a3f262108abc75592467ccf5defe9e46f3706cc90ae67a4b38910e61a05ff62a9d3ec383bd352143
> --dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
> --logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
> Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
> --tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
> --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
> /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
> Successfully created EK certificate locally.
>   Invoking /usr/share/swtpm/swtpm-localca --type platform --ek
> ac3b97418acfd724aed5d9dcc0f0e10a1a90b04ab21525115e7bb9b9ea63525acc5ac367deef59d99620f129417f21e1419edaebd8b1f385a5b874b463d744c609b2f4c6fc00bfe5712bea7d7506e29ba8b4cb34e1b3c90d3f5a1805ba52628751aef659959d12a33d5238ec82bfa0b04ebab52bde403c9291f80a949de6303af04aa1a706ca4b054f45e94d4749b729ddf2b50849abaae1f681c3bb48ddfce1166fd804b9197d14af5fff9a52e48b0707916091516ed67c4c1e519b51478ecc25c89d9ad7a6f1e29e263b35cb54ca75ebe8bc2d7a82a3f262108abc75592467ccf5defe9e46f3706cc90ae67a4b38910e61a05ff62a9d3ec383bd352143
> --dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
> --logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
> Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
> --tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
> --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
> /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
> Successfully created platform certificate locally.
> Successfully created NVRAM area 0x1c2 for RSA 2048 EK certificate.
> Successfully created NVRAM area 0x1c08000 for platform certificate.
> Successfully created ECC EK with handle 0x81010016.
>   Invoking /usr/share/swtpm/swtpm-localca --type ek --ek
> x=0ecc2c9a02316295724304fcdeb9802c6d2f2d5fa40c34717ea9ff64f4d5e969c79f6eaba9bf4f8e6c67416057542a7e,y=6d54604b00bbbc83f8e9d02983c3486514218c9eabf29dbfc692058506828b299cec8605be490173ebe1727719ff5c90,id=secp384r1
> --dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
> --logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
> Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
> --tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
> --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
> /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
> Successfully created EK certificate locally.
> Successfully created NVRAM area 0x1c00016 for ECC EK certificat

[vfio-users] UEFI Windows and SWTPM

2021-07-01 Thread Brett Peckinpaugh
With Win 11 coming I figured I would spend a bit of time tinkering and see
I could be ready if I decided it isn't the junk OS that every other windows
OS is.  I run a guest with OVMF for UEFI and pass through a PCIE video
card.  Everything works fine.

Challenge I am running into is I installed swtpm, then added a software TPM
to my guest.  System boots and runs fine but the TPM fails to start in the
Windows guest with a code of 10.  From Linux it all looks good.  Windows
events just say generic failure messages.

To confuse me more, I have a server with a guest running windows that is
just virtual.  Added the TPM and it shows up and is working on that guest.
Host is Manjaro flavor of Arch.

Linux logs for the TPM seems good.  Any ideas?  I tried to boot using a
secure boot enabled version of OVMF and guest would not even start.

Starting vTPM manufacturing as root:root @ Thu 01 Jul 2021 10:48:40 PM PDT
Successfully created RSA 2048 EK with handle 0x81010001.
  Invoking /usr/share/swtpm/swtpm-localca --type ek --ek
ac3b97418acfd724aed5d9dcc0f0e10a1a90b04ab21525115e7bb9b9ea63525acc5ac367deef59d99620f129417f21e1419edaebd8b1f385a5b874b463d744c609b2f4c6fc00bfe5712bea7d7506e29ba8b4cb34e1b3c90d3f5a1805ba52628751aef659959d12a33d5238ec82bfa0b04ebab52bde403c9291f80a949de6303af04aa1a706ca4b054f45e94d4749b729ddf2b50849abaae1f681c3bb48ddfce1166fd804b9197d14af5fff9a52e48b0707916091516ed67c4c1e519b51478ecc25c89d9ad7a6f1e29e263b35cb54ca75ebe8bc2d7a82a3f262108abc75592467ccf5defe9e46f3706cc90ae67a4b38910e61a05ff62a9d3ec383bd352143
--dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
--logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
--tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
--tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
/etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created EK certificate locally.
  Invoking /usr/share/swtpm/swtpm-localca --type platform --ek
ac3b97418acfd724aed5d9dcc0f0e10a1a90b04ab21525115e7bb9b9ea63525acc5ac367deef59d99620f129417f21e1419edaebd8b1f385a5b874b463d744c609b2f4c6fc00bfe5712bea7d7506e29ba8b4cb34e1b3c90d3f5a1805ba52628751aef659959d12a33d5238ec82bfa0b04ebab52bde403c9291f80a949de6303af04aa1a706ca4b054f45e94d4749b729ddf2b50849abaae1f681c3bb48ddfce1166fd804b9197d14af5fff9a52e48b0707916091516ed67c4c1e519b51478ecc25c89d9ad7a6f1e29e263b35cb54ca75ebe8bc2d7a82a3f262108abc75592467ccf5defe9e46f3706cc90ae67a4b38910e61a05ff62a9d3ec383bd352143
--dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
--logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
--tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
--tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
/etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created platform certificate locally.
Successfully created NVRAM area 0x1c2 for RSA 2048 EK certificate.
Successfully created NVRAM area 0x1c08000 for platform certificate.
Successfully created ECC EK with handle 0x81010016.
  Invoking /usr/share/swtpm/swtpm-localca --type ek --ek
x=0ecc2c9a02316295724304fcdeb9802c6d2f2d5fa40c34717ea9ff64f4d5e969c79f6eaba9bf4f8e6c67416057542a7e,y=6d54604b00bbbc83f8e9d02983c3486514218c9eabf29dbfc692058506828b299cec8605be490173ebe1727719ff5c90,id=secp384r1
--dir /var/lib/libvirt/swtpm/5e3c8d62-c0ef-41d7-9b7f-cddf618df88a/tpm2
--logfile /var/log/swtpm/libvirt/qemu/Megaera-swtpm.log --vmid
Megaera:5e3c8d62-c0ef-41d7-9b7f-cddf618df88a --tpm-spec-family 2.0
--tpm-spec-level 0 --tpm-spec-revision 162 --tpm-manufacturer id:1014
--tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile
/etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created EK certificate locally.
Successfully created NVRAM area 0x1c00016 for ECC EK certificate.
Successfully activated PCR banks sha1,sha256 among
sha1,sha256,sha384,sha512.
Successfully authored TPM state.
Ending vTPM manufacturing @ Thu 01 Jul 2021 10:48:40 PM PDT
___
vfio-users mailing list
vfio-users@redhat.com
https://listman.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] VFIO Setup Suddenly Stopped Working On OpenSUSE Tumbleweed / AMD 3700X / Asus Prime X570-Pro / AMD Vega 64

2020-02-15 Thread Brett Peckinpaugh
Did you verify that your bios settings for virtualization were not reset?


 Original Message 
From: qe...@cock.li
Sent: Sat Feb 15 08:12:14 PST 2020
To: vfio-users@redhat.com
Subject: [vfio-users] VFIO Setup Suddenly Stopped Working On OpenSUSE 
Tumbleweed / AMD 3700X / Asus Prime X570-Pro / AMD Vega 64

Essentially since I reset my bios/uefi no GPU has passed through and 
produced any video, and the vm typically dies according to the cpu usage 
monitor in virt-manager. To my knowledge all that I need is to enable 
SVM, IOMMU, and SR-IOV. Here’s all the info I can think of to add off 
the top of my head https://paste.debian.net/1130253/ (dmesg, vm.xml, vm 
log when starting up, /etc/modprobe.d/10-vfio.conf, 
/etc/modules-load.d/vfio.conf, /etc/default/grub, and 
/etc/dracut.conf.d/vfio.conf). Anyone have any ideas as to what I’m 
doing wrong here? Any help is greatly appreciated I’ve been trying all 
sorts of stuff to no luck the past week.


___
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] "BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8"

2018-02-23 Thread Brett Peckinpaugh
I pass a USB pci card also.  Guess I better be ready to roll back if I update. 

On February 23, 2018 6:41:15 PM PST, Will Marler  wrote:
>Thanks Nick.
>
>The kernel does not appear to be *entirely* broken for vfio. I figured
>out
>that if I didn't pass a specific PCI card to my guest, the guest would
>start. So VGA passthrough is still working; the device that breaks the
>kernel (for me anyway) is a PCI USB adapter.
>
>On Fri, Feb 23, 2018 at 7:32 PM, Brett Peckinpaugh 
>wrote:
>
>> So is the entire 4.15 kernel broken for vfio?
>>
>> On February 23, 2018 6:15:38 PM PST, Nick Sarnie
>
>> wrote:
>>>
>>> On Fri, Feb 23, 2018 at 6:04 PM, Will Marler 
>wrote:
>>>
>>>>  I'm running Arch and updating recently has caused my VM to stop
>booting.
>>>>
>>>>  Watching journalctl I see this when I try to start the VM:
>>>>
>>>>  "Feb 23 15:04:07 haze kernel: BUG: unable to handle kernel NULL
>pointer
>>>>  dereference at 00a8
>>>>  Feb 23 15:04:07 haze kernel: IP: down_write+0x12/0x30
>>>>
>>>>  and some more. Full pastebin is here:
>https://pastebin.com/8u70XLWJ
>>>>
>>>>  This happens when I try to start my domain (called "Win10Full").
>When it
>>>>  occurs, virsh locks up -- if I'm in virsh and do "list" it sits
>>>>  indefinitely. If I ctrl-C at this point, "End of file while
>reading data:
>>>>  Input/output error" gets written to the log, and my host cannot be
>rebooted
>>>>  without a physical power cycle.
>>>>
>>>>  There is nothing that gets written to
>/var/log/libvirt/qemu/Win10Full.log.
>>>>
>>>>  I'm not sure how to proceed; I figured this mailing list would be
>the first
>>>>  place to start. Any suggestions?
>>>>
>>>>  Thanks in advance,
>>>>
>>>>  Will
>>>>
>>>> --
>>>>
>>>>  vfio-users mailing list
>>>>  vfio-users@redhat.com
>>>>  https://www.redhat.com/mailman/listinfo/vfio-users
>>>
>>>
>>>
>>> Hi,
>>>
>>> This is a bug in 4.15. You can either revert to 4.14, or revert this
>>> patch and recompile the kernel:
>>>
>>> https://patchwork.kernel.org/patch/10103043/raw/
>>>
>>> Sarnex
>>>
>>> --
>>>
>>> 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] "BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8"

2018-02-23 Thread Brett Peckinpaugh
So is the entire 4.15 kernel broken for vfio? 

On February 23, 2018 6:15:38 PM PST, Nick Sarnie  
wrote:
>On Fri, Feb 23, 2018 at 6:04 PM, Will Marler  wrote:
>> I'm running Arch and updating recently has caused my VM to stop
>booting.
>>
>> Watching journalctl I see this when I try to start the VM:
>>
>> "Feb 23 15:04:07 haze kernel: BUG: unable to handle kernel NULL
>pointer
>> dereference at 00a8
>> Feb 23 15:04:07 haze kernel: IP: down_write+0x12/0x30
>>
>> and some more. Full pastebin is here: https://pastebin.com/8u70XLWJ
>>
>> This happens when I try to start my domain (called "Win10Full"). When
>it
>> occurs, virsh locks up -- if I'm in virsh and do "list" it sits
>> indefinitely. If I ctrl-C at this point, "End of file while reading
>data:
>> Input/output error" gets written to the log, and my host cannot be
>rebooted
>> without a physical power cycle.
>>
>> There is nothing that gets written to
>/var/log/libvirt/qemu/Win10Full.log.
>>
>> I'm not sure how to proceed; I figured this mailing list would be the
>first
>> place to start. Any suggestions?
>>
>> Thanks in advance,
>>
>> Will
>>
>> ___
>> vfio-users mailing list
>> vfio-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>
>Hi,
>
>This is a bug in 4.15. You can either revert to 4.14, or revert this
>patch and recompile the kernel:
>
>https://patchwork.kernel.org/patch/10103043/raw/
>
>Sarnex
>
>___
>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] Awful boot times, current OVMF to blame?

2017-08-28 Thread Brett Peckinpaugh
I have been using one from March last year. Do we know if there is to be an 
updates version with out the boot issue available soon? And would it be 
beneficial to update then?

On August 28, 2017 9:47:52 AM PDT, Martin Schrodt  wrote:
>Hey John,
>
>thanks for the advice, I saw that the old version of OVMF fixed it for
>you after I replied, and will try to use it when I come around (next
>weekend)
>
>Cheers!
>
>On 08/28/2017 05:31 PM, John Koelndorfer wrote:
>> Hi Martin,
>> 
>> I wrote previously that using a specific version of OVMF fixed the
>issue
>> for me. My almost-complete VFIO setup is documented at
>>
>https://github.com/jkoelndorfer/local-tools/tree/master/workstation/vfio,
>including
>> an RPM containing the OVMF revision I'm using now. Try that one and
>see
>> if it works. The CPU exposed to the VM in my configuration is the
>> equivalent of "host-passthrough" in libvirt as far as I know.
>> 
>> If that old version of OVMF doesn't work, take a look at the other
>bits
>> of my config and see what the differences might be. I've got a pretty
>> good experience with the launch script I have right now.
>> 
>> That reminds me, I need to get around to a kernel bisection one of
>these
>> days.
>> 
>
>___
>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] Onboard sound card to my VM

2017-08-14 Thread Brett Peckinpaugh
Name one, I have looked. Everyone I saw was an old pci e version. 

On August 14, 2017 8:16:30 PM PDT, Alex Williamson 
 wrote:
>On Mon, Aug 14, 2017 at 9:07 PM, taii...@gmx.com 
>wrote:
>
>>
>> I am not sure but I think there are no pci-e audio cards that support
>> IOMMU AFAIK.
>>
>
>False, especially for device assignment, the drivers in the guest and
>the
>guest itself is completely unaware of the IOMMU.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] GPU Pass Through with KVM

2017-07-16 Thread Brett Peckinpaugh
Skylake has no iommu separation. The only way I got it to work was with that 
unsupported ACS patch. You might be able to get the host to run on the igd and 
passthrough the video card but odds are too many devices share the same root 
port. 

Have you read Alex's website guide? It helped me alot. 

http://vfio.blogspot.com/2016/10/how-to-improve-performance-in-windows-7.html?m=1


On July 16, 2017 9:25:57 PM PDT, Chris Crutchfield  wrote:
>I have tried a few different distros (Ubuntu 16.04, Arch Linux, Fedora
>25) and have been unsuccessful at getting my GPU to correctly
>passthrough.  I have been trying to use Windows 10 x64 1703 for my
>guest.  It runs correctly without my GPU connected to the VM, but
>typically, but not always, fails when the GPU is connected.
>
>CPU: Intel I7 Skylake
>GPU: AMD Radeon R9 380
>
>Below are the results when I run “uname -r”
>4.11.8-200.fc25.x86_64
>
>Below are the results when I run “lspci -nnk”
>00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM
>Registers [8086:191f] (rev 07)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>   Kernel driver in use: skl_uncore
>00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller
>(x16) [8086:1901] (rev 07)
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
>00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB
>3.0 xHCI Controller [8086:a12f] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>   Kernel driver in use: xhci_hcd
>00:16.0 Communication controller [0780]: Intel Corporation Sunrise
>Point-H CSME HECI #1 [8086:a13a] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
>00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA
>controller [AHCI mode] [8086:a102] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>   Kernel driver in use: ahci
>00:1b.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Root
>Port #17 [8086:a167] (rev f1)
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
>00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #1 [8086:a110] (rev f1)
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
>00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #9 [8086:a118] (rev f1)
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
>00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC
>Controller [8086:a145] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H PMC
>[8086:a121] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio
>[8086:a170] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:86c9]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
>00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus
>[8086:a123] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
>   Kernel driver in use: i801_smbus
>   Kernel modules: i2c_i801
>00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
>Connection (2) I219-V [8086:15b8] (rev 31)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8672]
>   Kernel driver in use: e1000e
>   Kernel modules: e1000e
>01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
>[AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:04e3]
>   Kernel driver in use: vfio-pci
>   Kernel modules: amdgpu
>01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>Tonga HDMI Audio [Radeon R9 285/380] [1002:aad8]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:aad8]
>   Kernel driver in use: vfio-pci
>   Kernel modules: snd_hda_intel
>02:00.0 Non-Volatile memory controller [0108]: Lite-On Technology
>Corporation M8Pe Series NVMe SSD [14a4:22f1] (rev 01)
>   Subsystem: Marvell Technology Group Ltd. Device [1b4b:1093]
>   Kernel driver in use: nvme
>   Kernel modules: nvme
>03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1
>Host Controller [1b21:1242]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8675]
>   Kernel driver in use: xhci_hcd
>
>I know very little about KVM and am unsure about how to go about
>troubleshooting.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] Another Nvidia code 43 error

2016-11-17 Thread Brett Peckinpaugh
Has anyone verified if the video card has uefi firmware? 

On November 17, 2016 7:33:32 AM PST, Thomas Mashos  wrote:
>Sorry, guess I didn't reply all last time.
>
>Just uninstalled the Nvidia driver and let windows search for and
>install
>the driver. Let it reboot a few times, no deal. Still code 43 :(
>
>I'm still using the default Ubuntu kernel
>Linux smitty 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC
>2016
>x86_64 x86_64 x86_64 GNU/Linux
>
>Here's my current XML, which I tried changing the CPU topology to match
>yours, still getting error code 43.
>http://termbin.com/3n44
>
>Not sure what else to try here, maybe I should try a Win 7 install? I
>think
>I still have one of those DVD's laying around.
>
>
>On Wed, Nov 16, 2016 at 10:33 PM Eddie Yen 
>wrote:
>
>> OKnow things change to difficult.
>>
>> Can you post your XML again after you edit?
>> Also, did you change kernel or still using Ubuntu official version?
>> I don't want to suspect but I think it had few connection inside.
>>
>> And here is my XML code when running K420 /w Windows 7, as a
>reference.
>> Also don't forget to reply the mail back to VFIO milling list, maybe
>other
>> people can help :)
>>
>> 2016-11-17 13:34 GMT+08:00 Thomas Mashos :
>>
>> Just uninstalled the Nvidia driver and let windows search for and
>install
>> the driver. Let it reboot a few times, no deal. Still code 43 :(
>>
>> On Wed, Nov 16, 2016 at 7:33 PM Eddie Yen 
>wrote:
>>
>> Roger that,
>>
>> What about try the driver version from Windows 10, not NVIDIA
>official
>> download?
>> I remember Windows 10 has built GeForce 700 Series driver inside.
>>
>> 2016-11-17 11:04 GMT+08:00 Thomas Mashos :
>>
>> I've now tried both those options (I tried a few different machine
>types
>> too) with no luck.
>>
>> I forgot to mention that I also tried the setting the interrupts to
>MSI
>> via the registry for the GTX 760, but that didn't seem to switch it
>to MSI
>> on reboot.
>>
>> On Wed, Nov 16, 2016 at 6:08 PM Eddie Yen 
>wrote:
>>
>> Hi Thomas,
>>
>> Basically KVM  equals kvm=off, so you can keep it.
>>
>> And there is no need to reinstall NVIDIA driver whenever you change
>XML
>> code.
>>
>> If you already tried remove Hyper-V features and still got Code 43,
>> there're few ways you can try.
>>
>> 1. Set CPU as "host-passthrough" mode
>> 2. You can type virsh capabilities to see how many machine type you
>can
>> use, and try different i440fx version.
>> Some GPU may got a problem if using higher version of i440fx
>>
>> I'm running K420 on server, and guest OS is Windows 7. But I'm not
>using
>> third-party ppa to install newer QEMU and libvirt, all I do is
>compile and
>> install by myself. Using OVMF and i440fx-2.6 and it works perfectly
>without
>> Hyper-V (Because Windows 7 can't enable Hyper-V in OVMF mode.)
>>
>> I'm not sure these tip works on you or not, just give it a try :)
>>
>> 2016-11-17 9:40 GMT+08:00 Thomas Mashos :
>>
>> Hi Eddie,
>>
>> XML Dump is here  http://termbin.com/mwwd it's a Windows 10 Home
>64-bit
>> guest. I've previously tried with the hyperv features section
>removed, I
>> can try that again if you want. As for the kvm=off, is that different
>that
>> setting kvm's hidden state to on?
>>
>> This might be a dumb question, but do I need to reinstall the nvidia
>> drivers after each of these changes I test in the XML file? I've just
>been
>> shutting down the VM, making the change and booting it again, then
>checking
>> device manager.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 5:32 PM Eddie Yen 
>wrote:
>>
>> OK, forgot the previous message.
>>
>> Try to remove Hyper-V features, only leave kvm=off and try.
>>
>> Thanks,
>>
>> 2016-11-17 9:30 GMT+08:00 Eddie Yen :
>>
>> Hi
>>
>> Can you post your XML file? Also call tell which Windows version
>you're
>> using on guest?
>>
>> Thanks,
>>
>> 2016-11-17 9:18 GMT+08:00 Thomas Mashos :
>>
>> I've gone through reinstalls and multiple guides (
>>
>http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-3-host.html
>a
>> few times) and I'm not sure what to do next, no matter what I try I
>always
>> get the error code 43.
>>
>> My setup. I have a "server" in my closet that has 2 nvidia cards in
>(a
>> GeForce GT 430 to run the system, a GeForce GTX 760 dedicated to the
>VM).
>> I've setup the GTX 760 to use the stub (see below). The processor I
>have is
>> a 'Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz', so no integrated
>graphics on
>> that and the motherboard doesn't have any integrated graphics either.
>The
>> server runs Ubuntu Server 16.04.1, but has libvirt and qemu updated
>from a
>> PPA (see versions below). The VM is a Win 10 64-bit Home install with
>the
>> NVidia 375.70 drivers installed from their website.
>>
>> I've verified that if I pull the GT 430 from the box that I can see
>the
>> boot on the GTX 760. If I leave both cards in, I don't see anything
>on the
>> GTX 760 ever. One thing to note is that I setup the VM using
>virt-manager
>> 1.3.2 from a 16.10 machine, so in th

Re: [vfio-users] Users of X99-boards, can you do me a small favor?

2016-10-04 Thread Brett Peckinpaugh
What are you settling that fixes the Nvidia experience complaint? 

On October 4, 2016 9:15:56 AM PDT, Hristo Iliev  wrote:
>Hi Martin,
>
>Am 04.10.2016 10:09, schrieb Martin Schrodt:
>> Hi Hristo,
>> 
>>> No need to sleep/wake - my X99-based system starts with TSC
>disabled:
>>> 
>>> $ dmesg | grep TSC
>>> [0.00] tsc: Fast TSC calibration using PIT
>>> [0.077986] TSC deadline timer enabled
>>> [0.203383] TSC synchronization [CPU#0 -> CPU#1]:
>>> [0.203384] Measured 974558547804462 cycles TSC warp between
>CPUs,
>>> turning off TSC clock.
>>> [0.203388] tsc: Marking TSC unstable due to
>check_tsc_sync_source
>>> failed
>>> 
>>> Consequently, tsc is not among the clock sources listed in
>>> available_clocksource. KVM is not happy about that:
>>> 
>>> [16739.200656] kvm: SMP vm created on host with unstable TSC; guest 
>>> TSC
>>> will not be reliable
>> 
>> Ok, so an X99-board that behaves like this even on a fresh start.
>> Interesting.
>> 
>>> But I haven't observed any instabilities of the Windows 10 guest, 
>>> which
>>> happily runs with 4 virtual CPUs (2 virtual hyperthreaded CPUs)
>bound 
>>> to
>>> two cores of my i7-5820K.
>> 
>> This really makes me think there's something else involved in this
>> behaviour. Maybe the CPU configuration (I use "Skylake-Client")
>exposes
>> TSC to the guest, so if you put that on, it'll use it?
>> 
>> Can you check what kind of virtual CPU you use?
>> 
>
>I use 'passthrough', otherwise the default 'Haswell-noTSX' that 
>virt-manager picks results in NVIDIA GeForce Experience complaining 
>about unrecognised CPU type, so the TSC gets pretty much exposed to the
>
>guest.
>
>Just found this paste with a boot log from another system with the same
>
>motherboard, though with an older BIOS version and a Xeon E5-1620 v3 
>CPU:
>
>https://pastelink.net/fjm
>
>It shows the same problem with unsynchronised TSCs. Could also be 
>something specific to the LGA 2011v3 processors or to the EFI BIOS.
>I'll 
>take a look in the BIOS options when time permits.
>
>> Cheers,
>> Martin
>
>Cheers,
>Hristo
>
>___
>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] Z170X IOMMU Groups

2016-09-22 Thread Brett Peckinpaugh
Same here I have a ud5 that I would like a bios that does not need the ACS 
patch. 

On September 22, 2016 8:59:57 PM PDT, Wei Xu  wrote:
>
>
>On 2016年09月23日 02:47, Nick Sarnie wrote:
>> Hi again,
>>
>> Very much to my surprise, Gigabyte replied and sent me a fixed BIOS.
>The
>> new IOMMU groups (with ACS override patch kernel commandline removed
>for
>> this boot), as well as my lspci information are below. I see four
>> messages the following messages in dmesg now:
>>
>> [0.523892] pci :00:1c.0: Intel SPT PCH root port ACS
>workaround
>> enabled
>> [0.524031] pci :00:1c.4: Intel SPT PCH root port ACS
>workaround
>> enabled
>> [0.524159] pci :00:1c.5: Intel SPT PCH root port ACS
>workaround
>> enabled
>> [0.524292] pci :00:1d.0: Intel SPT PCH root port ACS
>workaround
>> enabled
>>
>>
>> IOMMU Groups: http://pastebin.com/raw/0dcHk8Xk
>> lspci: http://pastebin.com/raw/1zAZuPBM
>
>That's cool, how did you report your issue to Gigabyte? I'd like to
>have 
>a try as well.
>
>Wei
>
>>
>> Alex, please let me know if they missed anything else, so I can
>report
>> it to them.
>>
>> Thanks,
>> Nick
>>
>> On Sun, Sep 18, 2016 at 4:03 PM, Nick Sarnie > > wrote:
>>
>> Hi again,
>>
>> Thanks a lot for investigating. I've reported the issue to the
>> manufacturer.
>>
>>
>> Thanks,
>> sarnex
>>
>> On Sat, Sep 17, 2016 at 5:35 PM, Alex Williamson
>> >
>> wrote:
>>
>> On Sat, Sep 17, 2016 at 12:29 PM, Nick Sarnie
>> mailto:commendsar...@gmail.com>>
>wrote:
>>
>> Hi Alex,
>>
>> The output is here: http://pastebin.com/raw/qjnpuaVr
>> 
>>
>>
>> Ok, you need to go complain to your motherboard manufacturer,
>> they're the ones hiding the ACS capability.  PCIe
>capabilities
>> always start at 0x100, the dword there is:
>>
>> 100: 01 00 01 22 = 0x22010001
>>
>> Breaking that down, the capability at 0x100 is ID 0x0001
>(AER),
>> version 0x1, and the next capability is at 0x220.  So we do
>the
>> same there:
>>
>> 220: 19 00 01 00 = 0x00010019
>>
>> Capability ID 0x0019 (Secondary PCIe), version 0x1, next
>> capability 0x0, terminating the capability list.
>>
>> Per Intel documentation for the chipset
>>
>(http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html
>>
>),
>> the ACS capability and control registers live at 0x144 and
>0x148
>> respectively and we can see that you do have data here
>matching
>> the default value of the capability register:
>>
>> 140: 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00
>>
>> ie. default value of 0x144 is 0xf.  It appears that this BIOS
>> vendor didn't connect the capability into the chain or fill
>in
>> the capability header.  The registers to do this are RW/O,
>ie.
>> Read-Write-Once.  IOW, the registers can only be written
>once,
>> which is intended to be used by the BIOS.  The capability
>bits
>> themselves are RW/O, allowing vendors to expose different
>sets
>> of ACS capabilities.  Given that this vendor has not exposed
>the
>> capability, we have no basis to believe that the default
>value
>> of the register represents the real capabilities of the
>system
>> and therefore we cannot assume we're able to control ACS. 
>File
>> a bug with the vendor or look for a BIOS update where they
>may
>> have already fixed this.
>>
>> Also, is there any way we could move the USB controller
>into
>> its own group, or remove the Ethernet and SATA controller
>> into a seperate group? Ideally, I could pass the USB
>> Controller in group 7 without the ACS patch.
>>
>>
>> That's not how IOMMU groups works.  See
>>
>http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html
>
>>   We aren't creating these groups arbitrarily, we base them
>on
>> the information provided to use by the IOMMU driver and PCI
>> topology features, including ACS.  If we cannot determine
>that
>> there is isolation between components, we must assume that
>they
>> are not isolated.  Your choices are to run an unsupported
>(and
>> unsupportable) configuration using the ACS override patch,
>get
>> your hardware vendor to fix their platform, or upgrade to
>better
>> hardware with better isolation characteristics.
>>
>>
>>
>>
>>
>> ___
>> vfio-users mailing list
>> vfio-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/vfi

Re: [vfio-users] Z170X IOMMU Groups

2016-09-16 Thread Brett Peckinpaugh
So I might be able to drop the ACS patch now that 4.7 is out on Arch. 

On September 16, 2016 5:39:43 PM PDT, Alex Williamson 
 wrote:
>On Fri, Sep 16, 2016 at 6:30 PM, Nick Sarnie 
>wrote:
>
>> Hi,
>>
>> I was wondering if we could split group 7 any more. CPU is the 6700k.
>I'd
>> like to be able to pass through the USB controller without the ACS
>patch.
>>
>
>Run a newer kernel, Intel botched ACS in Skylake:
>
>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/quirks.c?id=1bf2bf229b64540f91ac6fa3af37c81249037a0b
>
>PCH PCIe root ports have isolation starting in v4.7.
>
>
>
>
>___
>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] Z170X IOMMU Groups

2016-09-16 Thread Brett Peckinpaugh
Running skylake myself and the IOMMU groups suck. Only options are the 
unsupported ACS patch or to passthrough the USB devices and leave the 
controller with the host. 

On September 16, 2016 5:30:38 PM PDT, Nick Sarnie  
wrote:
>Hi,
>
>I was wondering if we could split group 7 any more. CPU is the 6700k.
>I'd
>like to be able to pass through the USB controller without the ACS
>patch.
>
>Thanks,
>Sarnex
>
>IOMMU group 0
>00:00.0 Host bridge [0600]: Intel Corporation Skylake Host
>Bridge/DRAM Registers [8086:191f] (rev 07)
>IOMMU group 1
>00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe
>Controller (x16) [8086:1901] (rev 07)
>  01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>Inc. [AMD/ATI] Ellesmere [Radeon RX 480] [1002:67df] (rev c7)
>01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>Device [1002:aaf0]
>IOMMU group 2
>   00:02.0 Display controller [0380]: Intel Corporation HD Graphics
>530 [8086:1912] (rev 06)
>IOMMU group 3
>   00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H
>USB 3.0 xHCI Controller [8086:a12f] (rev 31)
>00:14.2 Signal processing controller [1180]: Intel Corporation
>Sunrise Point-H Thermal subsystem [8086:a131] (rev 31)
>IOMMU group 4
> 00:16.0 Communication controller [0780]: Intel Corporation Sunrise
>Point-H CSME HECI #1 [8086:a13a] (rev 31)
>IOMMU group 5
>  00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H
>SATA controller [AHCI mode] [8086:a102] (rev 31)
>IOMMU group 6
>   00:1b.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Root Port #17 [8086:a167] (rev f1)
>IOMMU group 7
>   00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #1 [8086:a110] (rev f1)
>   00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #5 [8086:a114] (rev f1)
>   00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #6 [8086:a115] (rev f1)
> 03:00.0 PCI bridge [0604]: Intel Corporation DSL6540 Thunderbolt 3
>Bridge [Alpine Ridge 4C 2015] [8086:1578]
> 04:00.0 PCI bridge [0604]: Intel Corporation DSL6540 Thunderbolt 3
>Bridge [Alpine Ridge 4C 2015] [8086:1578]
> 04:01.0 PCI bridge [0604]: Intel Corporation DSL6540 Thunderbolt 3
>Bridge [Alpine Ridge 4C 2015] [8086:1578]
> 04:02.0 PCI bridge [0604]: Intel Corporation DSL6540 Thunderbolt 3
>Bridge [Alpine Ridge 4C 2015] [8086:1578]
> 04:04.0 PCI bridge [0604]: Intel Corporation DSL6540 Thunderbolt 3
>Bridge [Alpine Ridge 4C 2015] [8086:1578]
>   07:00.0 USB controller [0c03]: Intel Corporation DSL6540 USB 3.1
>Controller [Alpine Ridge] [8086:15b6]
> 09:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit
>Network Connection [8086:1539] (rev 03)
>0a:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062
>Serial ATA Controller [1b21:0612] (rev 02)
>IOMMU group 8
>   00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #9 [8086:a118] (rev f1)
>   00:1d.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI
>Express Root Port #13 [8086:a11c] (rev f1)
>0b:00.0 Network controller [0280]: Qualcomm Atheros AR93xx Wireless
>Network Adapter [168c:0030] (rev 01)
>IOMMU group 9
>   00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC
>Controller [8086:a145] (rev 31)
>00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H
>PMC [8086:a121] (rev 31)
>  00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD
>Audio [8086:a170] (rev 31)
>00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus
>[8086:a123] (rev 31)
>IOMMU group 10
>00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
>Connection (2) I219-V [8086:15b8] (rev 31)
>
>
>
>
>___
>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] VM Won't boot with 2 PCIE 1x cards installed.

2016-09-08 Thread Brett Peckinpaugh
I am running Arch Linux, ACS patch on a Skylake system.  I have some 
audio pop and crackle so wanted to try passing a sound card instead of 
routing the audio from my monitor to my speakers.  I purchased an Asus 
Xonar PCI DGX.  Chip is CMI8788.  I can boot the host with it, or my USB 
card.  But not both.  Error I get is as follows.


Error starting domain: internal error: qemu unexpectedly closed the 
monitor: 2016-09-09T01:17:41.729237Z qemu-system-x86_64: -device 
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: vfio: Error: 
Failed to setup INTx fd: Device or resource busy
2016-09-09T01:17:41.729854Z qemu-system-x86_64: -device 
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: Device 
initialization failed


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in 
cb_wrapper

callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in 
tmpcb

callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, 
in newfn

ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in 
startup

self._backend.create()
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 1035, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: qemu unexpectedly closed the monitor: 
2016-09-09T01:17:41.729237Z qemu-system-x86_64: -device 
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: vfio: Error: 
Failed to setup INTx fd: Device or resource busy
2016-09-09T01:17:41.729854Z qemu-system-x86_64: -device 
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: Device 
initialization failed


I added the address for all devices to my VFIO.conf under modprode.d 
using options vfio-pci ids= to hopefully leave them only for the guest.  
But I doubt that is helping because I can start them with one or the 
other just not both.  Other than the pop and crack occasionally the 
guest runs great.  Below are my IOMMU groupings with IDs.  I am running 
out of ideas, not that I am an expert and could use a bit of help.


IOMMU group 0
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host 
Bridge/DRAM Registers [8086:191f] (rev 07)

IOMMU group 1
00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe 
Controller (x16) [8086:1901] (rev 07)

IOMMU group 2
00:01.1 PCI bridge [0604]: Intel Corporation Skylake PCIe 
Controller (x8) [8086:1905] (rev 07)

IOMMU group 3
00:14.0 USB controller [0c03]: Intel Corporation Sunrise 
Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31)
00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-H Thermal subsystem [8086:a131] (rev 31)

IOMMU group 4
00:16.0 Communication controller [0780]: Intel Corporation 
Sunrise Point-H CSME HECI #1 [8086:a13a] (rev 31)

IOMMU group 5
00:17.0 SATA controller [0106]: Intel Corporation Sunrise 
Point-H SATA controller [AHCI mode] [8086:a102] (rev 31)

IOMMU group 6
00:1b.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Root Port #17 [8086:a167] (rev f1)

IOMMU group 7
00:1b.3 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Root Port #20 [8086:a16a] (rev f1)

IOMMU group 8
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #1 [8086:a110] (rev f1)

IOMMU group 9
00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #5 [8086:a114] (rev f1)

IOMMU group 10
00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #6 [8086:a115] (rev f1)

IOMMU group 11
00:1c.7 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #8 [8086:a117] (rev f1)

IOMMU group 12
00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #9 [8086:a118] (rev f1)

IOMMU group 13
00:1d.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H 
PCI Express Root Port #13 [8086:a11c] (rev f1)

IOMMU group 14
00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H 
LPC Controller [8086:a145] (rev 31)
00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-H PMC [8086:a121] (rev 31)
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H 
HD Audio [8086:a170] (rev 31)
00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus 
[8086:a123] (rev 31)

IOMMU group 15
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection (2) I219-V [8086:15b8] (rev 31)

IOMMU group 16
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation 
GF110 [GeForce GTX 560 Ti 448 Cores] [10de:1087] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GF110 High 
Definition Audio Controller [10de:0e09] (rev a1)

IOMMU group 17
02:00.0 VGA compatible controller [0300]

Re: [vfio-users] Boot using second GPU?

2016-08-07 Thread Brett Peckinpaugh
I an running a gigabyte z170 board and cannot set primary graphic card. Primary 
is what is in PCIe 1.

On August 7, 2016 7:14:05 AM PDT, Rokas Kupstys  wrote:
>Thanks for reply. Since i am making a new build i am looking for proper
>motherboard. One i sided with is from asus, but it seems asus
>motherboards do not support switching primary GPU. I might go with
>gigabyte if there is no way to solve this. I am not sure yet though.
>Switching primary gpu in bios is ultimate solution. Directions i
>provided in earlier mail are workaround for people who do not have such
>capability. It is a tricky choice.. Go with beloved asus and suffer
>minor inconvenience or go with gigabyte.. Did you have any problems
>with
>gigabyte motherboard(s)?
>
>
>Rokas Kupstys
>
>On 2016.08.05 14:44, Hristo Iliev wrote:
>> Am 05.08.2016 10:22, schrieb Rokas Kupstys:
>>
>>> Okay this is unexpected luck. After more tinkering i got it to work!
>>> Here is my setup:
>>>
>>> * AMD FX-8350 CPU + Sabertooth 990FX R2 motherboard
>>> * :01:00.0 - gpu in first slot
>>> * :06:00.0 - gpu in third slot
>>> * UEFI on host and guest.
>>> * Archlinux
>>>
>>> In order to make host use non-boot GPU:
>>>
>>> 1. Add Kernel boot parameter "video=efifb:off". This makes kernel
>not
>>> use first gpu and boot messages appear on second gpu.
>>>
>>> 2. Bind first gpu (:01:00.0) to vfio-pci driver. I did this by
>>> adding line
>>>
 options vfio-pci ids=1002:677B,1002:AA98
>>> to /etc/modprobe.d/kvm.conf. They are obtained from "lspci -n" which
>>> in my case show:
>>>
 01:00.0 0300: 1002:677B
 01:00.1 0403: 1002:AA98
>>> 3. Configure xorg to use second gpu (:06:00.0). I added file
>>> /etc/X11/xorg.conf.d/secondary-gpu.conf with contents:
>>>
 Section "Device"
 Identifier "Device0"
 Driver "radeon"
 VendorName "AMD Corporation"
 BoardName  "AMD Secondary"
 BusID  "PCI:6:0:0"
 EndSection
>>> And thats it! Now when machine boots it shows POST messages and
>>> bootloader on first gpu, but as soon as boot option is selected
>>> display goes blank and kernel boot messages show on second gpu.
>After
>>> boot you can assign first gpu to VM as usual and it works.
>>> HELP REQUEST: could someone with intel hardware (ideally x99
>chipset)
>>> test this method? I am planning a build and if this works i could
>>> settle with 28 lane cpu and save couple hundred dollars. Intel's 40
>>> lane cpus are way overpriced.. And with 28 lane cpus only first slot
>>> can run at x16 speed while other slots downgrade to x8 or less.
>>> Anyhow i would love to hear if this works on intel hardware.
>>>
>>
>> Hi,
>>
>> I have a Gigabyte GA-X99-UD4 motherboard and i7-5820K. There are two
>GPUs
>> in it - a GTX 970 for pass-through on 03:00.0 and a GT 730 as primary
>GPU
>> on 06:00.0. The PCIE slot of the GT is selected as primary video
>output
>> in the UEFI settings. All text and graphics output goes to it - the
>> output
>> of the GTX card remains off the entire time until the VM is booted.
>The X
>> server does see both cards but since the nvidia module is prevented
>from
>> binding to the GTX, X cannot use it and starts on the GT. No fiddling
>> with
>> the console driver parameters necessary.
>>
>> Distribution:
>>Arch Linux, 4.6.4-1-ARCH
>>
>> Kernel parameters:
>>... pci-stub.ids=10de:13c2,10de:0fbb,8086:8d20
>nvidia-drm.modeset=1
>> ...
>>
>> /etc/modprobe.d/vfio.conf:
>>options vfio-pci ids=10de:13c2,10de:0fbb,8086:8d20
>>
>> /etc/mkinitcpio.conf:
>>...
>>MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd vfat
>aes_x86_64
>> crc32c_intel nvidia nvidia_modeset nvidia_uvm nvidia_drm"
>>...
>>
>> /etc/X11/xorg.conf.d/20-nvidia.conf:
>>Section "Device"
>> Identifier"Device0"
>> Driver"nvidia"
>> VendorName"NVIDIA Corporation"
>> Option "ConnectToAcpid"   "0"
>>EndSection
>>
>> The only problem with my setup is that the GTX is in PCIE_2, which
>works
>> as x8 with i7-5820K installed. I cannot fit the card in PCIE_1
>because of
>> the oversized CPU cooler. This doesn't actually bug me at all as
>multiple
>> tests (for example, [1]) have shown negligible difference in gaming
>FPS
>> between PCI-e 3.0 x8 and x16. The GT card is in PCIE_4.
>>
>> Kind regards,
>> Hristo
>>
>> [1]
>>
>http://www.gamersnexus.net/guides/2488-pci-e-3-x8-vs-x16-performance-impact-on-gpus
>>
>>> Rokas Kupstys
>>>
>>> On 2016.08.05 10:34, Rokas Kupstys wrote:
>>>
>>> I think i got half-way there.. My primary gpu is at :01:00.0 and
>>> secondary on :06:00.0. I used following xorg config:
>>>
>>> Section "Device"
>>> Identifier "Device0"
>>> Driver "radeon"
>>> VendorName "AMD Corporation"
>>> BoardName  "AMD Secondary"
>>> BusID  "PCI:6:0:0"
>>> EndSection
>>>
>>> After booting :06:00.0 was still bound to vfio-pci (im yet to
>sort
>>> it out why as i removed modprobe configs and kern

Re: [vfio-users] Slowdown/stuttering since most recent fedora core updates

2016-07-08 Thread Brett Peckinpaugh
What kernel are you running? 4.5 gave me audio crackle and none on 4.6.  Also 
did the update you ran update the kernel? 

On July 8, 2016 11:22:10 AM PDT, Ethan Thomas  wrote:
>After changing to host-passthrough at the suggestion of someone on
>reddit,
>everything was working pretty well, I was getting usable if not stellar
>framerates in games, audio had the intermittent crackle, but was
>generally
>in sync. However I just allowed fedora core 23 to run its updates,
>thinking
>nothing of it, and since then my windows 10 guest VM is very stuttery
>in
>both audio, and framerate in games. It's even somewhat noticable in web
>broswing. The audio also sometimes now has a weird echo which I
>previously
>only heard when trying to pass through the card. Unfortunately, as I
>didnt
>anticipate any trouble, I didn't pay attention to the previous or new
>versions, but I know that it listed both system and virt-manager
>updates.
>
>Any suggestions as to what to change would be welcome. The system is a
>Dual
>Westmere Xeon, the guest GPU (a Radeon 260x) is on the same node as the
>CPUs which are pinned to it. The USB3 card is also on that node. All
>other
>PCI-E cards are on the other node. The only change I've made to the XML
>since the update was to change the version of i440fx specified, which I
>changed to match what a newly generated virt-manager VM had after the
>problem started.
>
>Additionally, but unrelated I'd like to be able to hear guest audio
>without
>the virt-manager window open, and to remove the virtual video card,
>however
>when I remove the spice video in a bios mode VM the machine never
>boots.
>I'd appreciate any relevant suggestions there too, as ideally I want to
>entirely drop spice.
>
>
>XML follows:
>
>
>  windows10
>  835693f3-f65c-4ced-b6c6-be41896621f3
>  16777216
>  16777216
>  8
>  
>hvm
>  
>  
>
>
>
>
>  
>  
>  
>
>
>  
>  
>
>  
>  
>
>
>
>
>  
>  destroy
>  restart
>  restart
>  
>
>
>  
>  
>/usr/bin/qemu-kvm
>
>  
>  
>  
>  
> 
>
>
>  
>  
>  
>  
> 
>
>
>  function='0x7'/>
>
>
>  
>  function='0x0' multifunction='on'/>
>
>
>  
>  function='0x1'/>
>
>
>  
>  function='0x2'/>
>
>
>
>  function='0x1'/>
>
>
>  
>  
>  
>  function='0x0'/>
>
>
>
>
>
>  function='0x0'/>
>
>
>  
>  function='0x0'/>
>
>
>  
>   
>  
>  function='0x0'/>
>
>
>  
>   
>  
>  function='0x0'/>
>
>
>  
>   
>  
>  function='0x0'/>
>
>
>  
>
>
>  
>
>
>
>
>
>
>  function='0x0'/>
>
>  
>   
>
>
>
>
>___
>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] Nvidia glitches on Windows 10 guest

2016-06-21 Thread Brett Peckinpaugh
Are you using huge pages? 

On June 21, 2016 10:31:22 AM PDT, Berillions  wrote:
>Hi guys,
>
>I found where come from the issue. I have really in my PC 12Gb Memory
>RAM
>(but the issue exist with real 8Gb Memory Ram).
>
>If i give 4Gb or more to the VM, i have the glitches, corruption and
>freeze. But, if i give only 2Gb for the guest the issue does not exist
>and
>i can use Win10 correctly and play at games without problem.
>
>Any ideas to find a solution to allocate more Memory Ram without to
>have
>this issue ? (Because i would like to replace my 12GB (3x4Gb) by a
>1x16Gb)
>
>Thanks by advance,
>Maxime
>
>2016-06-16 12:52 GMT+02:00 thibaut noah :
>
>> Quick question, are you posting a new email everytime? Because i got
>like
>> 2 or 3 of those on the same request, very annoying.
>> Never heard about this kind of issue though, virtual net device load
>> should be insignificant.
>>
>> 2016-06-16 12:17 GMT+02:00 Quentin Deldycke
>:
>>
>>> Possibly because managing a virtual device is expensive in cpu time?
>>> Possibly because these cpus who are managing these interrupts or
>shared
>>> with the vm?
>>> Possibly because your dpc is bad when having a network interface?
>>>
>>> Much possibilities, no information, much things already answered in
>this
>>> mailing list.
>>>
>>> First of all:
>>>  - dmesg
>>>  - dps latency on the guest
>>>  - xml file
>>>  - cpu command line
>>>  - core isolation or equivalent
>>>
>>>
>>> Note that these catch lines are not the thing people like to read:
>"Nobody
>>> to help me how to resolv this issue ? "
>>>
>>> --
>>> Deldycke Quentin
>>>
>>>
>>> On 16 June 2016 at 11:46, Berillions  wrote:
>>>
 Nobody to help me how to resolv this issue ?
 Or where i must to search to give your more informations.

 I have my linux system on a ssd and the qemu image file on a HDD.

 I don't understand why Network driver reduce and finally freeze the
 system. Uninstall it and the Win10 works great.

  I need your help guys.

 ___
 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
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] Far Cry Primal

2016-06-13 Thread Brett Peckinpaugh
That did it, added that to my config file and was able to get into the
game.   Thanks alot!

On Mon, Jun 13, 2016 at 4:50 PM, Abdulla Bubshait 
wrote:

>
>
> On Mon, Jun 13, 2016 at 6:35 PM Brett Peckinpaugh 
> wrote:
>
>> So I should try adding to my boot command line ignore_msrs=1 and give it
>> a try?
>>
>
>  You add
>
> options kvm ignore_msrs=1
>
> to /etc/modprobe.d/kvm.conf
>
> then reboot. (in other words, add ignore_msrs=1 as an option to kvm module
> load however that is done in your distro)
>
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] Far Cry Primal

2016-06-13 Thread Brett Peckinpaugh
So I should try adding to my boot command line ignore_msrs=1 and give it a
try?

On Mon, Jun 13, 2016 at 2:56 PM, Jayme Howard  wrote:

> Ah, I didn't realize those were the actual output you wanted.  I've got
> output from a few different games in dmesg, so I'll fire up Doom when I get
> home and see what it spits out and reply.
>
> On Mon, Jun 13, 2016 at 4:49 PM, Abdulla Bubshait 
> wrote:
>
>> It usually outputs the ignored msrs to dmesg.
>>
>> On Mon, Jun 13, 2016, 17:45 Jayme Howard  wrote:
>>
>>> Truthfully, I don't know offhand.  If you can tell me how to determine
>>> that, I can check it out when I get home.
>>>
>>> On Mon, Jun 13, 2016 at 4:44 PM, Abdulla Bubshait 
>>> wrote:
>>>
>>>> What msrs does doom call?
>>>>
>>>> On Mon, Jun 13, 2016, 17:36 Jayme Howard  wrote:
>>>>
>>>>> I've seen exactly the same behavior with DOOM.  ignore_msrs fixed the
>>>>> problem for me.
>>>>>
>>>>> On Mon, Jun 13, 2016 at 4:35 PM, Brett Peckinpaugh >>>> > wrote:
>>>>>
>>>>>> I wanted to see if anyone else has been able to play this on a VM.
>>>>>> At this time it is the only one, and it forces a reboot.  I have a ticket
>>>>>> in with Ubisoft, but with their heavy handed DRM I am concerned it might 
>>>>>> be
>>>>>> DRM.
>>>>>>
>>>>>> Was hoping to see if anyone has ran it to somewhat rule out the VM as
>>>>>> being part of the issue.
>>>>>>
>>>>>> ___
>>>>>> 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


[vfio-users] Far Cry Primal

2016-06-13 Thread Brett Peckinpaugh
I wanted to see if anyone else has been able to play this on a VM.  At this
time it is the only one, and it forces a reboot.  I have a ticket in with
Ubisoft, but with their heavy handed DRM I am concerned it might be DRM.

Was hoping to see if anyone has ran it to somewhat rule out the VM as being
part of the issue.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] VFIO and random host crashes

2016-05-18 Thread Brett Peckinpaugh
Are you monitoring processor utilization? 2 systems like you describe could tax 
a host. Maybe it is cpu starvation? 

On May 18, 2016 7:47:11 AM PDT, Colin Godsey  wrote:
>I’ve been running a dual gaming VM rig (2x dedicated GPU) for a little
>bit
>now, and everything works perfectly except when both VMs are under
>load,
>after an hour or so I get a hard crash and/or reboot. It will either
>reboot
>itself, or will hang so bad the physical ‘reset’ button on the box
>doesnt
>work.
>
>There is 0 evidence in the linux logs about the crash, I literally just
>see
>one of a few standard cron jobs as the syslog, then the next line is
>the
>kernel boot/start-up. Only real evidence I get is that- rarely I can
>hear
>windows crash first. Or windows will crash and Ill get maybe another
>second
>or 2 of ’top’ before the whole system goes down. I find it extremely
>odd
>that there’s some sort of (albeit fast) degradation, but absolutely
>nothing
>interesting in the logs.
>
>So, I’m pretty sure it’s something hardware related- either PSU or my
>mobo
>is crap and is underpowered somewhere. During load, there are about 5
>drives, 2 GTX GPUs, and GBe (~200mbps) all under constant load, so it
>seems
>likely it could be something chipset related.
>
>*So my question is really: is there ANY kind of kernel/vfio software
>level
>issue that could cause this crash? Or does this just sound like
>hardware?*
>I’ve tried several different power configurations at this point, I just
>want to be as sure as possible it’s hardware before i start replacing
>more
>things =\
>
>This is an up to date Ubuntu Xenial, not really running anything
>special.
>I’ve gotten away with running my VMs almost as pure as possible, no
>funny
>workarounds or anything. OVMF, Windows 10, hyper-v flags. Skylake i7 @
>z170M.
>
>
>
>
>___
>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] BSOD occuring with 1 game in VM

2016-05-11 Thread Brett Peckinpaugh
Have you tried running the game in compatibility mode set to 8.1?

On May 11, 2016 5:26:19 AM PDT, Abdulla Bubshait  wrote:
>StarCraft and heroes are the two games that have this problem, they are
>both based on the same engine. Unfortunately I cannot test the cpu
>because
>if I were to change my cpu to anything but "host" my machine will not
>boot
>(I believe this is due to a problem with the AMD drivers).
>
>I believe the MSRs are called by Windows 10, since they are privileged
>registers. Likely for debugging purposes here.
>
>I would suggest trying something more related tou your  cpu ("Haswell"
>in
>my case) instead of "core2duo". I remember when I first tried to
>install
>Win10 under virt-manager I got a KVM error about unsupported cpu
>functions
>when I tried to clone the host cpu. Setting it to Haswell cleared those
>errors so this might have something to do with it. Unfortunately that
>didn't play nice with my video card so I ended up with a command line
>setup
>as virt-manager setup refused to load AMD drivers.
>Hope this helps.
>
>Abdulla
>
>On Wed, May 11, 2016, 04:03 Ivan Volosyuk 
>wrote:
>
>> My 2c: I had the same issues with StarCraft crashing on Win10 due to
>the
>> unsupported msrs (or producing lots of logs in dmesg). On Win8.1 I
>don't
>> have this problem. My best guess is that nvidia drivers for Win10
>started
>> to use msrs unsupported by qemu. Can you change your CPU to emulated
>> core2duo and check if it actually works faster and doesn't produce
>this
>> logging spam?
>>
>> On Wed, May 11, 2016 at 4:50 PM Quentin Deldycke <
>> quentindeldy...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I also play quite much this game. Adding this option makes the game
>>> "Works".
>>>
>>> But for me, it is also the game with worst performance. As there is
>a
>>> storm of unsupported msr (not 1 or 2 but hundreds of thousands...)
>>>
>>> Do you have correct performance?  I go between 120 at begging to 15
>>> during fights.
>>>
>>> Note that this is the only game making such mess with msr. Other
>blizzard
>>> games works perfectly...
>>> On 11 May 2016 1:04 am, "Abdulla Bubshait" 
>wrote:
>>>
 Just put that in and it solved the problem.

 Thanks

 On Tue, May 10, 2016 at 6:54 PM Alex Williamson <
 alex.l.william...@gmail.com> wrote:

> On Tue, May 10, 2016 at 4:40 PM, Abdulla Bubshait
>
> wrote:
>
>> I have a pretty stable VFIO setup running for a while, but I am
>stuck
>> with this
>> odd problem where 1 game (heroes of the storm) keeps giving me a
>BSOD
>> whenever I try to run it in the VM under Windows 10.
>>
>>  All other games are running fine. If I install Windows 8 in the
>VM
>> the game runs fine.
>>  If I boot the machine into the Windows 10 HDD directly the game
>runs
>> fine.
>> This crash occurs with both Nvidia GTX 770 and AMD Fury X.
>> It only crashes when in VM and Windows 10.
>>
>> The BSOD is some form of exception. Examples that occur
>> SYSTEM_SERVICE_EXCEPTION
>> KMODE_EXCEPTION_NOT_HANDLED
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M
>> The dump files seem to suggest a windows8 driver issue,
>> but I can't pinpoint any faulty driver.
>>
>> I am running netrunner (manjaro) kernel 4.4.9, qemu 2.5.1.
>>
>> My config is:
>> http://pastebin.com/W6cPyMEB
>>
>> Sample BSOD dumps:
>> http://pastebin.com/bgh2uEhf
>> http://pastebin.com/SLPTVUwn
>> http://pastebin.com/zdjTzKuV
>> http://pastebin.com/8Lt5VfLg
>>
>> Welcome any ideas to fix this problem. Thanks,
>>
>
>
> Do you have the following set in a modprobe.d conf file?
>
> options kvm ignore_msrs=1
>
> Windows BSODs are often the result of calling an unsupported MSR
>and
> not handling the exception.  There's some risk to this option
>because zero
> isn't guaranteed to be a valid return for an unknown MSR, but it
>seems to
> solve a lot of problems.  YMMV.
>

 ___
 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
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


[vfio-users] Microphones Sounds Robotic

2016-05-09 Thread Brett Peckinpaugh
Recently had the chance to test video conferencing on my virtual windows.
Running Arch 4.5.1 VFIO, passing through a PCIE USB card as well as video
card.

Ran into the issue video, and incoming audio are great.  But everyone hears
me as metallic or robotic.  I tried both the mic from the Logitech C920 and
a USB headset from Plantronics.  Both were the same.

Are there some settings I should tweak to make this work properly?
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] IOMMU group question - different pcie slots gives different configuration

2016-05-09 Thread Brett Peckinpaugh
Alex,

I am running the Arch VFIO kernel from aur and the ACS patch is working for my 
Skylake system.  Will I not need the ACS patch with 4.7 or will I get a 
performance increase? 

On May 9, 2016 9:25:09 AM PDT, Alex Williamson  
wrote:
>On Mon, May 9, 2016 at 10:06 AM, Jonas Camillus Jeppesen
>
>wrote:
>
>> My IOMMU grouping of devices change depending on which pci-e socket I
>> insert my R9 290 GPU into. For the sake of purchasing a new system I
>wanted
>> to discuss the different groupings so I can better choose my new
>hardware.
>>
>> Here are the IOMMU group which contain my GPU with the GPU inserted
>into
>> the three different PCIE slots I have (for all groups in the
>different
>> configs see attachments).
>>
>> #A: GPU in PCIE1
>> IOMMU group 1
>> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th
>Gen
>> Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>Inc.
>> [AMD/ATI] Hawaii PRO [Radeon R9 290] [1002:67b1]
>> 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc.
>[AMD/ATI]
>> Hawaii HDMI Audio [1002:aac8]
>>
>> #B:  GPU in PCIE3
>> IOMMU group 1
>> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th
>Gen
>> Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
>> 00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th
>Gen
>> Core Processor PCI Express x8 Controller [8086:0c05] (rev 06)
>> 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>Inc.
>> [AMD/ATI] Hawaii PRO [Radeon R9 290] [1002:67b1]
>> 02:00.1 Audio device [0403]: Advanced Micro Devices, Inc.
>[AMD/ATI]
>> Hawaii HDMI Audio [1002:aac8]
>>
>> #C:  GPU in PCIE4
>> IOMMU group 14
>> 04:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>Inc.
>> [AMD/ATI] Hawaii PRO [Radeon R9 290] [1002:67b1]
>> 04:00.1 Audio device [0403]: Advanced Micro Devices, Inc.
>[AMD/ATI]
>> Hawaii HDMI Audio [1002:aac8]
>>
>> I have had success with Arch linux and stock kernel 4.4.1 with config
>#C
>> (GPU in PCIE4), but not the others. Is that to be expected without
>patching
>> the kernel  (i.e. the GPU needs to be in a group all by itself)?
>>
>> Can these groups be figured out without plugging the GPU into the
>> different slots and looking at /sys/kernel/iommu_groups/; deduced
>from the
>> chip set specification, inspecting /sys/ in more clever way, or
>similar? If
>> yes, then it would be great to collect a list of hardware and its
>> groupings. That way it would be easier to decide which motherboard
>and cpu
>> to get for different setups.
>>
>
>It's very simple, unless you choose a Xeon E5+ or a High End Desktop
>Processor, then all of the processor based root ports will be grouped
>together.  The difference between #A and #B in your example is simply
>that
>the BIOS disables the 00:01.1 root port if there's nothing installed in
>the
>slot (it can't disable 00:01.0 in configuration #B because function #0
>must
>be present in order to discover function #1).  In example #C you've
>installed the card in a PCH-based root port for which we have quirks in
>the
>kernel to enable isolation.  We have quirks for most Intel chipsets to
>enable this:
>
>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c#n3877
>
>Linux v4.7 should have quirks for Skylake PCH root ports:
>
>https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/pci/quirks.c?id=1bf2bf229b64540f91ac6fa3af37c81249037a0b
>
>Often the more high-end motherboard manufacturers will have block
>diagrams
>of the system layout so you can see which slots are hosted by which
>device.  IIRC supermicro typically does this, not that I'm endorsing
>their
>products.
>
>All of the above configurations will work, #A and #B simply add
>restrictions that you can't use the additional CPU-based slots for
>anything
>else without (not recommended) using the ACS override patch.  For an
>assigned GPU, it does not matter that the root port itself is included
>in
>the group.  If however you were trying to make use of a multi-port NIC,
>with each port assigned to a separate VM, or an SR-IOV device with
>multiple
>virtual functions, installing it in such a slot would be a very bad
>choice
>for those applications.
>
>
>
>
>___
>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] Sound Options for Guest

2016-05-02 Thread Brett Peckinpaugh
I was wondering what are some options for audio?  Currently using the
monitor, but want to use my speakers for better quality.  The options I can
think of are a PCIE soundcard or USB sound device.

Are there any better options?  Would a USB which is cheaper and not needed
in the case blocking fans work well? Currently I am passing through a PCIE
USB 3.0 card which is where I would connect it.
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] VFIO and ARCH ?

2016-05-01 Thread Brett Peckinpaugh
If it helps I am running Antergos and so far going well. I am in stability and 
optimization stage now. 

On May 1, 2016 12:29:09 PM PDT, Daniel Browne  wrote:
>The first time I started playing with VFIO I was using Manjaro. It
>worked
>well, the arch instructions should work for you.
>
>On Sun, May 1, 2016 at 11:49 AM, thibaut noah 
>wrote:
>
>> There a some arch users on the mailing list, do you have a specific
>> question?
>> I assume manjaro runs arch default repo so there shouldn't be any
>> difference
>>
>> 2016-05-01 17:24 GMT+02:00 :
>>
>>> Does anyone tried Manjaro with VFIO ?
>>>
>>>
>>>
>>> Lg
>>>
>>> webadmin
>>>
>>> ___
>>> 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
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


Re: [vfio-users] VFIO not claiming device

2016-04-22 Thread Brett Peckinpaugh
Might be working now, oddly I thought I used the format modules-load= 
and no luck but it is at the moment.  Only issue, when I rebooted I had 
to reset my dual monitor config.  Any issues with kernel modules listing 
other drivers, or is the only thing that matters the kernel driver in use?


   02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF110
   [GeForce GTX 560 Ti 448 Cores] [10de:1087] (rev a1)
Subsystem: NVIDIA Corporation Device [10de:]
Kernel driver in use: vfio-pci
Kernel modules: nouveau, nvidia_drm, nvidia

kernel command line

   modules-load=vfio-pci quiet intel_iommu=on pcie_acs_override=downstream



On 04/22/2016 03:27 PM, thibaut noah wrote:
For further explanation see this : 
https://www.freedesktop.org/software/systemd/man/systemd-modules-load.service.html#rd.modules-load=


2016-04-23 0:24 GMT+02:00 thibaut noah <mailto:thibaut.n...@gmail.com>>:


My grub line :
"GRUB_CMDLINE_LINUX_DEFAULT="rd.modules-load=vfio-pci quiet
intel_iommu=on,igfx_off pcie_acs_override=downstream" (igfx_off is
because i cannot boot otherwise, got some graphic glitch at boot,
if you don't have it feel, free to remove itr"

Don't forget to update grub afterwards. It is weird though,
rd.modules-load is on others tutorials but not on arch wiki.
I believe that was the issue i had when first trying to get vfio
to grab the device on antergos first time i wanted to do this.

2016-04-23 0:10 GMT+02:00 Alex Williamson
mailto:alex.l.william...@gmail.com>>:

    On Fri, Apr 22, 2016 at 4:06 PM, Brett Peckinpaugh
mailto:erylfl...@gmail.com>> wrote:

To start I am now running Arch with the VFIO kernel, I did
not compile with the i915, my machine failed to boot with
that last time.  Currently I can't seem to get VFIO to
claim the devices I want to pass-through.  You can see
kernel driver is still nvidia.  I added my configs below. 
I even tried a script.  Every time I modify

mkinitcpio.conf I regenerate my intramfd with mkinitcpio
-p linux-vfio

What am I missing?

lspci -nnk -d 10de:1087

02:00.0 VGA compatible controller [0300]: NVIDIA
Corporation GF110 [GeForce GTX 560 Ti 448 Cores]
[10de:1087] (rev a1)
Subsystem: NVIDIA Corporation Device [10de:]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia



/etc/mkinitcpio.conf

MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"

kernel boot options.

intel_iommu=on pcie_acs_override=downstream
rd.driver.pre=vfio-pci


You're applying Fedora instructions to Arch, rd.driver.pre
apparently doesn't do anything on Arch.  Look in the archive
for the past couple weeks, I believe there are some working
instructions there.

___
vfio-users mailing list
vfio-users@redhat.com <mailto: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] VFIO not claiming device

2016-04-22 Thread Brett Peckinpaugh
To start I am now running Arch with the VFIO kernel, I did not compile 
with the i915, my machine failed to boot with that last time.  Currently 
I can't seem to get VFIO to claim the devices I want to pass-through.  
You can see kernel driver is still nvidia.  I added my configs below.  I 
even tried a script.  Every time I modify mkinitcpio.conf I regenerate 
my intramfd with mkinitcpio -p linux-vfio


What am I missing?

lspci -nnk -d 10de:1087

   02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF110
   [GeForce GTX 560 Ti 448 Cores] [10de:1087] (rev a1)
Subsystem: NVIDIA Corporation Device [10de:]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia



/etc/mkinitcpio.conf

   MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"

kernel boot options.

   intel_iommu=on pcie_acs_override=downstream rd.driver.pre=vfio-pci

/etc/modprobe.d/VFIO.conf

   options vfio-pci ids=10de:1087,10de:0e09

modinfo vfio-pci

   filename:
   /lib/modules/4.5.1-1-vfio/kernel/drivers/vfio/pci/vfio-pci.ko.gz
   description:VFIO PCI - User Level meta-driver
   author: Alex Williamson 
   license:GPL v2
   version:0.2
   srcversion: C2A1332D492B2BE5378D1E1
   depends:vfio,irqbypass,vfio_virqfd
   intree: Y
   vermagic:   4.5.1-1-vfio SMP preempt mod_unload modversions
   parm:   ids:Initial PCI IDs to add to the vfio driver,
   format is
   "vendor:device[:subvendor[:subdevice[:class[:class_mask" and
   multiple comma separated entries can be specified (string)
   parm:   nointxmask:Disable support for PCI 2.3 style INTx
   masking.  If this resolves problems for specific devices, report
   lspci -vvvxxx to linux-...@vger.kernel.org so the device can be
   fixed automatically via the broken_intx_masking flag. (bool)
   parm:   disable_vga:Disable VGA resource access through
   vfio-pci (bool)
   parm:   disable_idle_d3:Disable using the PCI D3 low power
   state for idle, unused devices (bool)

dmesg|grep -e DMAR -e IOMMU

   [0.00] Warning: PCIe ACS overrides enabled; This may allow
   non-IOMMU protected peer-to-peer DMA
   [0.00] ACPI: DMAR 0x87F4D9F8 70 (v01 INTEL
   SKL  0001 INTL 0001)
   [0.00] DMAR: IOMMU enabled
   [0.033182] DMAR: Host address width 39
   [0.033183] DMAR: DRHD base: 0x00fed9 flags: 0x1
   [0.033187] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap
   d2008c40660462 ecap f050da
   [0.033188] DMAR: RMRR base: 0x0087906000 end: 0x0087925fff
   [0.033189] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed9 IOMMU 0
   [0.033190] DMAR-IR: HPET id 0 under DRHD base 0xfed9
   [0.033191] DMAR-IR: x2apic is disabled because BIOS sets x2apic
   opt out bit.
   [0.033191] DMAR-IR: Use 'intremap=no_x2apic_optout' to override
   the BIOS setting.
   [0.034540] DMAR-IR: Enabled IRQ remapping in xapic mode
   [0.352192] DMAR: No ATSR found
   [0.352245] DMAR: dmar0: Using Queued invalidation
   [0.352251] DMAR: Setting RMRR:
   [0.352258] DMAR: Setting identity map for device :00:14.0
   [0x87906000 - 0x87925fff]
   [0.352262] DMAR: Prepare 0-16MiB unity mapping for LPC
   [0.352266] DMAR: Setting identity map for device :00:1f.0
   [0x0 - 0xff]
   [0.352270] DMAR: Intel(R) Virtualization Technology for Directed I/O


Incase this helps, here are my IOMMU groupings

   IOMMU group 0
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host
   Bridge/DRAM Registers [8086:191f] (rev 07)
   IOMMU group 1
00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe
   Controller (x16) [8086:1901] (rev 07)
   IOMMU group 2
00:01.1 PCI bridge [0604]: Intel Corporation Skylake PCIe
   Controller (x8) [8086:1905] (rev 07)
   IOMMU group 3
00:14.0 USB controller [0c03]: Intel Corporation Sunrise
   Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31)
00:14.2 Signal processing controller [1180]: Intel
   Corporation Sunrise Point-H Thermal subsystem [8086:a131] (rev 31)
   IOMMU group 4
00:16.0 Communication controller [0780]: Intel Corporation
   Sunrise Point-H CSME HECI #1 [8086:a13a] (rev 31)
   IOMMU group 5
00:17.0 SATA controller [0106]: Intel Corporation Sunrise
   Point-H SATA controller [AHCI mode] [8086:a102] (rev 31)
   IOMMU group 6
00:1b.0 PCI bridge [0604]: Intel Corporation Sunrise
   Point-H PCI Root Port #17 [8086:a167] (rev f1)
   IOMMU group 7
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise
   Point-H PCI Express Root Port #1 [8086:a110] (rev f1)
   IOMMU group 8
00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise
   Point-H PCI Express Root Port #5 [8086:a114] (rev f1)
   IOMMU group 9
00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise
   Point-H PCI Express Root Port #6 

Re: [vfio-users] Fedora 23 ACS Patch

2016-04-18 Thread Brett Peckinpaugh
Thanks for replying.

To stress, I am new to this process.  I have ran Linux as my primary
desktop for about 2 years.

How would I get a copy of an ACS patch for my kernel? Or failing that, what
should I do to create one?  I am not a C programmer, so would be limited in
my ability to write one.

On Mon, Apr 18, 2016 at 2:22 AM, Zycorax Tokoroa 
wrote:

>
> >
> >
> > 2016-04-18 3:21 GMT+02:00 Blank Field  > <mailto:ihatethisfi...@gmail.com>>:
> >
> > Doesn't patch support syntax like patch -p1 filename.patch?
> > Does vanilla linux really can do stuff like make rpm? If so, since
> when?
> >
> > I think that is the syntax i use back then.
> > What do you mean by vanilla linux? You're talking about the kernel or
> > the distrib gnu/linux in general?
> > Rpm is supported by the majority of the distros if i remember correctly.
> He likely refers to a method to build a rpm directly and solely trough
> the kernel's makefile. 'make rpm-pkg' is possible since as far as I can
> remember, along with 'make deb-pkg'
>
> > On Apr 18, 2016 4:18 AM, "Brett Peckinpaugh"  > <mailto:erylfl...@gmail.com>> wrote:
> >
> > Thanks for any help in advance.
> >
> > I am trying to create a patched kernel for Fedora 23.  I have
> > downloaded from the Kernel archive the 4.5.1 source files.  I
> > can compile to rpm, install and run from this source. When I
> > attempt to patch I fail at different steps based on which ACS
> > patch I try.
> >
> > I compile by the following steps.
> > make menuconfig
> > make rpm
> >
> > To patch:
> > make menuconfig
> > cat pathtofile/acs_patch.diff | patch -p1
> > make rpm
> >
> > Depending on the ACS patch, sometimes it fails at the cat step,
> > sometimes it fails at the make rpm step.
> 'patch' has an '-i' argument to take a file as input - not that cat'ing
> is wrong, both methods work.
> You should look at what exact errors you get to have proper help, errors
> in patching usually means you are using incompatible versions of the
> patch and the kernel together, where the code has changed enough to
> confuse patch. As it has been told, look for a patch that's appropriate
> to your kernel version. Errors during the building of the kernel need
> more detail to be understood
>
>  Zycorax Tokoroa
>
> ___
> 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] Fedora 23 ACS Patch

2016-04-17 Thread Brett Peckinpaugh

Thanks for any help in advance.

I am trying to create a patched kernel for Fedora 23.  I have downloaded 
from the Kernel archive the 4.5.1 source files.  I can compile to rpm, 
install and run from this source. When I attempt to patch I fail at 
different steps based on which ACS patch I try.


I compile by the following steps.
make menuconfig
make rpm

To patch:
make menuconfig
cat pathtofile/acs_patch.diff | patch -p1
make rpm

Depending on the ACS patch, sometimes it fails at the cat step, 
sometimes it fails at the make rpm step.


First, is what I am doing on the right track? If not is there a guide to 
do this? If I am on the right track, which ACS patch should I use, and 
if I run into issues what should I do or look for?  I can't seem to 
locate logs for when it fails to help me trouble shoot what is wrong.


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