Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Simon Gaiser 
Marek Marczykowski-Górecki:
[...]
> I don't see anything else related to this device. So until Simon gets
> permissive mode sorted out, it look like you have to use that usb
> ethernet.

FYI: https://github.com/QubesOS/qubes-core-admin/pull/184

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec1f044a-7910-1966-0e2a-d3b9b20503d3%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread mossy-nw 
Marek Marczykowski-Górecki:
> On Thu, Jan 18, 2018 at 07:21:14PM +, mossy-nw wrote:
>> OK thanks, Marek.  I'll try to help get that backup bug reproduced
>> then... should I file a permissive mode bug report based on this
>> discussion, or do you feel like all of the relevant folks are looped in
>> on this thread already?
> Even if relevant people are aware of it, a github issue would be useful
> for tracking purpose (for example to easily check what package version
> contains a fix).
>
Great -- please see issue #3476 
 -- I linked this thread 
there and pasted what I see as most
relevant comments from you all here, feel free to crticize/clarify.

thx,

-m0ssy

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/61cea59a-0a30-b63b-5c66-f0a170bfc35c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
On Thu, Jan 18, 2018 at 07:21:14PM +, mossy-nw wrote:
> OK thanks, Marek.  I'll try to help get that backup bug reproduced
> then... should I file a permissive mode bug report based on this
> discussion, or do you feel like all of the relevant folks are looped in
> on this thread already?

