Re: [qubes-users] clarification on usb qubes
On Tuesday, June 7, 2016 at 12:56:31 PM UTC-4, raah...@gmail.com wrote: > Actually when looking at the manual looks like I'm wrong. > > "Allows you to determine whether to rout the USB 3.0 ports to the xHCI or > EHCI controller > before booting to OS, and also provides you with options to manually rout > each USB3.0/2.0 port to xHCI or EHCI." > > Not sure if you will even get two controllers with usb3.0 on? I dunno i'd > have to play with it to know. Well I can tell you with one of my machines. disabling xhci means I get two ehci controllers. one for the 2 ports by the ps2 port. and one for the rest. So maybe you can route the usb 3.0 ports to the xhci. and then usb2.0 to the ehci and have two, and maybe possibly 3. But I don't have a board like this to test. -- 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/44fc36a6-572a-4733-9698-771bc017b6f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clarification on usb qubes
On Tuesday, June 7, 2016 at 4:41:15 AM UTC-4, Ilpo Järvinen wrote: > On Mon, 6 Jun 2016, raahe...@gmail.com wrote: > > > In order to have 3 usb controllers the only board I have found where > > this might be possible is with a 2011 socket board, and a board that > > has a bios that gives the ability to manually route the controllers. > > But who knows how compatible with linux the newer boards are at the > > moment, might run into other problems since not many people using them > > yet. > > Can you point me to some example motherboard? I've looked more than dozen > X99/C612 board manuals recently but I've not come across one so far with > such options. I'd be interested in seeing the bios part of the > motherboard's manual. Or do you refer to Sandybridge/Ivybridge MBs with > the "2011 socket"? If such a board really exists, it would further > reinforce that it may be possible also for the OS to play with > the forwarding (such forwarding forcing code already exists in Linux > XHCI driver anyway, it's just a question if the supported mask has > any/all bits enabled or not). If forwarding can be manipulated > successfully, then superspeed would not need to be disabled to > differentiate the USB ports to different controllers. > > Usually the manuals I've seen list only "legacy USB support", etc. > toggleable options. Although given the naming, I wouldn't be surprised > if some of those more standard bios options could be used to disable the > auto-forwarding. According to my understanding the reason behind > the forwarding is that if OS doesn't have necessary device drivers for > one of the controllers some of the ports wouldn't work, which would be > too confusing to many users. > > > -- > i. Most modern boards give you the option to shut off the usb 3.0. This "usually" means all the usb 3.0 ports will then become 2.0 ports. (and you will get two controllers as i described above) Here is a cheaper 2011 board with the manual routing option, and also an option to just not route to xhci which looks interesting. Gigabyte GA-X99-UD3P LGA 2011 It has intel vt, although it says its disabled by default. Most gigabyte boards have it enabled by default so that would worry me. But might be meaningless. Are you referring to the handoffs when you say forwarding for os without drivers? I always shut all that off never had a problem. -- 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/fe5996e6-97d7-4c95-a4cf-3fc80e7b03f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clarification on usb qubes
Actually when looking at the manual looks like I'm wrong. "Allows you to determine whether to rout the USB 3.0 ports to the xHCI or EHCI controller before booting to OS, and also provides you with options to manually rout each USB3.0/2.0 port to xHCI or EHCI." Not sure if you will even get two controllers with usb3.0 on? I dunno i'd have to play with it to know. -- 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/3af58a27-0a7e-4f3e-9c6f-58363e0e01f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clarification on usb qubes
On Mon, 6 Jun 2016, raahe...@gmail.com wrote: > In order to have 3 usb controllers the only board I have found where > this might be possible is with a 2011 socket board, and a board that > has a bios that gives the ability to manually route the controllers. > But who knows how compatible with linux the newer boards are at the > moment, might run into other problems since not many people using them > yet. Can you point me to some example motherboard? I've looked more than dozen X99/C612 board manuals recently but I've not come across one so far with such options. I'd be interested in seeing the bios part of the motherboard's manual. Or do you refer to Sandybridge/Ivybridge MBs with the "2011 socket"? If such a board really exists, it would further reinforce that it may be possible also for the OS to play with the forwarding (such forwarding forcing code already exists in Linux XHCI driver anyway, it's just a question if the supported mask has any/all bits enabled or not). If forwarding can be manipulated successfully, then superspeed would not need to be disabled to differentiate the USB ports to different controllers. Usually the manuals I've seen list only "legacy USB support", etc. toggleable options. Although given the naming, I wouldn't be surprised if some of those more standard bios options could be used to disable the auto-forwarding. According to my understanding the reason behind the forwarding is that if OS doesn't have necessary device drivers for one of the controllers some of the ports wouldn't work, which would be too confusing to many users. -- i.
Re: [qubes-users] clarification on usb qubes
On Sunday, June 5, 2016 at 4:07:17 PM UTC-4, Ilpo Järvinen wrote: > On Sun, 5 Jun 2016, Marek Marczykowski-Górecki wrote: > > > On Sat, Jun 04, 2016 at 06:13:45PM -0700, pixel fairy wrote: > > > > > Is it possible to have multiple usb qubes, one > > > for each controller? > > > > Yes, if you have multiple USB controllers. Which is quite rare > > nowadays... > > At least for recent desktop motherboards, that seems slightly incorrect > statement according to my research. Few desktop PCH datasheets I've > looked, indicate that there are two USB controllers (EHCI and XHCI), > however, it seems that typically on a modern MB the ports are > forwarded/routed by default so that they appear under a single controller > due to ease of use reasons (also Linux device driver code forces > forwarding all ports which allow forwarding). XHCI PCI config has XUSB2PR > register that might allow disabling the forwarding for a selected set of > registers. > > I'm yet to test if the forwarding/routing works for real because I lack > such a motherboard (I'll likely get one sooner than later though) but I > see no particular reason why it wouldn't work as documented. Probably > laptop PCH have similar arrangement and I might be able to test that one > soon if I find enough time to play with the usbvm kernel. Another thing > that needs testing, even if routing is configurable, is whether PCHs > really support EHCI and XHCI in different VMs or if there's some > other limiting depency between them. > > I've attached potentially working patch for Linux kernel. The mapping > between PCI register ports might not be consistent though so that the > patch might not exactly do what intented as is (usb3/superspeed port > might unintentionally be routed to EHCI, the docs are unclear on this > point). However, if any USB port would successfully appear as EHCI one > when using a kernel with that patch in usb vm, it is great success in > itself on truly separating the ports. > > At least X99/C612 and some recent Series X PCH datasheets listed the > required register (in case somebody is interested in testing this). > > I suspect that for a secure implementation Xen would need to somehow > arbitrate that PCI register as otherwise the xhci usb VM might be able > to steal the usb ports from the ehci VM. But this is already way beyond > my current level of understanding about Xen and PCI passthrough. > > > -- > >From what i"ve learned when building desktop for qubes and from my own >experience on desktop machines only.Older pc's without usb3, usually >have two controllers. One controller is for the two usb ports next to the ps2 >slot. I always assumed it was for mouse and kb at the slower usb1 speed (ahci) > And all the other usb ports on the 2nd controller(ehci). When building a newer qubes machine i5 1150 board (new for me) I was under the impression I would then get 3 controllers since it had usb3 (xhci) and i saw in the spec sheets it stated ahci, ehci, and xhci. But as Ilpo explained, all the controllers are automatically routed through the xhci controller. Which means that there is only actually a single controller, not 3. In most motherboard bios though you can disable xhci (usb3.0) which means you can use the other two controllers seperately. one for dom0 and one for usbvm. But then you won't get the super usb speeds, they will all be only at high speed (usb2.0). For super speed usb3.0 you can use the mouse proxy in qubes which worked well for me with the system only having a single usb controller on usbvm. But I set it up with a ps2 kb. (you can pick up a cheap usb to ps2 adapter since ps2 kb's are harder to come by. But you will need to use terminal when restarting the sys-usb after an update which is not too noob friendly for people not too computer illiterate. You can use a usb keyboard proxy too in qubes but that is a security risk and might be even more difficult for a nooby to manage. In order to have 3 usb controllers the only board I have found where this might be possible is with a 2011 socket board, and a board that has a bios that gives the ability to manually route the controllers. But who knows how compatible with linux the newer boards are at the moment, might run into other problems since not many people using them yet. -- 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/6f1f8379-ae10-4a8c-b527-e5cfb86b6b95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clarification on usb qubes
On Sun, 5 Jun 2016, Marek Marczykowski-Górecki wrote:
> On Sat, Jun 04, 2016 at 06:13:45PM -0700, pixel fairy wrote:
>
> > Is it possible to have multiple usb qubes, one
> > for each controller?
>
> Yes, if you have multiple USB controllers. Which is quite rare
> nowadays...
At least for recent desktop motherboards, that seems slightly incorrect
statement according to my research. Few desktop PCH datasheets I've
looked, indicate that there are two USB controllers (EHCI and XHCI),
however, it seems that typically on a modern MB the ports are
forwarded/routed by default so that they appear under a single controller
due to ease of use reasons (also Linux device driver code forces
forwarding all ports which allow forwarding). XHCI PCI config has XUSB2PR
register that might allow disabling the forwarding for a selected set of
registers.
I'm yet to test if the forwarding/routing works for real because I lack
such a motherboard (I'll likely get one sooner than later though) but I
see no particular reason why it wouldn't work as documented. Probably
laptop PCH have similar arrangement and I might be able to test that one
soon if I find enough time to play with the usbvm kernel. Another thing
that needs testing, even if routing is configurable, is whether PCHs
really support EHCI and XHCI in different VMs or if there's some
other limiting depency between them.
I've attached potentially working patch for Linux kernel. The mapping
between PCI register ports might not be consistent though so that the
patch might not exactly do what intented as is (usb3/superspeed port
might unintentionally be routed to EHCI, the docs are unclear on this
point). However, if any USB port would successfully appear as EHCI one
when using a kernel with that patch in usb vm, it is great success in
itself on truly separating the ports.
At least X99/C612 and some recent Series X PCH datasheets listed the
required register (in case somebody is interested in testing this).
I suspect that for a secure implementation Xen would need to somehow
arbitrate that PCI register as otherwise the xhci usb VM might be able
to steal the usb ports from the ehci VM. But this is already way beyond
my current level of understanding about Xen and PCI passthrough.
--
i.
--
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/alpine.DEB.2.10.1606052218040.12951%40melkinpaasi.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..87fca0f 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -867,6 +867,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
{
u32 ports_available;
+ u32 ports_usb3;
bool ehci_found = false;
struct pci_dev *companion = NULL;
@@ -920,6 +921,7 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
_available);
+ ports_usb3 = ports_available;
dev_dbg(_pdev->dev,
"USB 3.0 ports that are now enabled under xHCI: 0x%x\n",
ports_available);
@@ -931,6 +933,8 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
_available);
+ /* Only switch ports that are truly SuperSpeed capable. */
+ ports_available &= ports_usb3;
dev_dbg(_pdev->dev, "Configurable USB 2.0 ports to hand over to xCHI: 0x%x\n",
ports_available);
[qubes-users] clarification on usb qubes
Still shopping for a good laptop. >From reading this, https://www.qubes-os.org/doc/usb/ I gather you can make a usb qube, attach your mouse to it, then use it from dom0, though it would be possible for the usb qubes to spy on or mess with your mouse if its infected. So, if you only have one usb qube, would the process look like this? 1. unplug mouse 2. restart usb qube 3. run your app relying on your laptops touch pad 4. restart usb qube again 5. plug your mouse back in 6. reassign mouse back to dom0 I dont mind doing this, Its similar to how i already use the usb vm on my current laptop. Just want to make sure the process is right because it affects laptop selection. Is it possible to have multiple usb qubes, one for each controller? -- 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/2bd48ed4-eb45-4d85-b345-a7041953d41a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
