Dexuan,

I am attaching the logs & HVM configuration file with this email.

The log files are named accordingly.

Xend.log doesn’t contain anything after creating a HVM guest (before creating a HVM guest I cleared the log messages).

BTW, I am trying to direct assign a SAS controller and not a NIC.

Hi Venkat,

Can you attach the HVM config file? After you create the HVM guest and make it run (but the assigned NIC doesn't appear in guest's "lspci"), can you attach /var/log/xen/xend.log, /var/log/xen/qemu-dm-YourDomainName.log?

And can you attach all the log of serial cable -- from when Xen starts to boot, to after the HVM guest (with "pci=['xx:xx.x']" specified in hvm config file) is created? Please add "loglvl=all guest_logvel=all" in the Xen grub entry, like "kernel /boot/xen.gz dom0_mem=256m console=com1 loglvl=all guest_loglvl=all" to get verbose messages.

Thanks,
-- Dexuan

From: Kumar, Venkat [mailto:Venkat.Kumar@xxxxxxx]
Sent: 2008年8月6日 19:14
To: Han, Weidong; Cui, Dexuan
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Bryan York
Subject: RE: [Xen-devel] Xen-3.2.1 VT-d Support (NOT SURE WHETHER IT'SABUGOR...)

Thanks Randy, Dexuan.

Eventually I could boot Xen with VT-d enabled after disabling the PEG and enabling IGD.

I could also create HVM guests.

But while direct assigning a pci device (I am editing the configuration file to add pci=[‘PCIID’]) the HVM guest won’t show any error message and the HVM guest comes up successfully.

But lspci in the HVM guest is not showing up the device which has been direct assigned to him.

Before direct assigning I had bound the device to the pciback driver.

The dmesg in Domain0 shows me that pciback has seized that particular device.

The device is a LSI Mega Raid SAS controller.

Missed a word in the former mail. This is a BIOS "issue".

Randy (Weidong)

From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Han, Weidong
Sent: 2008年8月6日 16:59
To: Kumar, Venkat; Cui, Dexuan; Bryan York
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Xen-3.2.1 VT-d Support (NOT SURE WHETHER IT'SABUGOR...)

Venkat,

I think you are using PEG (which means IGD is disabled), right? This is a BIOS. I suggest you use IGD at this moment.

Randy (Weidong)

From: Kumar, Venkat [mailto:Venkat.Kumar@xxxxxxx]
Sent: 2008年8月6日16:22
To: Cui, Dexuan; Bryan York; Han, Weidong
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Xen-3.2.1 VT-d Support (NOT SURE WHETHER IT'S ABUGOR...)

As Dexuan suggested I used xen3.2.2-rc2.

With this version of xen with vtd=1 boot parameter I could boot successfully (I was not able to boot with vtd=1 in xen-3.2.1).

But I see the following in the boot messages when I do a xm dmesg after a boot.

===================================================

(XEN) Xen heap: 14MB (14956kB)

(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) Enabling APIC mode: Flat. Using 1 I/O APICs

(XEN) [VT-D]dmar.c:441: RMRR is incorrect.

(XEN) Failed to parse ACPI DMAR. Disabling VT-d.

(XEN) [VT-D]ACPI DMAR:No DMAR devices found

===================================================

If you observe the messages highlighted in RED.

VT-d is getting disabled due to some RMRR incorrect problem and in the dmar.c code this is the condition which is causing this.

if ( rmrr->base_address >= rmrr->end_address )

{

dprintk(XENLOG_ERR VTDPREFIX, "RMRR is incorrect.\n");

return -EFAULT;

}

This code is in acpi_parse_one_rmrr function.

Hi Bryan,

According to our tests using the latest xen-unstable, the assignment of SATA controller (like in AHCI mode or Enhanced mode) should be OK on the DQ35 platform.

From: Bryan York [mailto:bryan.york@xxxxxxxxx]
Sent: 2008年8月6日 12:10
To: Han, Weidong
Cc: Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Xen-3.2.1 VT-d Support (NOT SURE WHETHER IT'S A BUGOR...)