[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] VT-d with Supermicro MBD-X10SAE-O

  • To: xen-users@xxxxxxxxxxxxx
  • From: Qubes Fan <qubesfan@xxxxxxxxx>
  • Date: Thu, 20 Jun 2013 01:42:57 -0700
  • Delivery-date: Thu, 20 Jun 2013 08:44:17 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

Hi all,

I'm having difficulty getting VT-d to work correctly with a new Supermicro MBD-X10SAE-O in QubesOS, and I'm hoping someone here might be able to help me (or at least shed some light on my situation). A Qubes developer suggested I contact this list. Here's my HCL post from the qubes-users group (full thread):
HCL Report (2013-06-17)

Qubes release 2 (R2)
Model Name:    Supermicro X10SAE

Chipset:    00:00.0 Host bridge [0600]: Intel Corporation Haswell DRAM Controller [8086:0c08] (rev 06)
VGA:        01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Juniper [Radeon HD 5700 Series] [1002:68b8]
CPU:        Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz
BIOS:        1.00
VT-x:        Active
VT-d:        Not Active

After several days of troubleshooting and around twenty reinstallations, here is what I've come up with:

The MOBO and CPU both support VT-d, but I had to disable it in the BIOS in order to get Qubes working.

Explanation: If VT-d is enabled in the BIOS, then installation of Qubes proceeds normally up the last step (VM creation). At this stage, the user is presented with three options. The first two options create some VMs, while the third option creates no VMs (and leaves the user to do it manually later). If either of the first two options is selected, the system completely freezes when installation tries to create the netvm. A hard reboot is necessary. If the third option is chosen (i.e., create no VMs during installation), then the installation completes successfully, and the user can log in. But the system again freezes as soon as a netvm is manually created (with 'qvm-create --net --label red netvm' in dom0), and again a hard reboot is required. (I tried pretty much every possible combination of assigning different devices to the netvm before starting it up, but the system keeps freezing. I also tried updating (i.e., qubes-dom0-update), but no dice.)

Question/Hypothesis: Is this happening because the new Haswell implementation of VT-d (if there is such a thing) is not yet supported by the version of the Linux kernel we're using? Or maybe it's not yet supported by (the version of) Xen we're using? After all, this MOBO/CPU just came out in the last week or so. Maybe I just need to wait for an update?

The CPU has integrated Intel HD 4600 (GT2) graphics, but I had to use a discrete GPU in order to install Qubes.

Explanation: I actually chose the Xeon E3-1245v3 over the E3-1230v3 because the former has Intel graphics, and the HCL page recommends Intel graphics over nVidia/AMD. But, as it turns out (in my case, at least), using an AMD Radeon HD 5770 was necessary. At first, I tried installing Qubes with just the MOBO and CPU (no discrete graphics, no other PCI/e devices of any kind). This caused several errors during the installation, which I have seen others mention (in different situations). The first major thing that happened is that the graphical install failed (I believe it said, 'X startup failed'), and it kicked back to an anaconda text-only installation. I was able to select my options (time zone, storage device target for installation, etc.), but then I received an error which said, 'luks device has no key'. (I gathered from a post by Marek in an old thread that this is probably due to shortcomings in anaconda.) The installation could not proceed. So then I slotted in the Radeon HD 5770, and everything was fine.

Question/Hypothesis: Same as above. Maybe this is a kernel/Xen issue? I'm not personally worried about it, as the HD 5770 is working fine, but this may be important to others. By contrast, I really want VT-d to work.

Request for assistance: Is there anything else I can try to do to get VT-d working?
Things I've tried since posting the above: disabling TXT, disabling Vanderpool/VT-x, using Qubes with Xen 4.1.2, using Qubes with Xen 4.1.5, using Qubes with Linux kernel 3.9.2.

I've also installed the latest version of Xen with regular Fedora 18 as the host OS (all with VT-d enabled in the BIOS). Everything works fine so far, but I don't know how to check whether VT-d is enabled (or how to enable it) or test it. This page explains that I need 'iommu=1' as a boot parameter, but even after extensive searching, I can't seem to figure out how to actually do that with the current versions of Xen and Fedora.

Thank you for reading! Any help you can provide would be greatly appreciated!
Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.