Even if relevant people are aware of it, a github issue would be useful
for tracking purpose (for example to easily check what package version
contains a fix).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118192838.GD2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 04:50:02PM +, mossy-nw wrote:
> 
> 
> Marek Marczykowski-Górecki:
> > On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
> >> Marek Marczykowski-Górecki:
> >>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
>  Dear Qubes community,
> >>>
>  Has anyone using Qubes R4.0 been able to resolve any issues (e.g. with
>  wifi) by setting PCI permissive mode? (as described in:)
> >>>
>  https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues
> >>>
>  I successfully used this in Qubes R3.2 to get wifi working for dell xps
>  13 9350 (bcm4350) but am having no luck using this method in R4.0_rc3.
> >>>
>  This situation seems identical (driver errors that persist but
>  nonetheless wifi works using permissive mode) resolved by in a previous
>  (R3.2) qubes-users thread by miaoski --
>  https://groups.google.com/forum/#!msg/qubes-users/m4GzpfOVBiQ/bf5XCEc-DQAJ
> >>>
>  I'm hesitant to give up and go back to R3.2 on this machine, so I don't
>  have access to the R3.2 dom0 dmesg output for PCI spermissive mode, but
>  I recall before setting permissive mode dmesg suggested doing so.  This
>  is not the case in R4.0_rc3 however.
> >>>
>  Some dmesg output, if this gives anyone any ideas:
> >>>
>  [dom0 ~] lspci | grep -i network
>  3a:00.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
>  Network Adapter (rev 08)
> >>>
>  Before setting permissive mode:
>  [dom0 ~]$ sudo dmesg | grep
>  [7.222306] pci :3a:00.0: [14e4:43a3] type 00 class 0x028000
>  [7.222348] pci :3a:00.0: reg 0x10: [mem 0xdc40-0xdc407fff 
>  64bit]
>  [7.222379] pci :3a:00.0: reg 0x18: [mem 0xdc00-0xdc3f 
>  64bit]
>  [7.222618] pci :3a:00.0: supports D1 D2
>  [7.222619] pci :3a:00.0: PME# supported from D0 D1 D2 D3hot 
>  D3cold
>  [7.222766] pci :3a:00.0: System wakeup disabled by ACPI
>  [8.053279] pciback :3a:00.0: seizing device
>  [   68.211970] xen_pciback: vpci: :3a:00.0: assign to virtual slot 0
>  [   68.212362] pciback :3a:00.0: registering for 4
>  [   68.217475] pciback :3a:00.0: enabling device ( -> 0002)
> >>>
> >>> Did you get anything after that message? Permissive mode helps mostly
> >>> with cases reported in dom0 dmesg with message like this:
> >>>
> >>> pciback :03:00.0: Driver tried to write to a read-only
> >>> configuration space field at offset 0x110, size 4. This may be 
> >>> harmless,
> >>> but if you have problems with your device:
> >>> 1) see permissive attribute in sysfs
> >>> 2) report problems to the xen-devel mailing list along with details of
> >>> your device obtained from lspci.
> >>>
> >>> Interesting would be to see messages in sys-net about that device
> >>> driver.
> >>> You may also try updated kernel for VM, there is
> >>> kernel-qubes-vm-4.14.13-1 package in current-testing repository:
> >>> https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories
> >>>
> >>>
> > 
> >> Thanks, Marek--I will try the updated kernel (though sys-net has the
> >> appropriate driver binary file, and this was working under R3.2 for many
> >> months i.e. with older kernels).  Here are relevant messages from sys-net:
> > 
> >> [user@sys-net ~]$ lspci -k
> >> 00:05.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
> >> Network Adapter (rev 08)
> >>Subsystem: Dell Device 0023
> >>Kernel modules: brcmfmac
> > 
> >> [user@sys-net ~]$ sudo dmesg | grep brcmfmac
> >> [1.703756] usbcore: registered new interface driver brcmfmac
> >> [1.970170] brcmfmac: brcmf_chip_recognition: SB chip is not supported
> >> [1.970185] brcmfmac: brcmf_pcie_probe: failed 14e4:43a3
> > 
> > Do you see other relevant kernel messages about that time (not necessary
> > containing brcmfmac)?
> > 
> > I assume this is after enabling permissive mode, right?
> > Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> > stubdomain perform some additional filtering?
> > 
> 
> Sounds like you all are way ahead of me on this thread now (great!)--but
> yes, this is after permissive mode enabled.  I want to add upon first
> booting single clicking the dock icon for sys-net reads "device not
> managed" but after sleeping and waking there is no longer any entry at all.
> 
> I don't feel confident to judge for sure what's relevant, but here are
> some things that might be.
> 
> [1.979068] FUJITSU Extended Socket Network Device Driver - version
> 1.1 - Copyright (c) 2015 FUJITSU LIMITED
> [1.980511] piix4_smbus :00:01.3: SMBus Host Controller not enabled!
> [1.981868] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [1.982959] ehci-pci: EHCI PCI platform driver
> [1.998059] uhci_hcd: USB Universal Host Controller

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 04:44:54PM -, awokd wrote:
> On Thu, January 18, 2018 4:16 pm, "Marek Marczykowski-Górecki" wrote:
> 
> 
> > Not exactly...
> >
> >
> > 1. qvm-start sends a request to qubesd, using Admin API
> > 2. qubesd starts required netvm (recursively), if needed
> > 3. qubesd request qmemman to allocate needed memory for new VM
> > (according to VM's 'memory' property)
> > 4. qubesd calls into appropriate storage pool driver to prepare for VM
> > startup (create copy-on-write layers etc)
> > 5. qubesd gathers needed VM
> > properties etc and builds libvirt VM configuration (XML format, can be
> > seen using `virsh dumpxml`)
> > 6. qubesd calls into libvirt to start the VM
> > (but in paused mode)
> > 7. libvirt setup the VM using libxl, this include starting stubdomain if
> > needed
> > 8. qubesd start auxiliary processes, including:
> > - qrexec-daemon
> > - qubesdb-daemon (and fill its content)
> > 9. libvirt unpause the VM
> > 10. qvm-start-gui process (running separately from qubesd, as part of
> > dom0 user GUI session) starts gui daemon
> 
> Thank you, sir. No wonder I was having trouble following the control flow.

For the record, most of the above is in "start" method:
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-vm/qubesvm.html#qubes.vm.qubesvm.QubesVM.start
(there is "source" link at the right side)

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgz6YACgkQ24/THMrX
1ywAeQgAiNAlBk75F0ezCZHOgPed8Rd3qc8/pP7zRTYeWUOUCiDxSky+FSompw/k
1JS/ROgisCcma+16W2EPmGPDkxUjkJJcL+OJj/jZGZolxnFKoY3Atbu42qEckAlG
br11XSXtdVuV3IPR3nHQhdCn5BltwAgw0QE80ziekvb+9Fh+bIdzH8S9qyk/sVbf
WML6a/Gn81Nh4dWyktLL5V0onZmpn0wbRWhyXFGi9HUOJUgnl7WImLgjGD+3YBch
iCVwULNxewDA0Nkfq2UARnsODjP23M/9CNplUAq1oPumtQYIcsc4wGGDcZH/xXo4
aAhtZskNopUgBeCvBWGr7sywGSs1LA==
=G7vM
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118164734.GB2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread 'awokd' via qubes-users 
On Thu, January 18, 2018 4:16 pm, "Marek Marczykowski-Górecki" wrote:


> Not exactly...
>
>
> 1. qvm-start sends a request to qubesd, using Admin API
> 2. qubesd starts required netvm (recursively), if needed
> 3. qubesd request qmemman to allocate needed memory for new VM
> (according to VM's 'memory' property)
> 4. qubesd calls into appropriate storage pool driver to prepare for VM
> startup (create copy-on-write layers etc)
> 5. qubesd gathers needed VM
> properties etc and builds libvirt VM configuration (XML format, can be
> seen using `virsh dumpxml`)
> 6. qubesd calls into libvirt to start the VM
> (but in paused mode)
> 7. libvirt setup the VM using libxl, this include starting stubdomain if
> needed
> 8. qubesd start auxiliary processes, including:
> - qrexec-daemon
> - qubesdb-daemon (and fill its content)
> 9. libvirt unpause the VM
> 10. qvm-start-gui process (running separately from qubesd, as part of
> dom0 user GUI session) starts gui daemon

Thank you, sir. No wonder I was having trouble following the control flow.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f074b72ac28826e4f0ad8ca2c069aa1f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 03:42:43PM -, awokd wrote:
> On Thu, January 18, 2018 3:06 pm, Simon Gaiser wrote:
> > awokd:
> >
> >> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> >>
> >>
> >>>
> >>> According to logs provided by mossy-nw permissive mode is correctly
> >>> enabled in xen-pciback in dom0 for this device. The question here is
> >>> what else is needed for HVM (using qemu in stubdomain).
> >>
> >> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> >> device always getting added with permissive=false. Maybe that's what you
> >>  are saying, qemu isn't passing the value along?
> >
> > Yes that's the problem. The guide sets permissive mode in pciback and
> > not via libxl. So the stubdomain never learns about it. Will take a look
> > today.
> 
> Was trying to beat you to it but got lost in all the layers! Does anyone
> know of a flowchart somewhere of what happens when you enter "qvm-start
> vm" in 4.0? I gathered:
> 
> qvm-start
> qubesadmin -> QubesDB
> salt
> libxl calls Xen code-> stubdomain with qemu
> qemu uses libxl calling Xen code to start vm

Not exactly...

1. qvm-start sends a request to qubesd, using Admin API
2. qubesd starts required netvm (recursively), if needed
3. qubesd request qmemman to allocate needed memory for new VM
   (according to VM's 'memory' property)
4. qubesd calls into appropriate storage pool driver to prepare for VM
   startup (create copy-on-write layers etc)
5. qubesd gathers needed VM properties etc and builds libvirt VM
   configuration (XML format, can be seen using `virsh dumpxml`)
6. qubesd calls into libvirt to start the VM (but in paused mode)
7. libvirt setup the VM using libxl, this include starting stubdomain if
   needed
8. qubesd start auxiliary processes, including:
   - qrexec-daemon
   - qubesdb-daemon (and fill its content)
9. libvirt unpause the VM
10. qvm-start-gui process (running separately from qubesd, as part of
   dom0 user GUI session) starts gui daemon

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgyFIACgkQ24/THMrX
1yyEEwf+K1bF8s/zig+WmCFKfVrF+G9kFTC0l4FWejwbNBd3pslgz2ED6fu9S3S/
j/5OpEj40DF404FT7i1c9R6J0+hWvrIcuizZUJ3sY0Ip1na12sivxInhesLsOzMk
Qn/tz5Tob1HuowJEZG5CwBo/WkVZvkDmzn9hBFDg3hOoRPBg/kdFNJduQM+/zYGq
0SPfG9dUDKlDsi41hV4/ciZJiMRwOJIhaPj8nioyBUxrZSrhy8V1Z4/q8sCXxPu3
h8akFQxqyb27D7FjCgZALiISR0Er5pm3vsVhaNamEMV98A16BbmjHJAAbtTFGMUL
aFqppX3FK0v/g+RogLvyoBPxHYKkkA==
=eXzz
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118161618.GZ2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Simon Gaiser 
Marek Marczykowski-Górecki:> On Thu, Jan 18, 2018 at 03:06:00PM +, Simon 
Gaiser wrote:
>> awokd:
>>> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
>>>

 According to logs provided by mossy-nw permissive mode is correctly
 enabled in xen-pciback in dom0 for this device. The question here is what
 else is needed for HVM (using qemu in stubdomain).
>>>
>>> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
>>> device always getting added with permissive=false. Maybe that's what you
>>> are saying, qemu isn't passing the value along?
> 
>> Yes that's the problem. The guide sets permissive mode in pciback and
>> not via libxl. So the stubdomain never learns about it. Will take a look
>> today.
> 
> If that's the case, it looks we need another option for PCI device, like
> this:
> 
> qvm-pci attach sys-net dom0:xx_yy.zz -o permissive=True

Yes, exactly. And if I didn't miss something we first need to teach
libvirt about the permissive option.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a4a1f49c-4568-405c-ba05-6755da75abf2%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 03:06:00PM +, Simon Gaiser wrote:
> awokd:
> > On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> > 
> >>
> >> According to logs provided by mossy-nw permissive mode is correctly
> >> enabled in xen-pciback in dom0 for this device. The question here is what
> >> else is needed for HVM (using qemu in stubdomain).
> > 
> > My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> > device always getting added with permissive=false. Maybe that's what you
> > are saying, qemu isn't passing the value along?
> 
> Yes that's the problem. The guide sets permissive mode in pciback and
> not via libxl. So the stubdomain never learns about it. Will take a look
> today.

If that's the case, it looks we need another option for PCI device, like
this:

qvm-pci attach sys-net dom0:xx_yy.zz -o permissive=True

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgvHYACgkQ24/THMrX
1ywg3Qf/c/gV4AycMBti0O65ZP8s2tROvOBH8JkAZlNkO988GeQrPc4/O6fW4wR8
sfLLPzfylFTqcYm/gX8/UmNY01b/v167zUf2SLdqvCEqt08hykJ+fVII0tLuPz6c
fxvCyjrF3Q4zRdUaT3irL20TYoVPYZrbJwvtVk0gtHdmSMcmQIVQ4gU3isf3hYu9
RdRJ58Qulom9fmAlTu1LeQWdnzFLFW7ryIMtM7xaYC1RawLlEuxeIUjOCHxZP0Uw
zfexZkFyHHFTpGSE0tJT47jhK8JiHOIj+YEFASeaNu9DTTsGPTZxmnDD0aAh0FvT
OFXRpDPqIh31xQlnoHI7fGokETOTDg==
=tSUs
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118152542.GY2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Simon Gaiser 
awokd:
> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> 
>>
>> According to logs provided by mossy-nw permissive mode is correctly
>> enabled in xen-pciback in dom0 for this device. The question here is what
>> else is needed for HVM (using qemu in stubdomain).
> 
> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> device always getting added with permissive=false. Maybe that's what you
> are saying, qemu isn't passing the value along?

Yes that's the problem. The guide sets permissive mode in pciback and
not via libxl. So the stubdomain never learns about it. Will take a look
today.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b33c3a7f-4857-4507-c8a2-961a0bbdbd8b%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread 'awokd' via qubes-users 
On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:

>
> According to logs provided by mossy-nw permissive mode is correctly
> enabled in xen-pciback in dom0 for this device. The question here is what
> else is needed for HVM (using qemu in stubdomain).

My dom0 log shows that too, but the guest-dm/debug log showed the PCI
device always getting added with permissive=false. Maybe that's what you
are saying, qemu isn't passing the value along?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e4d9337abce534d43e6f046b7f5e9443.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 02:12:26PM -, awokd wrote:
> On Thu, January 18, 2018 1:17 am, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
> >>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
> 
>  Has anyone using Qubes R4.0 been able to resolve any issues (e.g.
>  with wifi) by setting PCI permissive mode? (as described in:)
> >>>
>  https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-iss
>  ues
> 
> > I assume this is after enabling permissive mode, right?
> > Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> > stubdomain perform some additional filtering?
> 
> Per device permissive mode is broken in 4.0. I was trying to figure out
> where exactly while troubleshooting my Atheros card. I found where the
> init script in the stubdomain reads the device values from xenstore, but I
> couldn't find anywhere that actually added per device permissive entries
> to xenstore (whereas I did find where msitranslate and power_mgmt got
> set).
> 
> For my troubleshooting, I set the init script to default to
> permissive=true which results in every device being added as permissive
> but it didn't help my Atheros case anyways.

According to logs provided by mossy-nw permissive mode is correctly
enabled in xen-pciback in dom0 for this device. The question here is
what else is needed for HVM (using qemu in stubdomain).

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgrokACgkQ24/THMrX
1yx8tQf9GA3s9nLdFQjLeQ6SRcsQGUVd/BSUkz/n+ssrcJHOm3xmcbi7bxE5/Pyd
iubkwqZwxCkNOLD1SAVVGEXmcPCh1mLvxCNhms2s16J0YQSBYTYEEgytgc3Maf6N
SZ80cCSnj4wM/OOc3xG7dbjq7cB827OyE4l3wxTzjnCKubRK6BKLMrJp9S/mG0O6
q45Hr1q75kRwZwRg77DAwq7wkVt9CSk8+S9tltlA6Cj0zK6wnw+4Enp21QHCgEim
z78RvpHZEjQefQAxIX9omIR1QsDvWj4uLSdQTisJZUseOU23rSqxtNU1MNisjKNn
88zC1Z4pJP6MX8SmfRlFR6RdkWi3lg==
=Nn3O
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118142617.GW2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-18 Thread 'awokd' via qubes-users 
On Thu, January 18, 2018 1:17 am, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
>>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:

 Has anyone using Qubes R4.0 been able to resolve any issues (e.g.
 with wifi) by setting PCI permissive mode? (as described in:)
>>>
 https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-iss
 ues

> I assume this is after enabling permissive mode, right?
> Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> stubdomain perform some additional filtering?

Per device permissive mode is broken in 4.0. I was trying to figure out
where exactly while troubleshooting my Atheros card. I found where the
init script in the stubdomain reads the device values from xenstore, but I
couldn't find anywhere that actually added per device permissive entries
to xenstore (whereas I did find where msitranslate and power_mgmt got
set).

For my troubleshooting, I set the init script to default to
permissive=true which results in every device being added as permissive
but it didn't help my Atheros case anyways.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/381cd456cabaaaba83b17dfc7ac94fd6.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-17 Thread mossy-nw 
Marek Marczykowski-Górecki:
> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
>> Dear Qubes community,
> 
>> Has anyone using Qubes R4.0 been able to resolve any issues (e.g. with
>> wifi) by setting PCI permissive mode? (as described in:)
> 
>> https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues
> 
>> I successfully used this in Qubes R3.2 to get wifi working for dell xps
>> 13 9350 (bcm4350) but am having no luck using this method in R4.0_rc3.
> 
>> This situation seems identical (driver errors that persist but
>> nonetheless wifi works using permissive mode) resolved by in a previous
>> (R3.2) qubes-users thread by miaoski --
>> https://groups.google.com/forum/#!msg/qubes-users/m4GzpfOVBiQ/bf5XCEc-DQAJ
> 
>> I'm hesitant to give up and go back to R3.2 on this machine, so I don't
>> have access to the R3.2 dom0 dmesg output for PCI spermissive mode, but
>> I recall before setting permissive mode dmesg suggested doing so.  This
>> is not the case in R4.0_rc3 however.
> 
>> Some dmesg output, if this gives anyone any ideas:
> 
>> [dom0 ~] lspci | grep -i network
>> 3a:00.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
>> Network Adapter (rev 08)
> 
>> Before setting permissive mode:
>> [dom0 ~]$ sudo dmesg | grep
>> [7.222306] pci :3a:00.0: [14e4:43a3] type 00 class 0x028000
>> [7.222348] pci :3a:00.0: reg 0x10: [mem 0xdc40-0xdc407fff 64bit]
>> [7.222379] pci :3a:00.0: reg 0x18: [mem 0xdc00-0xdc3f 64bit]
>> [7.222618] pci :3a:00.0: supports D1 D2
>> [7.222619] pci :3a:00.0: PME# supported from D0 D1 D2 D3hot D3cold
>> [7.222766] pci :3a:00.0: System wakeup disabled by ACPI
>> [8.053279] pciback :3a:00.0: seizing device
>> [   68.211970] xen_pciback: vpci: :3a:00.0: assign to virtual slot 0
>> [   68.212362] pciback :3a:00.0: registering for 4
>> [   68.217475] pciback :3a:00.0: enabling device ( -> 0002)
> 
> Did you get anything after that message? Permissive mode helps mostly
> with cases reported in dom0 dmesg with message like this:
> 
> pciback :03:00.0: Driver tried to write to a read-only
> configuration space field at offset 0x110, size 4. This may be harmless,
> but if you have problems with your device:
> 1) see permissive attribute in sysfs
> 2) report problems to the xen-devel mailing list along with details of
> your device obtained from lspci.
> 
> Interesting would be to see messages in sys-net about that device
> driver.
> You may also try updated kernel for VM, there is
> kernel-qubes-vm-4.14.13-1 package in current-testing repository:
> https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories
> 
> 

Thanks, Marek--I will try the updated kernel (though sys-net has the
appropriate driver binary file, and this was working under R3.2 for many
months i.e. with older kernels).  Here are relevant messages from sys-net:

[user@sys-net ~]$ lspci -k
00:05.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
Network Adapter (rev 08)
Subsystem: Dell Device 0023
Kernel modules: brcmfmac

[user@sys-net ~]$ sudo dmesg | grep brcmfmac
[1.703756] usbcore: registered new interface driver brcmfmac
[1.970170] brcmfmac: brcmf_chip_recognition: SB chip is not supported
[1.970185] brcmfmac: brcmf_pcie_probe: failed 14e4:43a3

[user@sys-net ~]$ modinfo brcmfmac | grep -E
'^(description|author|depends):'
description:Broadcom 802.11 wireless LAN fullmac driver.
author: Broadcom Corporation
depends:mmc_core,brcmutil,cfg80211

Trying advice from -
https://www.qubes-os.org/doc/wireless-troubleshooting - I tried
disabling/reenabling brcmfmac and some combinations of those others
(mmc_core,brcmutil,cfg80211; reversing remove/add order), but no luck.

I also tried using as the sys-net template qubes-template-debian-9 with
broadcom-sta-dkms and others (which I recall got this working for
running non-Qubes debian on this laptop), to no avail.

Thanks again,

-m0ssy

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f00b4628-626f-d63c-cb5e-40415e1019ac%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

2018-01-17 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
> Dear Qubes community,
> 
> Has anyone using Qubes R4.0 been able to resolve any issues (e.g. with
> wifi) by setting PCI permissive mode? (as described in:)
> 
> https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues
> 
> I successfully used this in Qubes R3.2 to get wifi working for dell xps
> 13 9350 (bcm4350) but am having no luck using this method in R4.0_rc3.
> 
> This situation seems identical (driver errors that persist but
> nonetheless wifi works using permissive mode) resolved by in a previous
> (R3.2) qubes-users thread by miaoski --
> https://groups.google.com/forum/#!msg/qubes-users/m4GzpfOVBiQ/bf5XCEc-DQAJ
> 
> I'm hesitant to give up and go back to R3.2 on this machine, so I don't
> have access to the R3.2 dom0 dmesg output for PCI spermissive mode, but
> I recall before setting permissive mode dmesg suggested doing so.  This
> is not the case in R4.0_rc3 however.
> 
> Some dmesg output, if this gives anyone any ideas:
> 
> [dom0 ~] lspci | grep -i network
> 3a:00.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
> Network Adapter (rev 08)
> 
> Before setting permissive mode:
> [dom0 ~]$ sudo dmesg | grep
> [7.222306] pci :3a:00.0: [14e4:43a3] type 00 class 0x028000
> [7.222348] pci :3a:00.0: reg 0x10: [mem 0xdc40-0xdc407fff 64bit]
> [7.222379] pci :3a:00.0: reg 0x18: [mem 0xdc00-0xdc3f 64bit]
> [7.222618] pci :3a:00.0: supports D1 D2
> [7.222619] pci :3a:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [7.222766] pci :3a:00.0: System wakeup disabled by ACPI
> [8.053279] pciback :3a:00.0: seizing device
> [   68.211970] xen_pciback: vpci: :3a:00.0: assign to virtual slot 0
> [   68.212362] pciback :3a:00.0: registering for 4
> [   68.217475] pciback :3a:00.0: enabling device ( -> 0002)

Did you get anything after that message? Permissive mode helps mostly
with cases reported in dom0 dmesg with message like this:

pciback :03:00.0: Driver tried to write to a read-only
configuration space field at offset 0x110, size 4. This may be harmless,
but if you have problems with your device:
1) see permissive attribute in sysfs
2) report problems to the xen-devel mailing list along with details of
your device obtained from lspci.

Interesting would be to see messages in sys-net about that device
driver.
You may also try updated kernel for VM, there is
kernel-qubes-vm-4.14.13-1 package in current-testing repository:
https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpf7kIACgkQ24/THMrX
1yzK7Qf/bu/GFioi0K4hWy5L5DgzI08Q1CcIGoupw3gXXMhOxzecyy/Ak+W1xPYs
m1PBk7EAaCLa2Rr9iUCZiP2vXKiMEdKT6NvxDF7GU/c4YlLRiAHcOXtKnPQjy/GT
TH29dN4oXNLzQhgcXxVg7qKvigE3BeDY5a1EYbByW+2gacwRqjPxnDvTjnMx/G4r
h/GhdjOs4qhQYQ04OdbIBxmx4Yec+SWznS6xDCzaO3lA4f6/LiyW9+UiXpNb1o92
4yVTZEdEu086eurndITYnS2lEI7h3r7OP8YySFFKlZlaNMOkqZa+eOyGQLhUw+Jz
jNIEyqwwgJVj+ggKXd9Y9vt6Rki1dA==
=o9wL
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180118004554.GC12450%40mail-itl.
For more options, visit https://groups.google.com/d/optout.