Re: [Xen-devel] VT-D On An Asus P5E-VM DO Motherboard Not Working, Xen 3.4.1

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Hello Dexuan,

Although  it  would be the best, as one little tiny customer you don't
make a very big impression on firms like ASUS (believe me I have tried
..)  and  bios  manufacturers  like  award  phoenix etc. You don't get
passed  customer  support  with there standard denial: only supporting
microsoft windows (so no virtualization what so ever).

So what perhaps could make an impression:

1)  Naming  and  shaming  on  the  VT-D wiki, that these boards do NOT
support it properly. This also warns potential customers.

2)  Pressure  from  Intel, that manufactures who do not implement VT-D
properly  (and/or  not correct it properly if there are problems) are not 
allowed to mention
it as features of there motherboards anymore. This makes sense because
i'm at the point i'm waiting for AMD to get there IOMMU on the market.
Hope  they  are  somehow  less dependant on bios manufacturers, and it
actually works without these problems.

At  the  moment  buying  an Intel motherboard should be the safest bet,
because although there have been reports of problems with them as well
(according  to  mailing  lists)  they  have  a  larger chance of being
resolved.  But  most  of the times they are not as feature complete as
other boards.

Perhaps  a boot option "relax_iommu_checks" would be handy in the mean
time.

For  the record, ASUS P5Q-EM DO has the same problems, also tested all
available  bioses,  contacted  both  ASUS and there BIOS manufacturer,
with no result what so ever.

Regards,

Sander




Monday, September 28, 2009, 4:33:14 AM, you wrote:

> Hi Michael,
> You can try the workaround patch below (for xen-unstable.hg). Hope it would 
> help.
> However, please remember the right solution is pushing your BIOS vendor to 
> fix the buggy BIOS. :-)

> Thanks,
> -- Dexuan 

> diff -r 623aa5c2eaa4 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c    Fri Sep 25 15:20:58 2009 +0100
> +++ b/xen/drivers/passthrough/vtd/dmar.c    Mon Sep 28 10:25:33 2009 +0800
> @@ -413,7 +413,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
>          dprintk(XENLOG_ERR VTDPREFIX,
>                  "RMRR error: base_addr %"PRIx64" end_address %"PRIx64"\n",
>                  rmrr->base_address, rmrr->end_address);
> -        return -EFAULT;
+        rmrr->>end_address = 0xFFFFFFFF;
>      }
>  
>  #ifdef CONFIG_X86
> diff -r 623aa5c2eaa4 xen/drivers/passthrough/vtd/x86/vtd.c
> --- a/xen/drivers/passthrough/vtd/x86/vtd.c Fri Sep 25 15:20:58 2009 +0100
> +++ b/xen/drivers/passthrough/vtd/x86/vtd.c Mon Sep 28 10:26:16 2009 +0800
> @@ -31,7 +31,7 @@
>   * iommu_inclusive_mapping: when set, all memory below 4GB is included in 
> dom0
>   * 1:1 iommu mappings except xen and unusable regions.
>   */
> -static int iommu_inclusive_mapping;
> +static int iommu_inclusive_mapping = 1;
>  boolean_param("iommu_inclusive_mapping", iommu_inclusive_mapping);
>  
>  void *map_vtd_domain_page(u64 maddr)


> ________________________________

> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Michael MacLeod
> Sent: 2009?9?27? 4:18
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] VT-D On An Asus P5E-VM DO Motherboard Not Working, Xen 
> 3.4.1


> I've been trying to get VT-D working with Xen and my Asus P5E-VM DO
> motherboard for the last week. This board is listed on the VTdHowTo
> xen wiki page as supported, and I've found another subscriber of the
> xen-users list who has this configuration working, which makes my predicament 
> all the more odd.

> I'm using debian lenny as my dom0 OS, though I've built Xen 3.4.1
> from source and can replicate this problem with both the lenny
> 2.6.26-2-xen-amd64 kernel and the Xen 2.6.18-xen.hg kernel I built.
> I've tried several different BIOS revisions, and the problem is consistent 
> across them.

> Here's some output from my bootup and from acpidump:

> # xm dmesg | grep -C1 VT-D
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 36
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fed90000
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1b.0
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fed92000
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:3.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:3.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:3.3
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fed93000
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1a.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1a.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1a.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1a.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR

> (XEN) [VT-D]dmar.c:388: RMRR error: base_addr d0000000 end_address cfffffff
> (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.


> # acpidump -t DMAR
> Wrong checksum for OEMB!
> Wrong checksum for !

> # acpidump | grep -B3 -A20 DMAR
> Wrong checksum for OEMB!
> Wrong checksum for !

>  @ 0xcff601b0
>   0000: 00 4d 41 52 48 01 00 00 01 f5 41 4d 49 00 00 00  .MARH.....AMI...
>   0010: 4f 45 4d 44 4d 41 52 00 01 00 00 00 4d 53 46 54  OEMDMAR.....MSFT
>   0020: 97 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00  ....#...........
>   0030: 00 00 18 00 00 00 00 00 00 00 d9 fe 00 00 00 00  ................
>   0040: 01 08 00 00 00 00 1b 00 00 00 28 00 00 00 00 00  ..........(.....
>   0050: 00 20 d9 fe 00 00 00 00 01 08 00 00 00 00 03 00  . ..............
>   0060: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03  ................
>   0070: 00 00 10 00 01 00 00 00 00 30 d9 fe 00 00 00 00  .........0......
>   0080: 01 00 58 00 00 00 00 00 00 d0 0e 00 00 00 00 00  ..X.............
>   0090: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00  ................
>   00a0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02  ................
>   00b0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00  ................
>   00c0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02  ................
>   00d0: 01 08 00 00 00 00 1a 07 01 00 18 00 00 00 00 00  ................
>   00e0: 00 00 00 d0 00 00 00 00 ff ff ff cf 00 00 00 00  ................
>   00f0: 01 00 58 00 00 00 00 00 00 00 fe cf 00 00 00 00  ..X.............
>   0100: ff ff fe cf 00 00 00 00 01 08 00 00 00 00 1d 00  ................
>   0110: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02  ................
>   0120: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00  ................
>   0130: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02  ................
>   0140: 01 08 00 00 00 00 1a 07                          ........

> I've posted the my full xm dmesg here:
> http://pastebin.com/m32beff18 and you can find my full dmesg output
> here: http://pastebin.com/m74a7dc2a

> The other user of the xen-users list (Christian Tramnitz) who has
> VT-D working with the same motherboard and BIOS revision listed this as the 
> output he gets:

> (XEN) [VT-D]iommu.c:722: iommu_page_fault: iommu->reg = ffff828bfff56000
> (XEN) [VT-D]iommu.c:691: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:694: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:676: iommu_fault:DMA Write: 0:2.0 addr
> 400000000 REASON 5 iommu->reg = ffff828bfff56000
> (XEN) print_vtd_entries: iommu = ffff83022bde62d0 bdf = 0:2:0 gmfn = 400000
> (XEN)     root_entry = ffff83022bdcf000
> (XEN)     root_entry[0] = 224cc8001
> (XEN)     context = ffff830224cc8000
> (XEN)     context[10] = 101_22bdb3001
> (XEN)     l3 = ffff83022bdb3000
> (XEN)     l3_index = 10
> (XEN)     l3[10] = 0
> (XEN)     l3[10] not present

> # acpidump | grep -B3 -A20 DMAR

> Wrong checksum for OEMB
> Wrong checksum for

> Wrong checksum for OEMB!

> @ 0xcf5601b0
>  0000: 00 4d 41 52 40 01 00 00 01 01 41 4d 49 00 00 00  .MAR@.....AMI...

>  0010: 4f 45 4d 44 4d 41 52 00 01 00 00 00 4d 53 46 54  OEMDMAR.....MSFT
>  0020: 97 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00  ....#...........
>  0030: 00 00 18 00 00 00 00 00 00 10 d9 fe 00 00 00 00  ................

>  0040: 01 08 00 00 00 00 02 00 00 00 18 00 00 00 00 00  ................

>  0050: 00 20 d9 fe 00 00 00 00 01 08 00 00 00 00 03 00  . ..............

>  0060: 00 00 10 00 01 00 00 00 00 30 d9 fe 00 00 00 00  .........0......
>  0070: 01 00 58 00 00 00 00 00 00 d0 0e 00 00 00 00 00  ..X.............
>  0080: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00  ................
>  0090: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02  ................
>  00a0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00  ................
>  00b0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02  ................
>  00c0: 01 08 00 00 00 00 1a 07 01 00 20 00 00 00 00 00  .......... .....
>  00d0: 00 00 60 cf 00 00 00 00 ff ff ff cf 00 00 00 00  ..`.............
>  00e0: 01 08 00 00 00 00 02 00 01 00 58 00 00 00 00 00  ..........X.....
>  00f0: 00 00 5e cf 00 00 00 00 ff ff 5e cf 00 00 00 00  ..^.......^.....
>  0100: 01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01  ................
>  0110: 01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07  ................
>  0120: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01  ................
>  0130: 01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07  ................

> XSDT @ 0xcf550100
> Wrong checksum for !

> # acpidump -t DMAR
> Wrong checksum for OEMB
> Wrong checksum for
> Wrong checksum for OEMB!
> Wrong checksum for !

> I've also, on the suggestion of Christian I tried disabling USB in
> the BIOS completely, as he said that he had to do that with a
> different Asus motherboard that also supported VT-D before it would
> work, but that didn't resolve the problem for me.

> Please let me know if there is anything else I can try or any other
> info I can provide. I'd be quite happy to work with a dev to
> determine the exact source of the problem and test patches, etc.

> Thanks,
> Mike






-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel