[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Qubes R3.1 rc2 released!
From: Eric Shelton <knockknock () gmail ! com>
Date: 2016-01-19 22:24:13
Message-ID: 1d4e5dd7-5589-4f2a-9d8b-efc9a367c54e () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tuesday, January 19, 2016 at 5:05:14 PM UTC-5, Outback Dingo wrote:
>
>
> On Tue, Jan 19, 2016 at 10:49 PM, Eric Shelton <knock...@gmail.com
> <javascript:>> wrote:
>
> > On Tuesday, January 19, 2016 at 3:52:49 PM UTC-5, Outback Dingo wrote:
> > >
> > >
> > > On Tue, Jan 19, 2016 at 9:49 PM, Marek Marczykowski-Górecki <
> > > marm...@invisiblethingslab.com> wrote:
> > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA256
> > > >
> > > > On Tue, Jan 19, 2016 at 08:44:02PM +0100, Outback Dingo wrote:
> > > > > On Fri, Jan 15, 2016 at 5:03 AM, Eric Shelton <knock...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > On Thursday, January 14, 2016 at 10:43:16 PM UTC-5, Outback Dingo
> > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > On Jan 15, 2016 04:23, "Eric Shelton" <knock...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thursday, January 14, 2016 at 10:08:12 PM UTC-5, Outback
> > > > Dingo wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jan 15, 2016 at 3:48 AM, Eric Shelton <
> > > > knock...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thursday, January 14, 2016 at 5:41:21 PM UTC-5, Outback
> > > > Dingo
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Jan 14, 2016 21:57, "Eric Shelton" <knock...@gmail.com>
> > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thursday, January 14, 2016 at 3:47:08 PM UTC-5, Outback
> > > > Dingo
> > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sorry no the wireless even need a custom modules build to
> > > > work
> > > > > > > under fedora 23. I guess what bothers me is I run fedora 23 on top
> > > > of xen
> > > > > > > 4.5 on the same laptop on another drive and I don't see any issues
> > > > with
> > > > > > > networking like I'm fighting here. I'll try what you suggest
> > > > however I'm
> > > > > > > not feeling lucky. No idea how qubes its self is so different then
> > > > my
> > > > > > > current setup from a device and kernel perspective
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The difference is that on Qubes, PCI passthrough is being
> > > > used to
> > > > > > > hand the device to (and if you have an IOMMU, isolate the device
> > > > within)
> > > > > > > another domain. This is not a minor difference. In a vanilla
> > > > Linux
> > > > > > > install, there is no such passthrough (there are no domains even,
> > > > of
> > > > > > > course). In a standard Xen install, it still is essentially the
> > > > same as
> > > > > > > the vanilla Linux install, as the networking devices are managed
> > > > by dom0,
> > > > > > > and there still is no passthrough. That is why I tossed in that
> > > > third
> > > > > > > option in my previous post - it provides a bit of a sanity check:
> > > > if dom0
> > > > > > > can initialize the device without passthrough, sys-net should have
> > > > (for the
> > > > > > > most part) the same kernel drivers and firmware, and you might
> > > > have more
> > > > > > > confidence that it is simply a PCI passthrough issue.
> > > > > > > > > > > >
> > > > > > > > > > > > There are still a few well-known PCI passthrough solutions
> > > > that
> > > > > > > you have not tried, so no need to abandon hope yet. The odds are
> > > > good that
> > > > > > > the permissive thing will work. If not, there are likely other
> > > > avenues to
> > > > > > > pursue.
> > > > > > > > > > >
> > > > > > > > > > > OK so.... Removed the devices from sys-net and rebooted
> > > > There's no
> > > > > > > ifconfig in dom0 so can't see it that way, also dmesg is not
> > > > showing net or
> > > > > > > r8169 however the module is shown by lsmod as loaded. And sys-net
> > > > boots
> > > > > > > fine without the devices attached. Then added the
> > > > qubes-pre-netvm.service I
> > > > > > > see the device as 0000:02:00.1 and it is showing as permissive on
> > > > > > > rebooted.. I see the systems status look iads the qubes-pre-netvm
> > > > service
> > > > > > > fine but start qubes vm sys-net again hangs for a very long time
> > > > and
> > > > > > > doesn't really initialize.... I also logged into the gui and i show
> > > > > > > 0000:02:00.1 is in permissive.... The sys-net vm state button is
> > > > yelliw and
> > > > > > > remains, even if i kill it and restart it. Sooo
> > > > > > > > > > > Guess it's time for further ideas
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > It turns out the crash is from drivers/mfd/rtl8411.c - not the
> > > > > > > ethernet driver - which is part of the rtsx_pci module. So, try
> > > > to keep
> > > > > > > that driver from loading. Maybe temporarily
> > > > > > > move
> > > > /lib/modules/4.2.8-3.pvops.qubes.x86_64/kernel/drivers/mfd/rtsx_pci.ko
> > > > > > > somewhere to prevent the kernel in sys-net from loading it?
> > > > Another idea
> > > > > > > is to set permissive for the 02:00.0 device (although in practice
> > > > you
> > > > > > > probably don't want it). You might also try 'qvm-prefs -s sys-net
> > > > > > > kernelopts='nopat iommu=soft swiotlb=8192
> > > > rd.driver.blacklist=rtsx_pci',
> > > > > > > although I don't actually know if that will prevent sys-net from
> > > > loading
> > > > > > > the rtsx_pci driver...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ok ill try this also, but does it not bother you that when the
> > > > devices
> > > > > > > are detached from the vm i dont see an eth or p8p0 devices on the
> > > > host
> > > > > > > under XEN ?
> > > > > > > >
> > > > > > > >
> > > > > > > > I am guessing you by "XEN" you are referring to dom0. If so,
> > > > since
> > > > > > > dom0 is not supposed to do networking, it does not really bother
> > > > me -
> > > > > > > seeing the module loaded via lsmod seems promising.
> > > > > > >
> > > > > > > Cannot mv the file, filesystem is read only
> > > > > > >
> > > > > >
> > > > > > Right - I overlooked that. You would have to loopback mount and
> > > > modify
> > > > > > /var/lib/qubes/vm-kernel/4.2.8-?/modules.img I think you want to
> > > > avoid
> > > > > > going that far initially.
> > > > > >
> > > > > >
> > > > > > > And qvm-prefs as you typed it tells me
> > > > > > > ERROR: Wrong property name
> > > > > > >
> > > > > >
> > > > > > Syntax error on my part. Hopefully you figured out that it should
> > > > be
> > > > > > (omiting the first '='):
> > > > > > qvm-prefs -s sys-net kernelopts 'nopat iommu=soft swiotlb=8192
> > > > > > rd.driver.blacklist=rtsx_pci'
> > > > > >
> > > > > >
> > > > > > Finally, another thing you might try is only assigning the '02:00.1'
> > > > > > device to sys-net, and doing
> > > > > > qvm-prefs -s sys-net pci_strictreset False
> > > > > >
> > > > > > To overcome libvirt's objection to splitting them up. This would be
> > > > > > another way to prevent rtsx_pci from possibly messing things up in
> > > > sys-net.
> > > > > >
> > > > > > That's all I have to offer for today. There are various
> > > > combinations of
> > > > > > the ideas I have tossed out that you might try if things don't work
> > > > out.
> > > > > >
> > > > > >
> > > > >
> > > > > So I guess i really need to ask the question, what is it that Qubes is
> > > > > modiying xen wise, and kernel wise which appears to be preventing me
> > > > from
> > > > > using netwoeking under a Qubes install
> > > > > when Fedora 23 on top of XEN itself works perfectly fine.
> > > >
> > > > Eric already explained that:
> > > >
> > >
> > >
> > > ok, more specifically maybe i should ask, where are said patches we
> > > apply to the xen and kernel in qubes located... in the build system
> > >
> >
> > The source for Qubes (and you can build this all from source under
> > Fedora, if you are so inclined) is available via
> > https://github.com/QubesOS/. In particular, what you are asking about
> > can be seen at https://github.com/QubesOS/qubes-vmm-xen and
> > https://github.com/QubesOS/qubes-linux-kernel. Look in all of the
> > patches.* directories there. The file series.conf lists the patches that
> > are applied.
> >
> > That said, none of those patches are responsible for your
> > hardware-related issues. What is different between your experiences on
> > Windows, Linux, or even Xen on Linux, is that none of those situations
> > involve the use of "driver domains" (see
> > http://wiki.xenproject.org/mediawiki/images/1/17/Device_passthrough_xen.pdf
> > for a discussion about them). Your Fedora install with Xen still operates
> > the network adapters in the same way as Fedora without Xen - in dom0
> > without the use of PCI passthrough. However, if you took the time to
> > reconfigure your Xen on Fedora install to create a driver domain for your
> > network adapters (which is possible), you would run into the same issues.
> > In other words, it is not a Qubes problem (nor even a Xen problem) so much
> > as your devices are being run in a slightly different environment, and they
> > don't like it.
> >
> > I do not know how much experience you have had with running Linux on
> > laptops, but these kinds of issues are reasonably common in trying to get
> > hardware that primarily has been developed for and tested on Windows
> > working on open source operating systems. It was much worse years ago,
> > when significant amounts of hardware lacked support or reasonably complete
> > support, and as a result you had to be selective about the laptops you
> > bought. Sometimes you get hardware that has zero support, and sometimes
> > you get the square peg/round hole phenomenon - in that situation, you can
> > either bang on it with a hammer to get it working (there are lots of cases
> > where you can do this, if you want to dig into and modify the code
> > involved), or you can find a round peg instead (in other words, replace the
> > hardware - although this is harder on a laptop than a desktop, wifi cards
> > are usually miniPCIE, and you can easily swap in a new wifi adapter that
> > will work). The open source ethos generally gives you three options: (1)
> > pitch in, identify and make the needed code and/or configuration changes to
> > get your hardware working, and share the changes so others can use the
> > hardware too; (2) wait long enough, and maybe someone else will do it for
> > you; or (3) use different hardware that is known how to work. I suppose
> > there is a fourth item: (4) give up.
> >
> > In this case, it sounds like you have two issues. First, the combined
> > ethernet/card reader RTL8411 device, or the Linux drivers that were written
> > for it, does not appear to like being run through PCI passthrough. This
> > sometimes happens - it quite possible you are the first person ever to have
> > tried running this device via PCI passthrough - it at least is all but
> > certain the driver developer never did. Some Linux device drivers play a
> > bit fast and loose with PCI registers, etc., and when they are run through
> > PCI passthrough, Xen does not give them the degree of access that they
> > expect. If you want to pursue the above "hammer" approach, you can dig
> > into the driver for the RTL8411 ethernet, figure out what accesses are
> > causing problems, and see if you can rewrite the driver to eliminate them.
> > Also, as I noted before, the crashes you saw seem to be related to the card
> > reader side of things - that is something else to dig into. If I were in
> > your shoes, I would give up on trying to get the RTL8411 working, since in
> > practice you want to use wifi on a laptop.
> >
> > Second, it sounds like your wifi adapter is so new that even on Fedora
> > you had to just through hoops to get it to work. Although it is possible
> > to replicate what you did in Fedora on Qubes, you may have to learn quite a
> > bit (mostly about how Qubes packages up drivers and such and provides them
> > to its PV domains) to make it happen. If I were in your shoes, I would buy
> > a new wifi adapter for $25 on ebay and move on (something I have done in
> > the past for unsupported or poorly supported wifi adapters). Another idea
> > that I did not come up with before is that you could assign your USB
> > controller to sys-net, and maybe use a USB-based wifi adapter, if for some
> > reason you like that idea better.
> >
> > It is going to be a LONG time - if ever - before an open source OS such
> > as Linux or Qubes is going to "just work" like Windows. You are running on
> > very new hardware, and that complicates the situation. In the end, you
> > will have to decide if you want to put forth the effort to get the hardware
> > you have to do what you want, change the hardware involved to the extent
> > you can, or change your mind about what you want to do.
> >
> > Eric
> >
>
>
> There we go, exactly what i was looking for.... Ill do some research into
> this, Im quite familiar with linux in kernel development, i think the piece
> i need more research on is the driver layer for pci
> and this "shared" issue im having. Much appreicated for the write up, as
> for changing my hardware, im comfortable with whats installed, its working,
> as for using Qubes, ive used it before and
> installed it on about 7 different systems now. as for my needs,
> specifically qubes provides me virtualization with a net-vm and firewall
> vm... which is my specific purpose for its use.
> It allows my that "extra" layer of security between my data and the
> "outside world". If i could duplicate that alone on XEN, under Fedora 23 i
> would,
>
Just in case this is not clear, you actually could, without too much
difficulty, replicate that aspect of things on Xen. Create a domU that
owns the network adapters (a network domain), create another domU for a
firewall (if desired), and do the necessary Linux networking magic to tie
it all together, but you would have the same problems because it is more of
a hardware-specific issue and PCI passthrough would come back into the
picture.
FYI, there are not all that many people outside of Qubes making use of
driver domains, so don't expect to find too many answers via Google
searches. Expect to have to figure out a lot of it on your own. Probably
a lot of what there is to learn from are efforts in trying to get
passthrough working for GPUs on Xen, KVM, and QEMU. There was a big push
to get that working on QEMU (mostly on KVM) a couple of years ago.
Eric
--
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/1d4e5dd7-5589-4f2a-9d8b-efc9a367c54e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
On Tuesday, January 19, 2016 at 5:05:14 PM UTC-5, Outback Dingo wrote:<blockquote \
class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc \
solid;padding-left: 1ex;"><div dir="ltr"><br><div class="gmail_quote">On Tue, Jan 19, \
2016 at 10:49 PM, Eric Shelton <span dir="ltr"><<a href="javascript:" \
target="_blank" gdf-obfuscated-mailto="xNqn9VRSCAAJ" rel="nofollow" \
onmousedown="this.href='javascript:';return true;" \
onclick="this.href='javascript:';return \
true;">knock...@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tuesday, \
January 19, 2016 at 3:52:49 PM UTC-5, Outback Dingo wrote:<blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><br><div class="gmail_quote"><span>On \
Tue, Jan 19, 2016 at 9:49 PM, Marek Marczykowski-Górecki <span dir="ltr"><<a \
rel="nofollow">marm...@invisiblethingslab.<wbr>com</a>></span> \
wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>-----BEGIN PGP SIGNED \
MESSAGE-----<br>
Hash: SHA256<br>
<br>
</span></span><div><div><span>On Tue, Jan 19, 2016 at 08:44:02PM +0100, Outback Dingo \
wrote:<br></span><div><div> > On Fri, Jan 15, 2016 at 5:03 AM, Eric Shelton <<a \
rel="nofollow">knock...@gmail.com</a>> wrote:<br> ><br>
> > On Thursday, January 14, 2016 at 10:43:16 PM UTC-5, Outback Dingo \
wrote:<br> > >><br>
> >><br>
> >> On Jan 15, 2016 04:23, "Eric Shelton" \
<<a>knock...@gmail.com</a>> wrote:<br> > >> ><br>
> >> > On Thursday, January 14, 2016 at 10:08:12 PM UTC-5, Outback Dingo \
wrote:<br> > >> >><br>
> >> >><br>
> >> >><br>
> >> >> On Fri, Jan 15, 2016 at 3:48 AM, Eric Shelton \
<<a>knock...@gmail.com</a>><br> > >> wrote:<br>
> >> >>><br>
> >> >>> On Thursday, January 14, 2016 at 5:41:21 PM UTC-5, Outback \
Dingo<br> > >> wrote:<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> On Jan 14, 2016 21:57, "Eric Shelton" \
<<a>knock...@gmail.com</a>> wrote:<br> > >> >>>> ><br>
> >> >>>> > On Thursday, January 14, 2016 at 3:47:08 PM \
UTC-5, Outback Dingo<br> > >> wrote:<br>
> >> >>>> >><br>
> >> >>>> >><br>
> >> >>>> >> Sorry no the wireless even need a custom \
modules build to work<br> > >> under fedora 23. I guess what bothers me is I \
run fedora 23 on top of xen<br> > >> 4.5 on the same laptop on another \
drive and I don't see any issues with<br> > >> networking like I'm \
fighting here. I'll try what you suggest however I'm<br> > >> not \
feeling lucky. No idea how qubes its self is so different then my<br> > >> \
current setup from a device and kernel perspective<br> > >> >>>> \
><br> > >> >>>> ><br>
> >> >>>> > The difference is that on Qubes, PCI passthrough \
is being used to<br> > >> hand the device to (and if you have an IOMMU, \
isolate the device within)<br> > >> another domain. This is not a minor \
difference. In a vanilla Linux<br> > >> install, there is no such \
passthrough (there are no domains even, of<br> > >> course). In a standard \
Xen install, it still is essentially the same as<br> > >> the vanilla Linux \
install, as the networking devices are managed by dom0,<br> > >> and there \
still is no passthrough. That is why I tossed in that third<br> > >> \
option in my previous post - it provides a bit of a sanity check: if dom0<br> > \
>> can initialize the device without passthrough, sys-net should have (for \
the<br> > >> most part) the same kernel drivers and firmware, and you might \
have more<br> > >> confidence that it is simply a PCI passthrough issue.<br>
> >> >>>> ><br>
> >> >>>> > There are still a few well-known PCI passthrough \
solutions that<br> > >> you have not tried, so no need to abandon hope yet. \
The odds are good that<br> > >> the permissive thing will work. If not, \
there are likely other avenues to<br> > >> pursue.<br>
> >> >>>><br>
> >> >>>> OK so.... Removed the devices from sys-net and \
rebooted There's no<br> > >> ifconfig in dom0 so can't see it that \
way, also dmesg is not showing net or<br> > >> r8169 however the module is \
shown by lsmod as loaded. And sys-net boots<br> > >> fine without the \
devices attached. Then added the qubes-pre-netvm.service I<br> > >> see the \
device as 0000:02:00.1 and it is showing as permissive on<br> > >> \
rebooted.. I see the systems status look iads the qubes-pre-netvm service<br> > \
>> fine but start qubes vm sys-net again hangs for a very long time and<br> \
> >> doesn't really initialize.... I also logged into the gui and i \
show<br> > >> 0000:02:00.1 is in permissive.... The sys-net vm state button \
is yelliw and<br> > >> remains, even if i kill it and restart it. Sooo<br>
> >> >>>> Guess it's time for further ideas<br>
> >> >>><br>
> >> >>><br>
> >> >>> It turns out the crash is from drivers/mfd/rtl8411.c - not \
the<br> > >> ethernet driver - which is part of the rtsx_pci module. So, \
try to keep<br> > >> that driver from loading. Maybe temporarily<br>
> >> move /lib/modules/4.2.8-3.pvops.<wbr>qubes.x86_64/kernel/drivers/<wbr>mfd/rtsx_pci.ko<br>
> >> somewhere to prevent the kernel in sys-net from loading it? Another \
idea<br> > >> is to set permissive for the 02:00.0 device (although in \
practice you<br> > >> probably don't want it). You might also try \
'qvm-prefs -s sys-net<br> > >> kernelopts='nopat iommu=soft \
swiotlb=8192 rd.driver.blacklist=rtsx_pci',<br> > >> although I \
don't actually know if that will prevent sys-net from loading<br> > >> \
the rtsx_pci driver...<br> > >> >><br>
> >> >><br>
> >> >> ok ill try this also, but does it not bother you that when the \
devices<br> > >> are detached from the vm i dont see an eth or p8p0 devices \
on the host<br> > >> under XEN ?<br>
> >> ><br>
> >> ><br>
> >> > I am guessing you by "XEN" you are referring to dom0. \
If so, since<br> > >> dom0 is not supposed to do networking, it does not \
really bother me -<br> > >> seeing the module loaded via lsmod seems \
promising.<br> > >><br>
> >> Cannot mv the file, filesystem is read only<br>
> >><br>
> ><br>
> > Right - I overlooked that. You would have to loopback mount and \
modify<br> > > /var/lib/qubes/vm-kernel/4.2.<wbr>8-?/modules.img I think you \
want to avoid<br> > > going that far initially.<br>
> ><br>
> ><br>
> >> And qvm-prefs as you typed it tells me<br>
> >> ERROR: Wrong property name<br>
> >><br>
> ><br>
> > Syntax error on my part. Hopefully you figured out that it should be<br>
> > (omiting the first '='):<br>
> > qvm-prefs -s sys-net kernelopts 'nopat iommu=soft swiotlb=8192<br>
> > rd.driver.blacklist=rtsx_pci'<br>
> ><br>
> ><br>
> > Finally, another thing you might try is only assigning the \
'02:00.1'<br> > > device to sys-net, and doing<br>
> > qvm-prefs -s sys-net pci_strictreset False<br>
> ><br>
> > To overcome libvirt's objection to splitting them up. This would \
be<br> > > another way to prevent rtsx_pci from possibly messing things up in \
sys-net.<br> > ><br>
> > That's all I have to offer for today. There are various combinations \
of<br> > > the ideas I have tossed out that you might try if things don't \
work out.<br> > ><br>
> ><br>
><br>
> So I guess i really need to ask the question, what is it that Qubes is<br>
> modiying xen wise, and kernel wise which appears to be preventing me from<br>
> using netwoeking under a Qubes install<br>
> when Fedora 23 on top of XEN itself works perfectly fine.<br>
<br>
</div></div></div></div>Eric already explained \
that:<br></blockquote><div><div><div><br></div><div><br></div><div>ok, more \
specifically maybe i should ask, where are said patches we apply to the xen and \
kernel in qubes located... in the build \
system</div></div></div></div></div></div></blockquote><div><br></div><div>The source \
for Qubes (and you can build this all from source under Fedora, if you are so \
inclined) is available via <a href="https://github.com/QubesOS/" target="_blank" \
rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F% \
2Fgithub.com%2FQubesOS%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGog9Tja80BfwbBMSWh1MztVYPLAg';return \
true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com \
%2FQubesOS%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGog9Tja80BfwbBMSWh1MztVYPLAg';return \
true;">https://github.com/<wbr>QubesOS/</a>. In particular, what you are asking \
about can be seen at <a href="https://github.com/QubesOS/qubes-vmm-xen" \
target="_blank" rel="nofollow" \
onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F \
QubesOS%2Fqubes-vmm-xen\46sa\75D\46sntz\0751\46usg\75AFQjCNEhNwW1aqcHdi74FOsh2wLLwslxig';return \
true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com \
%2FQubesOS%2Fqubes-vmm-xen\46sa\75D\46sntz\0751\46usg\75AFQjCNEhNwW1aqcHdi74FOsh2wLLwslxig';return \
true;">https://github.com/QubesOS/<wbr>qubes-vmm-xen</a> and <a \
href="https://github.com/QubesOS/qubes-linux-kernel" target="_blank" rel="nofollow" \
onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F \
QubesOS%2Fqubes-linux-kernel\46sa\75D\46sntz\0751\46usg\75AFQjCNEtD11l91BmgoRJ5jXWBHwx_BtPBA';return \
true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com \
%2FQubesOS%2Fqubes-linux-kernel\46sa\75D\46sntz\0751\46usg\75AFQjCNEtD11l91BmgoRJ5jXWBHwx_BtPBA';return \
true;">https://github.com/QubesOS/<wbr>qubes-linux-kernel</a>. Look in all of the \
patches.* directories there. The file series.conf lists the patches that are \
applied.</div><div><br></div><div>That said, none of those patches are responsible \
for your hardware-related issues. What is different between your experiences on \
Windows, Linux, or even Xen on Linux, is that none of those situations involve the \
use of "driver domains" (see <a \
href="http://wiki.xenproject.org/mediawiki/images/1/17/Device_passthrough_xen.pdf" \
target="_blank" rel="nofollow" \
onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwiki.xenproject \
.org%2Fmediawiki%2Fimages%2F1%2F17%2FDevice_passthrough_xen.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFCCAASPM2ZGlyBCDNWhXpUsIewaA';return \
true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwiki.xenproj \
ect.org%2Fmediawiki%2Fimages%2F1%2F17%2FDevice_passthrough_xen.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFCCAASPM2ZGlyBCDNWhXpUsIewaA';return \
true;">http://wiki.xenproject.<wbr>org/mediawiki/images/1/17/<wbr>Device_passthrough_xen.pdf</a> \
for a discussion about them). Your Fedora install with Xen still operates the \
network adapters in the same way as Fedora without Xen - in dom0 without the use of \
PCI passthrough. However, if you took the time to reconfigure your Xen on Fedora \
install to create a driver domain for your network adapters (which is possible), you \
would run into the same issues. In other words, it is not a Qubes problem (nor even \
a Xen problem) so much as your devices are being run in a slightly different \
environment, and they don't like it.</div><div><br></div><div><span \
style="font-family:arial,sans-serif;font-size:small">I do not know how much \
experience you have had with running Linux on laptops, but these kinds of issues are \
reasonably common in trying to get hardware that primarily has been developed for and \
tested on Windows working on open source operating systems. It was much worse years \
ago, when significant amounts of hardware lacked support or reasonably complete \
support, and as a result you had to be selective about the laptops you bought. \
Sometimes you get hardware that has zero support, and sometimes you get the square \
peg/round hole phenomenon - in that situation, you can either bang on it with a \
hammer to get it working (there are lots of cases where you can do this, if you want \
to dig into and modify the code involved), or you can find a round peg instead (in \
other words, replace the hardware - although this is harder on a laptop than a \
desktop, wifi cards are usually miniPCIE, and you can easily swap in a new wifi \
adapter that will work). The open source ethos generally gives you three options: \
(1) pitch in, identify and make the needed code and/or configuration changes to get \
your hardware working, and share the changes so others can use the hardware too; (2) \
wait long enough, and maybe someone else will do it for you; or (3) use different \
hardware that is known how to work. I suppose there is a fourth item: (4) give \
up.</span><br></div><div><span \
style="font-family:arial,sans-serif;font-size:small"><br></span></div><div><span \
style="font-family:arial,sans-serif;font-size:small">In this case, it sounds like you \
have two issues. First, the combined ethernet/card reader RTL8411 device, or the \
Linux drivers that were written for it, does not appear to like being run through PCI \
passthrough. This sometimes happens - it quite possible you are the first person \
ever to have tried running this device via PCI passthrough - it at least is all but \
certain the driver developer never did. Some Linux device drivers play a bit fast \
and loose with PCI registers, etc., and when they are run through PCI passthrough, \
Xen does not give them the degree of access that they expect. If you want to pursue \
the above "hammer" approach, you can dig into the driver for the RTL8411 \
ethernet, figure out what accesses are causing problems, and see if you can rewrite \
the driver to eliminate them. Also, as I noted before, the crashes you saw seem to \
be related to the card reader side of things - that is something else to dig into. \
If I were in your shoes, I would give up on trying to get the RTL8411 working, since \
in practice you want to use wifi on a laptop.</span></div><div><span \
style="font-family:arial,sans-serif;font-size:small"><br></span></div><div><span \
style="font-family:arial,sans-serif;font-size:small">Second, it sounds like your wifi \
adapter is so new that even on Fedora you had to just through hoops to get it to \
work. Although it is possible to replicate what you did in Fedora on Qubes, you may \
have to learn quite a bit (mostly about how Qubes packages up drivers and such and \
provides them to its PV domains) to make it happen. If I were in your shoes, I \
would buy a new wifi adapter for $25 on ebay and move on (something I have done in \
the past for unsupported or poorly supported wifi adapters). Another idea that I \
did not come up with before is that you could assign your USB controller to sys-net, \
and maybe use a USB-based wifi adapter, if for some reason you like that idea \
better.</span></div><div><span \
style="font-family:arial,sans-serif;font-size:small"><br></span></div><div><span \
style="font-family:arial,sans-serif;font-size:small">It is going to be a LONG time - \
if ever - before an open source OS such as Linux or Qubes is going to "just \
work" like Windows. You are running on very new hardware, and that complicates \
the situation. In the end, you will have to decide if you want to put forth the \
effort to get the hardware you have to do what you want, change the hardware involved \
to the extent you can, or change your mind about what you want to \
do.</span></div><div><span \
style="font-family:arial,sans-serif;font-size:small"><br></span></div><div><span \
style="font-family:arial,sans-serif;font-size:small">Eric</span></div></blockquote><div><br></div><div><br></div><div>There \
we go, exactly what i was looking for.... Ill do some research into this, Im quite \
familiar with linux in kernel development, i think the piece i need more research on \
is the driver layer for pci</div><div>and this "shared" issue im having. \
Much appreicated for the write up, as for changing my hardware, im comfortable with \
whats installed, its working, as for using Qubes, ive used it before and \
</div><div>installed it on about 7 different systems now. as for my needs, \
specifically qubes provides me virtualization with a net-vm and firewall vm... which \
is my specific purpose for its use.</div><div>It allows my that "extra" \
layer of security between my data and the "outside world". If i could \
duplicate that alone on XEN, under Fedora 23 i would, \
</div></div></div></blockquote><div><br></div><div>Just in case this is not clear, \
you actually could, without too much difficulty, replicate that aspect of things on \
Xen. Create a domU that owns the network adapters (a network domain), create \
another domU for a firewall (if desired), and do the necessary Linux networking magic \
to tie it all together, but you would have the same problems because it is more of a \
hardware-specific issue and PCI passthrough would come back into the \
picture.</div><div><br></div><div>FYI, there are not all that many people outside of \
Qubes making use of driver domains, so don't expect to find too many answers via \
Google searches. Expect to have to figure out a lot of it on your own. Probably a \
lot of what there is to learn from are efforts in trying to get passthrough working \
for GPUs on Xen, KVM, and QEMU. There was a big push to get that working on QEMU \
(mostly on KVM) a couple of years ago.</div><div><br></div><div>Eric</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/1d4e5dd7-5589-4f2a-9d8b-efc9a367c5 \
4e%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/1d4e5dd7-5589-4f2a-9d8b-efc9a367c54e%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
------=_Part_221_1437765117.1453242253554--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic