Hi,
after a few tests, i can confirm that VT-d on Supermicro X7SBE/X7SB4
doesn't work at all.
I assume this has to do with invalid ACPI table content.
I've tried xen 3.2-testing, xen unstable and vanilla 2.6.24.1 (CONFIG_DMAR=y).
None of the routines is able to detect a valid DMAR structure.
While xen 3.2 and xen unstable report this as failure and are booting whith
!vtd_enabled,
the vanilla kernel prefers to get stuck in an endless kprint() loop ;)
Hopefully, the supermicro tech support will provide a solution.
cheers
Stephan
Stephan Seitz schrieb:
You, Yongkang schrieb:
On Friday, February 08, 2008 11:10 PM, "Stephan Seitz" wrote:
My question is, do I need to add patches, or use specific changesets
to have VT-d code available in xen / dom0 kernel? If so, could
someone provide me link?
There is a VT-d quick README in xen_source/docs/misc/vtd.txt
Anotherr link:
http://wiki.xensource.com/xenwiki/VTdHowTo?highlight=%28vtd%29
Thanks for your quick response, next time I'll take a look at /docs
first... ;)
Anyway, I've tried this with my currently available kernel (with pciback
as module),
as well as I did pciback hiding via modprobe the HVM refuses to load
the pci device
(No vt-d or device not found or device not hidden).
I'm not sure if this is caused by an unsupported chipset or my
xen-build. So I'll
follow the docs step-by-step and post the results later.
By now xm dmesg shows following statement about VT-D:
(Don't know if this messages is caused by an unsupported chipset. I'll
see...)
\ \/ /___ _ __ |___ / |___ \ / _ \
\ // _ \ '_ \ |_ \ __) || | | |
/ \ __/ | | | ___) | / __/ | |_| |
/_/\_\___|_| |_| |____(_)_____(_)___/
(XEN) Xen version 3.2.0 (root@xxxxxxxxxx) (gcc version 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)) Mon Jan 21 10:18:53 CET 2008
(XEN) Latest ChangeSet: unavailable
(XEN) Command line: loopback.nloopbacks=16 dom0_mem=512M vtd=1
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 2 MBR signatures
(XEN) Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009dc00 (usable)
(XEN) 000000000009dc00 - 00000000000a0000 (reserved)
(XEN) 00000000000ce000 - 00000000000d0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000cfe70000 (usable)
(XEN) 00000000cfe70000 - 00000000cfe83000 (ACPI data)
(XEN) 00000000cfe83000 - 00000000cfe86000 (ACPI NVS)
(XEN) 00000000cfe86000 - 00000000d0000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fec00000 - 00000000fed00000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ff000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000130000000 (usable)
(XEN) System RAM: 4094MB (4192308kB)
(XEN) Xen heap: 14MB (14952kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Processor #0 6:15 APIC version 20
(XEN) Processor #1 6:15 APIC version 20
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfecc0000, GSI 24-47
(XEN) IOAPIC[2]: apic_id 4, version 32, address 0xfecc0400, GSI 48-71
(XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) [VT-D]ACPI DMAR:Unknown DMAR structure type
(XEN) [VT-D]ACPI DMAR:No DMAR devices found
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2660.040 MHz processor.
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz stepping 0b
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz stepping 0b
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) Platform timer overflows in 14998 jiffies.
(XEN) Platform timer is 14.318MHz HPET
(XEN) Brought up 2 CPUs
(XEN) AMD IOMMU: Disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 ->
0xffffffff80680688
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000012a000000->000000012c000000 (122880 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff80680688
(XEN) Init. ramdisk: ffffffff80681000->ffffffff81a58a00
(XEN) Phys-Mach map: ffffffff81a59000->ffffffff81b59000
(XEN) Start info: ffffffff81b59000->ffffffff81b594a4
(XEN) Page tables: ffffffff81b5a000->ffffffff81b6b000
(XEN) Boot stack: ffffffff81b6b000->ffffffff81b6c000
(XEN) TOTAL: ffffffff80000000->ffffffff81c00000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 2 VCPUs
[...]
Indeed, I found a lot of information in xen-devel, but I don't know
which of the submitted patches are accepted and which are merged into
mercurial.
Is redirection of e.g. a pci network card or a pci isdn card possible
for hvm domU's without special driver support by the guest (say:
windows)?
Guest needs drivers to enable devices. Dom0 doesn't need.
Is there any support for pci/e and/or pci-x?
Yes. It supports PCIe and PCI/x devices. But, guest doesn't supported
MSI yet. For example, in Linux (kernel >=2.6.18), it needs an
additional kernel boot option: "pci=nomsi".
Best Regards,
Yongkang You
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
--
Stephan Seitz
Senior System Administrator
*netz-haut* e.K.
multimediale kommunikation
zweierweg 22
97074 würzburg
fon: +49 931 2876247
fax: +49 931 2876248
web: www.netz-haut.de <http://www.netz-haut.de/>
registriergericht: amtsgericht würzburg, hra 5054
s_seitz.vcf
Description: Vcard
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|