Vt-d not working with 3.4.1

Vt-d not working with 3.4.1

[Bonenkamp, Ralf]

Hi folks,

currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
to a HVM domU.
Unfortunate there seem some issue with the VT-d DMAR tables which is
beyond my knowledge and probably someone has some hint how to proceed?
:-)

Find attached the output of xm dmesg. Please drop a short note whatever
additional information might be needed... 

Best regards & thanks in advance
Ralf Bonenkamp

---- snip
__  __            _____ _  _    _
 \ \/ /___ _ __   |___ /| || |  / |
  \  // _ \ '_ \    |_ \| || |_ | |
  /  \  __/ | | |  ___) |__   _|| |
 /_/\_\___|_| |_| |____(_) |_|(_)_|

(XEN) Xen version 3.4.1 (root@jrnet.private) (gcc version 4.3.3 (Ubuntu
4.3.3-5ubuntu4) ) Sat Aug  8 21:53:36 BST 2009
(XEN) Latest ChangeSet: Thu Aug 06 13:27:53 2009 +0100
19718:13fe7f07df15
(XEN) Command line: iommu_inclusive_mapping=1 iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ec00 (usable)
(XEN)  000000000009ec00 - 00000000000a0000 (reserved)
(XEN)  00000000000e4000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000007d550000 (usable)
(XEN)  000000007d550000 - 000000007d55e000 (ACPI data)
(XEN)  000000007d55e000 - 000000007d5e0000 (ACPI NVS)
(XEN)  000000007d5e0000 - 000000007d600000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffc00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2004MB (2053048kB)
(XEN) ACPI: RSDP 000F9A80, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT 7D550100, 0064 (r1 A_M_I_ OEMXSDT   2000917 MSFT
97)
(XEN) ACPI: FACP 7D550290, 00F4 (r3 A_M_I_ OEMFACP   2000917 MSFT
97)
(XEN) ACPI: DSDT 7D5505C0, 843B (r1  A0869 A0869001        1 INTL
20060113)
(XEN) ACPI: FACS 7D55E000, 0040
(XEN) ACPI: APIC 7D550390, 006C (r1 A_M_I_ OEMAPIC   2000917 MSFT
97)
(XEN) ACPI: MCFG 7D550400, 003C (r1 A_M_I_ OEMMCFG   2000917 MSFT
97)
(XEN) ACPI: OEMB 7D55E040, 0081 (r1 A_M_I_ AMI_OEM   2000917 MSFT
97)
(XEN) ACPI: HPET 7D558A00, 0038 (r1 A_M_I_ OEMHPET   2000917 MSFT
97)
(XEN) ACPI: GSCI 7D55E0D0, 2024 (r1 A_M_I_ GMCHSCI   2000917 MSFT
97)
(XEN) ACPI: iEIT 7D560100, 00B0 (r1 A_M_I_ EITTABLE  2000917 MSFT
97)
(XEN) ACPI: DMAR 7D5601B0, 0158 (r1    AMI  OEMDMAR        1 MSFT
97)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 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:401: RMRR address range not in reserved memory base =
7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
needed.
(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2999.981 MHz processor.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz stepping 0a
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz stepping 0a
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) checking TSC synchronization across 2 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) Brought up 2 CPUs
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(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 = ffff83007d54a370 bdf = 0:2:0 gmfn =
400000
(XEN)     root_entry = ffff83007d543000
(XEN)     root_entry[0] = 795c6001
(XEN)     context = ffff8300795c6000
(XEN)     context[10] = 101_7d0ec001
(XEN)     l3 = ffff83007d0ec000
(XEN)     l3_index = 10
(XEN)     l3[10] = 0
(XEN)     l3[10] not present
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x76d000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000076000000->0000000078000000 (465255 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff8076d000
(XEN)  Init. ramdisk: ffffffff8076d000->ffffffff81d4c600
(XEN)  Phys-Mach map: ffffe20000000000->ffffe2000039cb38
(XEN)  Start info:    ffffffff81d4d000->ffffffff81d4d4b4
(XEN)  Page tables:   ffffffff81d4e000->ffffffff81d61000
(XEN)  Boot stack:    ffffffff81d61000->ffffffff81d62000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82000000
(XEN)  ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 2 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 132kB init memory.
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
(XEN) no cpu_id for acpi_id 3
(XEN) no cpu_id for acpi_id 4

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

RE: Vt-d not working with 3.4.1

[Bonenkamp, Ralf]

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Mon, Aug 17, 2009 at 04:46:29PM +0200, Bonenkamp, Ralf wrote:
> Hi Pasi,
> 
> Sorry - I forgot to mention that I've tried setting the iommu_inclusive_mapping=1 
> parameter too, but unfortunate I posted the output from a previous attempt without this parameter.
> 
> The xm dmesg output and the DMAR parsing error remains the same. This was the reason posting, because I ran out of ideas...
> 

Ok. I remember discussions about Asus having buggy BIOS for VT-d stuff, so
maybe that's your problem here aswell..

I can't unfortunately help you more.. hopefully others can.

-- Pasi

> Best regards
> Ralf Bonenkamp
> 
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
> Sent: Montag, 17. August 2009 16:32
> To: Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
> 
> On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> > Hi folks,
> > 
> > currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> > DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> > extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> > want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> > to a HVM domU.
> > Unfortunate there seem some issue with the VT-d DMAR tables which is
> > beyond my knowledge and probably someone has some hint how to proceed?
> > :-)
> >
> 
> Well did you try iommu_inclusive_mapping=1, like it suggests ?
>  
> > (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> > 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> > needed.
> > (XEN) Intel VT-d DMAR tables have been parsed.
> 
> -- Pasi

RE: Vt-d not working with 3.4.1

[Ross Philipson]

The message will remain regardless of whether you set iommu_inclusive_mapping or not. The parameter is there to work around the underlying issue but the issue is not actually corrected. So the code that generates the message (which is detecting discrepancies between the e820 map and the DMAR RMRR values) will continue to report this even though you used the parameter. The real question is whether you are experiencing some other problems beyond the warning message - like a boot hang?

Thanks
Ross

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 10:46 AM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

RE: Vt-d not working with 3.4.1

[Bonenkamp, Ralf]

Hi Ross,

thanks for this clarification! I misinterpreted the iommu_inclusive_mapping=1 thing in the way that this would prevent the log message ;-)
The interesting point is now that my system booted up fine with AND without iommu_inclusive_mapping=1!

In both cases hiding a PCI device via pciback.hide at boot time using a grub entry was not successful and 'xm pci-list-assignable-devices' returned nothing. But I've got this working some weeks before with 3.4.1-rc3 and a different PCIe ISDN-board but same mobo. Assigning the PCI to a XP hvm domU worked basically but caused a kernel panic ~30sec runtime of the hvm. Unfortunate I needed to return the PCIe ISDN-board and therefore I was not able to dig into this any further. Now I wanted to continue my tests with the current Xen sources BUT an older ISDN board (same vendor but _without_ PLX PCIe-PCI bridge). BTW I read somewhere that Vt-d with Q35 only might work with PCIe devices!?!

Nevertheless I will try to collect the PCIe ISDN-board from my colleague to use the same hardware setup as before and recheck my config...

Best regards
Ralf


 
-----Original Message-----
From: Ross Philipson [mailto:Ross.Philipson@citrix.com] 
Sent: Montag, 17. August 2009 16:58
To: Bonenkamp, Ralf; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

The message will remain regardless of whether you set iommu_inclusive_mapping or not. The parameter is there to work around the underlying issue but the issue is not actually corrected. So the code that generates the message (which is detecting discrepancies between the e820 map and the DMAR RMRR values) will continue to report this even though you used the parameter. The real question is whether you are experiencing some other problems beyond the warning message - like a boot hang?

Thanks
Ross

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 10:46 AM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

RE: Vt-d not working with 3.4.1

[Ross Philipson]

> The interesting point is now that my system booted up fine with AND without iommu_inclusive_mapping=1!

Right, the discrepancies between the RMRRs and memory map may or may not cause problems. The check which generates the message can only detect certain cases and cannot determine whether it will actually cause a problem. When there is a problem it is usually related to video card not having certain physical ranges identity mapped into dom0 - this leads to a hang while dom0 is starting up. Glad to hear that you are not having hangs.

Thanks
Ross

-----Original Message-----
From: Bonenkamp, Ralf [mailto:ralf.bonenkamp@swyx.com] 
Sent: Monday, August 17, 2009 11:20 AM
To: xen-devel@lists.xensource.com
Cc: Ross Philipson
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Ross,

thanks for this clarification! I misinterpreted the iommu_inclusive_mapping=1 thing in the way that this would prevent the log message ;-)
The interesting point is now that my system booted up fine with AND without iommu_inclusive_mapping=1!

In both cases hiding a PCI device via pciback.hide at boot time using a grub entry was not successful and 'xm pci-list-assignable-devices' returned nothing. But I've got this working some weeks before with 3.4.1-rc3 and a different PCIe ISDN-board but same mobo. Assigning the PCI to a XP hvm domU worked basically but caused a kernel panic ~30sec runtime of the hvm. Unfortunate I needed to return the PCIe ISDN-board and therefore I was not able to dig into this any further. Now I wanted to continue my tests with the current Xen sources BUT an older ISDN board (same vendor but _without_ PLX PCIe-PCI bridge). BTW I read somewhere that Vt-d with Q35 only might work with PCIe devices!?!

Nevertheless I will try to collect the PCIe ISDN-board from my colleague to use the same hardware setup as before and recheck my config...

Best regards
Ralf


 
-----Original Message-----
From: Ross Philipson [mailto:Ross.Philipson@citrix.com] 
Sent: Montag, 17. August 2009 16:58
To: Bonenkamp, Ralf; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

The message will remain regardless of whether you set iommu_inclusive_mapping or not. The parameter is there to work around the underlying issue but the issue is not actually corrected. So the code that generates the message (which is detecting discrepancies between the e820 map and the DMAR RMRR values) will continue to report this even though you used the parameter. The real question is whether you are experiencing some other problems beyond the warning message - like a boot hang?

Thanks
Ross

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 10:46 AM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

How about Intel Q45 chipset?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 11:20 PM
To: xen-devel@lists.xensource.com
Cc: Ross Philipson
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Ross,

thanks for this clarification! I misinterpreted the
iommu_inclusive_mapping=1 thing in the way that this would prevent the log
message ;-)
The interesting point is now that my system booted up fine with AND without
iommu_inclusive_mapping=1!

In both cases hiding a PCI device via pciback.hide at boot time using a grub
entry was not successful and 'xm pci-list-assignable-devices' returned
nothing. But I've got this working some weeks before with 3.4.1-rc3 and a
different PCIe ISDN-board but same mobo. Assigning the PCI to a XP hvm domU
worked basically but caused a kernel panic ~30sec runtime of the hvm.
Unfortunate I needed to return the PCIe ISDN-board and therefore I was not
able to dig into this any further. Now I wanted to continue my tests with
the current Xen sources BUT an older ISDN board (same vendor but _without_
PLX PCIe-PCI bridge). BTW I read somewhere that Vt-d with Q35 only might
work with PCIe devices!?!

Nevertheless I will try to collect the PCIe ISDN-board from my colleague to
use the same hardware setup as before and recheck my config...

Best regards
Ralf


 
-----Original Message-----
From: Ross Philipson [mailto:Ross.Philipson@citrix.com] 
Sent: Montag, 17. August 2009 16:58
To: Bonenkamp, Ralf; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

The message will remain regardless of whether you set
iommu_inclusive_mapping or not. The parameter is there to work around the
underlying issue but the issue is not actually corrected. So the code that
generates the message (which is detecting discrepancies between the e820 map
and the DMAR RMRR values) will continue to report this even though you used
the parameter. The real question is whether you are experiencing some other
problems beyond the warning message - like a boot hang?

Thanks
Ross

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 10:46 AM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the
iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output
from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was
the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

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

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/18/09
18:05:00

RE: Vt-d not working with 3.4.1

[Han, Weidong]

Yes, we usually observed that the iommu fault on bdf 00:02.0 is harmless. What problem of VT-d did you find? Dom0 hang? Cannot passthrough device?

Regards,
Weidong

Ross Philipson wrote:
> The message will remain regardless of whether you set
> iommu_inclusive_mapping or not. The parameter is there to work around
> the underlying issue but the issue is not actually corrected. So the
> code that generates the message (which is detecting discrepancies
> between the e820 map and the DMAR RMRR values) will continue to
> report this even though you used the parameter. The real question is
> whether you are experiencing some other problems beyond the warning
> message - like a boot hang?       
> 
> Thanks
> Ross
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
> Bonenkamp, Ralf  
> Sent: Monday, August 17, 2009 10:46 AM
> To: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
> 
> Hi Pasi,
> 
> Sorry - I forgot to mention that I've tried setting the
> iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the
> output from a previous attempt without this parameter.  
> 
> The xm dmesg output and the DMAR parsing error remains the same. This
> was the reason posting, because I ran out of ideas... 
> 
> Best regards
> Ralf Bonenkamp
> 
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> Sent: Montag, 17. August 2009 16:32
> To: Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
> 
> On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
>> Hi folks,
>> 
>> currently I try to setup a new xen host v3.4.1 on top of a Asus
>> P5E-VM DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate
>> my extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new
>> home. I want to switch over to 3.4.1 to (hopefully!) passthrough my
>> ISDN board to a HVM domU. Unfortunate there seem some issue with the
>> VT-d DMAR tables which is beyond my knowledge and probably someone
>> has some hint how to proceed? :-) 
>> 
> 
> Well did you try iommu_inclusive_mapping=1, like it suggests ?
> 
>> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory
>> base = 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter
>> may be needed. (XEN) Intel VT-d DMAR tables have been parsed.
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

Dear Ralf,

I am also working on VT-d on Intel Desktop Board DQ45CB. We could share our
findings with each other.

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Bonenkamp, Ralf
Sent: Monday, August 17, 2009 10:46 PM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi Pasi,

Sorry - I forgot to mention that I've tried setting the
iommu_inclusive_mapping=1 parameter too, but unfortunate I posted the output
from a previous attempt without this parameter.

The xm dmesg output and the DMAR parsing error remains the same. This was
the reason posting, because I ran out of ideas...

Best regards
Ralf Bonenkamp

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Montag, 17. August 2009 16:32
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/18/09
18:05:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

Hi,

Is it not sufficient to parse iommu=1 only?

kernel /xen.gz iommu=1

We should also add iommu_inclusive_mapping=1?

So it becomes

kernel /xen.gz iommu=1 iommu_inclusive_mapping=1

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi Kärkkäinen
Sent: Monday, August 17, 2009 10:32 PM
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

RE: Vt-d not working with 3.4.1

[Bonenkamp, Ralf]

Dear Teo,

I tried all combinations
- kernel /xen.gz iommu=1
- kernel /xen.gz iommu_inclusive_mapping=1
- kernel /xen.gz iommu=1 iommu_inclusive_mapping=1

And got the same result at xm dmesg on my mobo ;-)

I noticed that there is another switch mentioned named 'vtd=1' in some postings. The wiki at http://wiki.xensource.com/xenwiki/VTdHowTo does not mention any of those switches. Hopefully I can spare time in the next days to sort this switches out and prepare some sort of beginners guide to this topic...

Regards,
Ralf


-----Original Message-----
From: Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net] 
Sent: Mittwoch, 19. August 2009 04:44
To: pasik@iki.fi; Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Hi,

Is it not sufficient to parse iommu=1 only?

kernel /xen.gz iommu=1

We should also add iommu_inclusive_mapping=1?

So it becomes

kernel /xen.gz iommu=1 iommu_inclusive_mapping=1

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi Kärkkäinen
Sent: Monday, August 17, 2009 10:32 PM
To: Bonenkamp, Ralf
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
> Hi folks,
> 
> currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM
> DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my
> extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I
> want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board
> to a HVM domU.
> Unfortunate there seem some issue with the VT-d DMAR tables which is
> beyond my knowledge and probably someone has some hint how to proceed?
> :-)
>

Well did you try iommu_inclusive_mapping=1, like it suggests ?
 
> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory base =
> 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter may be
> needed.
> (XEN) Intel VT-d DMAR tables have been parsed.

-- Pasi

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

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09
18:19:00

RE: Vt-d not working with 3.4.1

[Han, Weidong]

'vtd=1' is old parameter to enable VT-d. It's replaced by 'iommu' parameter for a long time. The 'iommu=' parameter values are as follows:

 *   off|no|false|disable   Disable IOMMU (default)
 *   pv                         	Enable IOMMU for PV domains
 *   no-pv                   	Disable IOMMU for PV domains (default)
 *   force|required         	Don't boot unless IOMMU is enabled
 *   passthrough            	Enable VT-d DMA passthrough (no DMA translation for Dom0)
 *   no-snoop                	Disable VT-d Snoop Control
 *   no-qinval                 	Disable VT-d Queued Invalidation
 *   no-intremap             Disable VT-d Interrupt Remapping

Usually, you just need 'iommu=1' to enable IOMMU. When IOMMU is enabled, most of VT-d features (snoop control, queued invalidation and interrupt remapping) are enabled by default if they are available. 

When RMRR address range is not in reserved memory (BIOS issue), can use 'iommu_inclusive_mapping=1' to work around it.

Regards,
Weidong

Bonenkamp, Ralf wrote:
> Dear Teo,
> 
> I tried all combinations
> - kernel /xen.gz iommu=1
> - kernel /xen.gz iommu_inclusive_mapping=1
> - kernel /xen.gz iommu=1 iommu_inclusive_mapping=1
> 
> And got the same result at xm dmesg on my mobo ;-)
> 
> I noticed that there is another switch mentioned named 'vtd=1' in
> some postings. The wiki at http://wiki.xensource.com/xenwiki/VTdHowTo
> does not mention any of those switches. Hopefully I can spare time in
> the next days to sort this switches out and prepare some sort of
> beginners guide to this topic...    
> 
> Regards,
> Ralf
> 
> 
> -----Original Message-----
> From: Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
> Sent: Mittwoch, 19. August 2009 04:44
> To: pasik@iki.fi; Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
> 
> Hi,
> 
> Is it not sufficient to parse iommu=1 only?
> 
> kernel /xen.gz iommu=1
> 
> We should also add iommu_inclusive_mapping=1?
> 
> So it becomes
> 
> kernel /xen.gz iommu=1 iommu_inclusive_mapping=1
> 
> Regards,
> 
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi
> Kärkkäinen 
> Sent: Monday, August 17, 2009 10:32 PM
> To: Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
> 
> On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
>> Hi folks,
>> 
>> currently I try to setup a new xen host v3.4.1 on top of a Asus
>> P5E-VM DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate
>> my extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new
>> home. I want to switch over to 3.4.1 to (hopefully!) passthrough my
>> ISDN board to a HVM domU. Unfortunate there seem some issue with the
>> VT-d DMAR tables which is beyond my knowledge and probably someone
>> has some hint how to proceed? :-) 
>> 
> 
> Well did you try iommu_inclusive_mapping=1, like it suggests ?
> 
>> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory
>> base = 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter
>> may be needed. (XEN) Intel VT-d DMAR tables have been parsed.
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date:
> 08/10/09 18:19:00
> 
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date:
> 08/10/09 18:19:00
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

Hi,

My hardware configuration is as follows:

Intel Desktop Board DQ45CB
BIOS Flashed from version 0063 to 0093
Intel Pentium Dual Core E6300
PCI Express x16 Graphics card NVIDIA chipset
8 GB DDR2-800

My software configuration is as follows:

Fedora 11 64-bit host operating system
Jeremy's pv-ops dom0 kernel 2.6.30 rc3 and 2.6.31 rc6
Xen 3.4.1 testing

When I tried to download and compile Jeremy's pv-ops dom0 kernel, bzImage
kernel image is compiled successfully for both 2.6.30 rc3 and 2.6.31 rc6.

However, when I tried to boot using bzImage kernel image, it complains of a
kernel panic on CPU0.

(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_init: not an ELF binary

I googled around and saw a posting saying to use vmlinux kernel image and
not the bzImage kernel image.

So I tried to use vmlinux in arch/x86/boot/compressed to boot but it did not
work.

Not disheartened, I proceeded to try vmlinux.bin as my kernel image.

Now I can successfully boot up the Xen Dom 0 pv-ops kernel, I can see Domain
0 using "xm list" and I can see the Ethernet bridge created and I can also
surf the internet using a text based browser.

However, I cannot start X server. It crashed. The system complains about
some libraries.

Any idea what goes wrong?


Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Han, Weidong
Sent: Wednesday, August 19, 2009 3:24 PM
To: 'Bonenkamp, Ralf'; 'xen-devel@lists.xensource.com'
Cc: 'enming.teo@asiasoftsea.net'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

'vtd=1' is old parameter to enable VT-d. It's replaced by 'iommu' parameter
for a long time. The 'iommu=' parameter values are as follows:

 *   off|no|false|disable   Disable IOMMU (default)
 *   pv                         	Enable IOMMU for PV domains
 *   no-pv                   	Disable IOMMU for PV domains (default)
 *   force|required         	Don't boot unless IOMMU is enabled
 *   passthrough            	Enable VT-d DMA passthrough (no DMA
translation for Dom0)
 *   no-snoop                	Disable VT-d Snoop Control
 *   no-qinval                 	Disable VT-d Queued Invalidation
 *   no-intremap             Disable VT-d Interrupt Remapping

Usually, you just need 'iommu=1' to enable IOMMU. When IOMMU is enabled,
most of VT-d features (snoop control, queued invalidation and interrupt
remapping) are enabled by default if they are available. 

When RMRR address range is not in reserved memory (BIOS issue), can use
'iommu_inclusive_mapping=1' to work around it.

Regards,
Weidong

Bonenkamp, Ralf wrote:
> Dear Teo,
> 
> I tried all combinations
> - kernel /xen.gz iommu=1
> - kernel /xen.gz iommu_inclusive_mapping=1
> - kernel /xen.gz iommu=1 iommu_inclusive_mapping=1
> 
> And got the same result at xm dmesg on my mobo ;-)
> 
> I noticed that there is another switch mentioned named 'vtd=1' in
> some postings. The wiki at http://wiki.xensource.com/xenwiki/VTdHowTo
> does not mention any of those switches. Hopefully I can spare time in
> the next days to sort this switches out and prepare some sort of
> beginners guide to this topic...    
> 
> Regards,
> Ralf
> 
> 
> -----Original Message-----
> From: Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
> Sent: Mittwoch, 19. August 2009 04:44
> To: pasik@iki.fi; Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
> 
> Hi,
> 
> Is it not sufficient to parse iommu=1 only?
> 
> kernel /xen.gz iommu=1
> 
> We should also add iommu_inclusive_mapping=1?
> 
> So it becomes
> 
> kernel /xen.gz iommu=1 iommu_inclusive_mapping=1
> 
> Regards,
> 
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi
> Kärkkäinen 
> Sent: Monday, August 17, 2009 10:32 PM
> To: Bonenkamp, Ralf
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
> 
> On Sat, Aug 08, 2009 at 11:53:23PM +0200, Bonenkamp, Ralf wrote:
>> Hi folks,
>> 
>> currently I try to setup a new xen host v3.4.1 on top of a Asus
>> P5E-VM DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate
>> my extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new
>> home. I want to switch over to 3.4.1 to (hopefully!) passthrough my
>> ISDN board to a HVM domU. Unfortunate there seem some issue with the
>> VT-d DMAR tables which is beyond my knowledge and probably someone
>> has some hint how to proceed? :-) 
>> 
> 
> Well did you try iommu_inclusive_mapping=1, like it suggests ?
> 
>> (XEN) [VT-D]dmar.c:401: RMRR address range not in reserved memory
>> base = 7d600000 end = 7dffffff; iommu_inclusive_mapping=1 parameter
>> may be needed. (XEN) Intel VT-d DMAR tables have been parsed.
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date:
> 08/10/09 18:19:00
> 
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date:
> 08/10/09 18:19:00
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 05:10:47PM +0800, Teo En Ming (Zhang Enming) wrote:
> Hi,
> 
> My hardware configuration is as follows:
> 
> Intel Desktop Board DQ45CB
> BIOS Flashed from version 0063 to 0093
> Intel Pentium Dual Core E6300
> PCI Express x16 Graphics card NVIDIA chipset
> 8 GB DDR2-800
> 
> My software configuration is as follows:
> 
> Fedora 11 64-bit host operating system
> Jeremy's pv-ops dom0 kernel 2.6.30 rc3 and 2.6.31 rc6
> Xen 3.4.1 testing
> 
> When I tried to download and compile Jeremy's pv-ops dom0 kernel, bzImage
> kernel image is compiled successfully for both 2.6.30 rc3 and 2.6.31 rc6.
> 
> However, when I tried to boot using bzImage kernel image, it complains of a
> kernel panic on CPU0.
> 
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) elf_init: not an ELF binary
> 
> I googled around and saw a posting saying to use vmlinux kernel image and
> not the bzImage kernel image.
> 

I'm using arch/x86/boot/bzImage from pv_ops dom0 kernel tree as dom0 kernel, 
and it works without problems.

Are you using LZMA compression for the kernel? Maybe that's the problem..

> So I tried to use vmlinux in arch/x86/boot/compressed to boot but it did not
> work.
> 

Earlier when Xen didn't support bzImage yet, I used "vmlinux" from the top
directory of kernel tree. It's huge, but you can gzip it to make it a bit
smaller.

Xen 3.4.x supports bzImage dom0 kernels.

> Not disheartened, I proceeded to try vmlinux.bin as my kernel image.
> 
> Now I can successfully boot up the Xen Dom 0 pv-ops kernel, I can see Domain
> 0 using "xm list" and I can see the Ethernet bridge created and I can also
> surf the internet using a text based browser.
> 
> However, I cannot start X server. It crashed. The system complains about
> some libraries.
> 
> Any idea what goes wrong?
> 

Read "dmesg" and X log.

-- Pasi

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

Dear Pasi,

I did a "readelf bzImage" command and it is not an ELF image. I even tried
to do a readelf command on the default kernel (without Xen) that ships with
Fedora 11 and it says not an ELF image too.

Strange. Default installing Fedora 11 kernel not ELF image?

When configuring the pv-ops dom 0 kernel, I always select bzip2 compression.

I also carried out the readelf command on vmlinux and vmlinux.bin in the
arch/x86/boot/compressed directory after compiling the kernel. Both files
reported as ELF 64-bit executable but using vmlinux will NOT boot. Only
using vmlinux.bin will boot.


Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Wednesday, August 19, 2009 5:27 PM
To: Teo En Ming (Zhang Enming)
Cc: weidong.han@intel.com; 'Bonenkamp, Ralf'; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

On Wed, Aug 19, 2009 at 05:10:47PM +0800, Teo En Ming (Zhang Enming) wrote:
> Hi,
> 
> My hardware configuration is as follows:
> 
> Intel Desktop Board DQ45CB
> BIOS Flashed from version 0063 to 0093
> Intel Pentium Dual Core E6300
> PCI Express x16 Graphics card NVIDIA chipset
> 8 GB DDR2-800
> 
> My software configuration is as follows:
> 
> Fedora 11 64-bit host operating system
> Jeremy's pv-ops dom0 kernel 2.6.30 rc3 and 2.6.31 rc6
> Xen 3.4.1 testing
> 
> When I tried to download and compile Jeremy's pv-ops dom0 kernel, bzImage
> kernel image is compiled successfully for both 2.6.30 rc3 and 2.6.31 rc6.
> 
> However, when I tried to boot using bzImage kernel image, it complains of
a
> kernel panic on CPU0.
> 
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) elf_init: not an ELF binary
> 
> I googled around and saw a posting saying to use vmlinux kernel image and
> not the bzImage kernel image.
> 

I'm using arch/x86/boot/bzImage from pv_ops dom0 kernel tree as dom0 kernel,

and it works without problems.

Are you using LZMA compression for the kernel? Maybe that's the problem..

> So I tried to use vmlinux in arch/x86/boot/compressed to boot but it did
not
> work.
> 

Earlier when Xen didn't support bzImage yet, I used "vmlinux" from the top
directory of kernel tree. It's huge, but you can gzip it to make it a bit
smaller.

Xen 3.4.x supports bzImage dom0 kernels.

> Not disheartened, I proceeded to try vmlinux.bin as my kernel image.
> 
> Now I can successfully boot up the Xen Dom 0 pv-ops kernel, I can see
Domain
> 0 using "xm list" and I can see the Ethernet bridge created and I can also
> surf the internet using a text based browser.
> 
> However, I cannot start X server. It crashed. The system complains about
> some libraries.
> 
> Any idea what goes wrong?
> 

Read "dmesg" and X log.

-- Pasi

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 05:45:53PM +0800, Teo En Ming (Zhang Enming) wrote:
> Dear Pasi,
> 
> I did a "readelf bzImage" command and it is not an ELF image. I even tried
> to do a readelf command on the default kernel (without Xen) that ships with
> Fedora 11 and it says not an ELF image too.
> 
> Strange. Default installing Fedora 11 kernel not ELF image?
> 

Maybe you need to do "bzcat kernel > kernel.elf && readelf kernel.elf".

> When configuring the pv-ops dom 0 kernel, I always select bzip2 compression.
> 
> I also carried out the readelf command on vmlinux and vmlinux.bin in the
> arch/x86/boot/compressed directory after compiling the kernel. Both files
> reported as ELF 64-bit executable but using vmlinux will NOT boot. Only
> using vmlinux.bin will boot.
> 

I was talking about the "vmlinux" from the top level directory, not from
arch/x86/boot/compressed.


Here is my grub.conf from my F11 dom0:

title Fedora Xen pv_ops dom0-test (2.6.31-rc6)
        root (hd0,0)
        kernel /xen.gz dom0_mem=1024M loglvl=all guest_loglvl=all
        module /vmlinuz-2.6.31-rc6 ro root=/dev/mapper/vg_dom0test-lv01
        module /initrd-2.6.31-rc6.img


Where "vmlinuz-2.6.31-rc6" is arch/x86/boot/bzImage.

-- Pasi

> 
> Regards,
>  
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering) 
> Technical Support Engineer 
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza 
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> 
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
> Sent: Wednesday, August 19, 2009 5:27 PM
> To: Teo En Ming (Zhang Enming)
> Cc: weidong.han@intel.com; 'Bonenkamp, Ralf'; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
> 
> On Wed, Aug 19, 2009 at 05:10:47PM +0800, Teo En Ming (Zhang Enming) wrote:
> > Hi,
> > 
> > My hardware configuration is as follows:
> > 
> > Intel Desktop Board DQ45CB
> > BIOS Flashed from version 0063 to 0093
> > Intel Pentium Dual Core E6300
> > PCI Express x16 Graphics card NVIDIA chipset
> > 8 GB DDR2-800
> > 
> > My software configuration is as follows:
> > 
> > Fedora 11 64-bit host operating system
> > Jeremy's pv-ops dom0 kernel 2.6.30 rc3 and 2.6.31 rc6
> > Xen 3.4.1 testing
> > 
> > When I tried to download and compile Jeremy's pv-ops dom0 kernel, bzImage
> > kernel image is compiled successfully for both 2.6.30 rc3 and 2.6.31 rc6.
> > 
> > However, when I tried to boot using bzImage kernel image, it complains of
> a
> > kernel panic on CPU0.
> > 
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) elf_init: not an ELF binary
> > 
> > I googled around and saw a posting saying to use vmlinux kernel image and
> > not the bzImage kernel image.
> > 
> 
> I'm using arch/x86/boot/bzImage from pv_ops dom0 kernel tree as dom0 kernel,
> 
> and it works without problems.
> 
> Are you using LZMA compression for the kernel? Maybe that's the problem..
> 
> > So I tried to use vmlinux in arch/x86/boot/compressed to boot but it did
> not
> > work.
> > 
> 
> Earlier when Xen didn't support bzImage yet, I used "vmlinux" from the top
> directory of kernel tree. It's huge, but you can gzip it to make it a bit
> smaller.
> 
> Xen 3.4.x supports bzImage dom0 kernels.
> 
> > Not disheartened, I proceeded to try vmlinux.bin as my kernel image.
> > 
> > Now I can successfully boot up the Xen Dom 0 pv-ops kernel, I can see
> Domain
> > 0 using "xm list" and I can see the Ethernet bridge created and I can also
> > surf the internet using a text based browser.
> > 
> > However, I cannot start X server. It crashed. The system complains about
> > some libraries.
> > 
> > Any idea what goes wrong?
> > 
> 
> Read "dmesg" and X log.
> 
> -- Pasi
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
> 18:05:00
> 
> No virus found in this outgoing message.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
> 18:05:00
> 
> 

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear Pasi,

I suspect that there may be some problems with the Xen 3.4.1 changeset of 6 August 2009.

The bzImage kernel image that I compiled is not a bzip2 file, hence I cannot bzcat it. If I tried to do so, it will complain that it is not a bzip2 file.

I did specify the following in my kernel configuration:

CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_KERNEL_BZIP2=y
CONFIG_RD_BZIP2=y
CONFIG_DECOMPRESS_BZIP2=y

When I do a "xm dmesg" command, I see the following output:

(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled

So can I confirm that I have VT-d support enabled?

I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are NOT ELF images.

Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 images.

However, vmlinux inside compressed cannot boot successfully.

Only vmlinux.bin inside compressed can boot successfully, and this is what I am using now.

Regarding X server (GUI) unable to start, I have a backtrace inside /var/log/Xorg.0.log.

It complains about Fatal Server error:
Caught signal 11. Server aborting.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 06:20 PM, Pasi Kärkkäinen wrote:
> On Wed, Aug 19, 2009 at 05:45:53PM +0800, Teo En Ming (Zhang Enming) wrote:
>    
>> Dear Pasi,
>>
>> I did a "readelf bzImage" command and it is not an ELF image. I even tried
>> to do a readelf command on the default kernel (without Xen) that ships with
>> Fedora 11 and it says not an ELF image too.
>>
>> Strange. Default installing Fedora 11 kernel not ELF image?
>>
>>      
> Maybe you need to do "bzcat kernel>  kernel.elf&&  readelf kernel.elf".
>
>    
>> When configuring the pv-ops dom 0 kernel, I always select bzip2 compression.
>>
>> I also carried out the readelf command on vmlinux and vmlinux.bin in the
>> arch/x86/boot/compressed directory after compiling the kernel. Both files
>> reported as ELF 64-bit executable but using vmlinux will NOT boot. Only
>> using vmlinux.bin will boot.
>>
>>      
> I was talking about the "vmlinux" from the top level directory, not from
> arch/x86/boot/compressed.
>
>
> Here is my grub.conf from my F11 dom0:
>
> title Fedora Xen pv_ops dom0-test (2.6.31-rc6)
>          root (hd0,0)
>          kernel /xen.gz dom0_mem=1024M loglvl=all guest_loglvl=all
>          module /vmlinuz-2.6.31-rc6 ro root=/dev/mapper/vg_dom0test-lv01
>          module /initrd-2.6.31-rc6.img
>
>
> Where "vmlinuz-2.6.31-rc6" is arch/x86/boot/bzImage.
>
> -- Pasi
>
>    
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>>
>> -----Original Message-----
>> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
>> Sent: Wednesday, August 19, 2009 5:27 PM
>> To: Teo En Ming (Zhang Enming)
>> Cc: weidong.han@intel.com; 'Bonenkamp, Ralf'; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
>>
>> On Wed, Aug 19, 2009 at 05:10:47PM +0800, Teo En Ming (Zhang Enming) wrote:
>>      
>>> Hi,
>>>
>>> My hardware configuration is as follows:
>>>
>>> Intel Desktop Board DQ45CB
>>> BIOS Flashed from version 0063 to 0093
>>> Intel Pentium Dual Core E6300
>>> PCI Express x16 Graphics card NVIDIA chipset
>>> 8 GB DDR2-800
>>>
>>> My software configuration is as follows:
>>>
>>> Fedora 11 64-bit host operating system
>>> Jeremy's pv-ops dom0 kernel 2.6.30 rc3 and 2.6.31 rc6
>>> Xen 3.4.1 testing
>>>
>>> When I tried to download and compile Jeremy's pv-ops dom0 kernel, bzImage
>>> kernel image is compiled successfully for both 2.6.30 rc3 and 2.6.31 rc6.
>>>
>>> However, when I tried to boot using bzImage kernel image, it complains of
>>>        
>> a
>>      
>>> kernel panic on CPU0.
>>>
>>> (XEN) *** LOADING DOMAIN 0 ***
>>> (XEN) elf_init: not an ELF binary
>>>
>>> I googled around and saw a posting saying to use vmlinux kernel image and
>>> not the bzImage kernel image.
>>>
>>>        
>> I'm using arch/x86/boot/bzImage from pv_ops dom0 kernel tree as dom0 kernel,
>>
>> and it works without problems.
>>
>> Are you using LZMA compression for the kernel? Maybe that's the problem..
>>
>>      
>>> So I tried to use vmlinux in arch/x86/boot/compressed to boot but it did
>>>        
>> not
>>      
>>> work.
>>>
>>>        
>> Earlier when Xen didn't support bzImage yet, I used "vmlinux" from the top
>> directory of kernel tree. It's huge, but you can gzip it to make it a bit
>> smaller.
>>
>> Xen 3.4.x supports bzImage dom0 kernels.
>>
>>      
>>> Not disheartened, I proceeded to try vmlinux.bin as my kernel image.
>>>
>>> Now I can successfully boot up the Xen Dom 0 pv-ops kernel, I can see
>>>        
>> Domain
>>      
>>> 0 using "xm list" and I can see the Ethernet bridge created and I can also
>>> surf the internet using a text based browser.
>>>
>>> However, I cannot start X server. It crashed. The system complains about
>>> some libraries.
>>>
>>> Any idea what goes wrong?
>>>
>>>        
>> Read "dmesg" and X log.
>>
>> -- Pasi
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
>> 18:05:00
>>
>> No virus found in this outgoing message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
>> 18:05:00
>>
>>
>>      
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Hi,

The specific details for the X server crash when booting Xen 3.4.1 dom 0 
pvops kernel are as follows:

[drm] failed to load kernel module "nouveau"
(EE) [drm] drmOpen failed.
(EE) NOUVEAU(0): [drm] error opening the drm
(!!) NOUVEAU(0): Failing back to NoAccel mode

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4e89b6]
1: /usr/bin/X(xf86SigHandler+0x6f) [0x47d63f]
2: /lib64/libc.so.6 [0x3cb4633370]
3: /usr/lib64/xorg/modules//libint10.so(x_outl+0x25) [0x7f1914133e15]
4: /usr/lib64/xorg/modules//libint10.so [0x7f191413a3d0]
5: /usr/lib64/xorg/modules//libint10.so(X86EMU_exec+0x81) [0x7f1914146e81]
6: /usr/lib64/xorg/modules//libint10.so(xf86ExecX86int10+0x55) 
[0x7f1914135585]
7: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x7f1914bff194]
8: /usr/bin/X(InitOutput+0x507) [0x467377]
9: /usr/bin/X(main+0x1fe) [0x42cf1e]
10: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3cb461ea2d]
11: /usr/bin/X [0x42c559]

Fatal server error:
Caught signal 11.  Server aborting

Do I have to update the X server and/or the C library?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 07:13 PM, Mr. Teo En Ming (Zhang Enming) wrote:
> Dear Pasi,
>
> I suspect that there may be some problems with the Xen 3.4.1 changeset 
> of 6 August 2009.
>
> The bzImage kernel image that I compiled is not a bzip2 file, hence I 
> cannot bzcat it. If I tried to do so, it will complain that it is not 
> a bzip2 file.
>
> I did specify the following in my kernel configuration:
>
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_KERNEL_BZIP2=y
> CONFIG_RD_BZIP2=y
> CONFIG_DECOMPRESS_BZIP2=y
>
> When I do a "xm dmesg" command, I see the following output:
>
> (XEN) Intel VT-d DMAR tables have been parsed.
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
>
> So can I confirm that I have VT-d support enabled?
>
> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
> NOT ELF images.
>
> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
> images.
>
> However, vmlinux inside compressed cannot boot successfully.
>
> Only vmlinux.bin inside compressed can boot successfully, and this is 
> what I am using now.
>
> Regarding X server (GUI) unable to start, I have a backtrace inside 
> /var/log/Xorg.0.log.
>
> It complains about Fatal Server error:
> Caught signal 11. Server aborting.
>

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Hi,

I think I know what's the problem with my X server crashes already.

Under the default Fedora 11 installation, the kernel module (driver) 
nouveau is loaded for my PCI Express x16 nvidia chipset graphics card.

However, after compiling Xen pv-ops dom 0 kernel 2.6.30 rc3 and 2.6.31 
rc6, the nouveau driver for my graphics card is no longer there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 07:39 PM, Mr. Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> The specific details for the X server crash when booting Xen 3.4.1 dom 
> 0 pvops kernel are as follows:
>
> [drm] failed to load kernel module "nouveau"
> (EE) [drm] drmOpen failed.
> (EE) NOUVEAU(0): [drm] error opening the drm
> (!!) NOUVEAU(0): Failing back to NoAccel mode
>
> Backtrace:
> 0: /usr/bin/X(xorg_backtrace+0x26) [0x4e89b6]
> 1: /usr/bin/X(xf86SigHandler+0x6f) [0x47d63f]
> 2: /lib64/libc.so.6 [0x3cb4633370]
> 3: /usr/lib64/xorg/modules//libint10.so(x_outl+0x25) [0x7f1914133e15]
> 4: /usr/lib64/xorg/modules//libint10.so [0x7f191413a3d0]
> 5: /usr/lib64/xorg/modules//libint10.so(X86EMU_exec+0x81) 
> [0x7f1914146e81]
> 6: /usr/lib64/xorg/modules//libint10.so(xf86ExecX86int10+0x55) 
> [0x7f1914135585]
> 7: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x7f1914bff194]
> 8: /usr/bin/X(InitOutput+0x507) [0x467377]
> 9: /usr/bin/X(main+0x1fe) [0x42cf1e]
> 10: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3cb461ea2d]
> 11: /usr/bin/X [0x42c559]
>
> Fatal server error:
> Caught signal 11.  Server aborting
>
> Do I have to update the X server and/or the C library?
>

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 08:30:45PM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
> Hi,
> 
> I think I know what's the problem with my X server crashes already.
> 
> Under the default Fedora 11 installation, the kernel module (driver) 
> nouveau is loaded for my PCI Express x16 nvidia chipset graphics card.
> 
> However, after compiling Xen pv-ops dom 0 kernel 2.6.30 rc3 and 2.6.31 
> rc6, the nouveau driver for my graphics card is no longer there.
> 

Yeah, fedora's kernel has additional drivers and fixes/patches, especially
for nouveau stuff.

-- Pasi


> -- 
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) 
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> Alma Maters: Singapore Polytechnic, National University of Singapore
> 
> 
> 
> On 08/19/2009 07:39 PM, Mr. Teo En Ming (Zhang Enming) wrote:
> >Hi,
> >
> >The specific details for the X server crash when booting Xen 3.4.1 dom 
> >0 pvops kernel are as follows:
> >
> >[drm] failed to load kernel module "nouveau"
> >(EE) [drm] drmOpen failed.
> >(EE) NOUVEAU(0): [drm] error opening the drm
> >(!!) NOUVEAU(0): Failing back to NoAccel mode
> >
> >Backtrace:
> >0: /usr/bin/X(xorg_backtrace+0x26) [0x4e89b6]
> >1: /usr/bin/X(xf86SigHandler+0x6f) [0x47d63f]
> >2: /lib64/libc.so.6 [0x3cb4633370]
> >3: /usr/lib64/xorg/modules//libint10.so(x_outl+0x25) [0x7f1914133e15]
> >4: /usr/lib64/xorg/modules//libint10.so [0x7f191413a3d0]
> >5: /usr/lib64/xorg/modules//libint10.so(X86EMU_exec+0x81) 
> >[0x7f1914146e81]
> >6: /usr/lib64/xorg/modules//libint10.so(xf86ExecX86int10+0x55) 
> >[0x7f1914135585]
> >7: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x7f1914bff194]
> >8: /usr/bin/X(InitOutput+0x507) [0x467377]
> >9: /usr/bin/X(main+0x1fe) [0x42cf1e]
> >10: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3cb461ea2d]
> >11: /usr/bin/X [0x42c559]
> >
> >Fatal server error:
> >Caught signal 11.  Server aborting
> >
> >Do I have to update the X server and/or the C library?
> >
> 
> 
> 

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear Pasi,

Is it possible to compile the open source nouveau drivers for nvidia 
graphics cards against the xen pv-ops dom 0 2.6.30-rc3 and 2.6.31-rc6 
jeremy's kernel?

http://nouveau.freedesktop.org/wiki/

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 08:34 PM, Pasi Kärkkäinen wrote:
> On Wed, Aug 19, 2009 at 08:30:45PM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
>    
>> Hi,
>>
>> I think I know what's the problem with my X server crashes already.
>>
>> Under the default Fedora 11 installation, the kernel module (driver)
>> nouveau is loaded for my PCI Express x16 nvidia chipset graphics card.
>>
>> However, after compiling Xen pv-ops dom 0 kernel 2.6.30 rc3 and 2.6.31
>> rc6, the nouveau driver for my graphics card is no longer there.
>>
>>      
> Yeah, fedora's kernel has additional drivers and fixes/patches, especially
> for nouveau stuff.
>
> -- Pasi
>
>
>    
>> -- 
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>> Alma Maters: Singapore Polytechnic, National University of Singapore
>>
>>
>>
>> On 08/19/2009 07:39 PM, Mr. Teo En Ming (Zhang Enming) wrote:
>>      
>>> Hi,
>>>
>>> The specific details for the X server crash when booting Xen 3.4.1 dom
>>> 0 pvops kernel are as follows:
>>>
>>> [drm] failed to load kernel module "nouveau"
>>> (EE) [drm] drmOpen failed.
>>> (EE) NOUVEAU(0): [drm] error opening the drm
>>> (!!) NOUVEAU(0): Failing back to NoAccel mode
>>>
>>> Backtrace:
>>> 0: /usr/bin/X(xorg_backtrace+0x26) [0x4e89b6]
>>> 1: /usr/bin/X(xf86SigHandler+0x6f) [0x47d63f]
>>> 2: /lib64/libc.so.6 [0x3cb4633370]
>>> 3: /usr/lib64/xorg/modules//libint10.so(x_outl+0x25) [0x7f1914133e15]
>>> 4: /usr/lib64/xorg/modules//libint10.so [0x7f191413a3d0]
>>> 5: /usr/lib64/xorg/modules//libint10.so(X86EMU_exec+0x81)
>>> [0x7f1914146e81]
>>> 6: /usr/lib64/xorg/modules//libint10.so(xf86ExecX86int10+0x55)
>>> [0x7f1914135585]
>>> 7: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x7f1914bff194]
>>> 8: /usr/bin/X(InitOutput+0x507) [0x467377]
>>> 9: /usr/bin/X(main+0x1fe) [0x42cf1e]
>>> 10: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3cb461ea2d]
>>> 11: /usr/bin/X [0x42c559]
>>>
>>> Fatal server error:
>>> Caught signal 11.  Server aborting
>>>
>>> Do I have to update the X server and/or the C library?
>>>
>>>        
>>
>>
>>      

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 07:13:50PM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
> Dear Pasi,
> 
> I suspect that there may be some problems with the Xen 3.4.1 changeset of 6 
> August 2009.
> 
> The bzImage kernel image that I compiled is not a bzip2 file, hence I 
> cannot bzcat it. If I tried to do so, it will complain that it is not a 
> bzip2 file.
> 

What does "file <kernel>" say?

> I did specify the following in my kernel configuration:
> 
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_KERNEL_BZIP2=y
> CONFIG_RD_BZIP2=y
> CONFIG_DECOMPRESS_BZIP2=y
> 
> When I do a "xm dmesg" command, I see the following output:
> 
> (XEN) Intel VT-d DMAR tables have been parsed.
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> 
> So can I confirm that I have VT-d support enabled?
> 
> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are NOT 
> ELF images.
>

Please run "file bzImage" and "file vmlinux.bin".
 
> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
> images.
> 
> However, vmlinux inside compressed cannot boot successfully.
> 

What's the error with that?

> Only vmlinux.bin inside compressed can boot successfully, and this is what 
> I am using now.
> 

Well good that something works..

> Regarding X server (GUI) unable to start, I have a backtrace inside 
> /var/log/Xorg.0.log.
> 
> It complains about Fatal Server error:
> Caught signal 11. Server aborting.
> 

Can you pastebin the backtrace? Or the whole x.org log.

-- Pasi

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear Pasi,

I went into arch/x86/boot:-

[root@fedora11-x86-64-host ~]# cd /usr/src/2.6.30-rc3-xen/arch/x86/boot/
[root@fedora11-x86-64-host boot]# file bzImage
bzImage: Linux kernel x86 boot executable bzImage, version 
2.6.30-rc3-enming.teo-tip (root, RO-rootFS, swap_dev 0x2, Normal VGA
[root@fedora11-x86-64-host boot]# file vmlinux.bin
vmlinux.bin: data

If I go into arch/x86/boot/compressed:-

[root@fedora11-x86-64-host compressed]# file vmlinux
vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
linked, not stripped
[root@fedora11-x86-64-host compressed]# file vmlinux.bin
vmlinux.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
statically linked, stripped

If I try to boot with vmlinux inside compressed (not stripped), I get 
the following error:

(XEN) elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or 
'__xen_guest' section found.

Panic on CPU 0:
Could not set up DOM0 guest OS

I can only boot Xen Dom 0 successfully with vmlinux.bin inside 
compressed directory (stripped).

So in summary,

I cannot boot with bzImage and vmlinux.bin inside arch/x86/boot. I also 
cannot boot with vmlinux inside arch/x86/boot/compressed. I can only 
boot Xen Dom 0 successfully with vmlinux.bin inside 
arch/x86/boot/compressed.

Hence I am wondering if there are any problems or bugs with the Xen 
3.4.1 changeset of 6 August 2009.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 08:32 PM, Pasi Kärkkäinen wrote:
> On Wed, Aug 19, 2009 at 07:13:50PM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
>    
>> Dear Pasi,
>>
>> I suspect that there may be some problems with the Xen 3.4.1 changeset of 6
>> August 2009.
>>
>> The bzImage kernel image that I compiled is not a bzip2 file, hence I
>> cannot bzcat it. If I tried to do so, it will complain that it is not a
>> bzip2 file.
>>
>>      
> What does "file<kernel>" say?
>
>    
>> I did specify the following in my kernel configuration:
>>
>> CONFIG_HAVE_KERNEL_BZIP2=y
>> CONFIG_KERNEL_BZIP2=y
>> CONFIG_RD_BZIP2=y
>> CONFIG_DECOMPRESS_BZIP2=y
>>
>> When I do a "xm dmesg" command, I see the following output:
>>
>> (XEN) Intel VT-d DMAR tables have been parsed.
>> (XEN) Intel VT-d Snoop Control not supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
>> (XEN) Intel VT-d Queued Invalidation not supported.
>> (XEN) Intel VT-d Interrupt Remapping not supported.
>> (XEN) I/O virtualisation enabled
>> (XEN) I/O virtualisation for PV guests disabled
>>
>> So can I confirm that I have VT-d support enabled?
>>
>> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are NOT
>> ELF images.
>>
>>      
> Please run "file bzImage" and "file vmlinux.bin".
>
>    
>> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64
>> images.
>>
>> However, vmlinux inside compressed cannot boot successfully.
>>
>>      
> What's the error with that?
>
>    
>> Only vmlinux.bin inside compressed can boot successfully, and this is what
>> I am using now.
>>
>>      
> Well good that something works..
>
>    
>> Regarding X server (GUI) unable to start, I have a backtrace inside
>> /var/log/Xorg.0.log.
>>
>> It complains about Fatal Server error:
>> Caught signal 11. Server aborting.
>>
>>      
> Can you pastebin the backtrace? Or the whole x.org log.
>
> -- Pasi
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

Re: Vt-d not working with 3.4.1

[Marc - A. Dahlhaus]

Mr. Teo En Ming (Zhang Enming) schrieb:
> Dear Pasi,
>
> I suspect that there may be some problems with the Xen 3.4.1 changeset 
> of 6 August 2009.
>
> The bzImage kernel image that I compiled is not a bzip2 file, hence I 
> cannot bzcat it. If I tried to do so, it will complain that it is not 
> a bzip2 file.
>
> I did specify the following in my kernel configuration:
>
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_KERNEL_BZIP2=y
> CONFIG_RD_BZIP2=y
> CONFIG_DECOMPRESS_BZIP2=y
>
> When I do a "xm dmesg" command, I see the following output:
>
> (XEN) Intel VT-d DMAR tables have been parsed.
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
>
> So can I confirm that I have VT-d support enabled?
>
> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
> NOT ELF images.
>
> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
> images.
>
> However, vmlinux inside compressed cannot boot successfully.
>
> Only vmlinux.bin inside compressed can boot successfully, and this is 
> what I am using now.
>
> Regarding X server (GUI) unable to start, I have a backtrace inside 
> /var/log/Xorg.0.log.
>
> It complains about Fatal Server error:
> Caught signal 11. Server aborting.
>
The bzImage has nothing to do with bzip2 compression and the current 
dom0 loader can only decode that CONFIG_KERNEL_GZIP based image.
Please change your config to use CONFIG_KERNEL_GZIP instead of 
CONFIG_KERNEL_BZIP2.

Marc

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear Marc,

I am aware that bzImage is not related to bzip2 compression at all. In 
fact bzImage stands for big zImage.

http://en.wikipedia.org/wiki/Vmlinux

In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
successfully. Why is it I am only able to use gzip now?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 08:45 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Pasi,
>>
>> I suspect that there may be some problems with the Xen 3.4.1 
>> changeset of 6 August 2009.
>>
>> The bzImage kernel image that I compiled is not a bzip2 file, hence I 
>> cannot bzcat it. If I tried to do so, it will complain that it is not 
>> a bzip2 file.
>>
>> I did specify the following in my kernel configuration:
>>
>> CONFIG_HAVE_KERNEL_BZIP2=y
>> CONFIG_KERNEL_BZIP2=y
>> CONFIG_RD_BZIP2=y
>> CONFIG_DECOMPRESS_BZIP2=y
>>
>> When I do a "xm dmesg" command, I see the following output:
>>
>> (XEN) Intel VT-d DMAR tables have been parsed.
>> (XEN) Intel VT-d Snoop Control not supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
>> (XEN) Intel VT-d Queued Invalidation not supported.
>> (XEN) Intel VT-d Interrupt Remapping not supported.
>> (XEN) I/O virtualisation enabled
>> (XEN) I/O virtualisation for PV guests disabled
>>
>> So can I confirm that I have VT-d support enabled?
>>
>> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
>> NOT ELF images.
>>
>> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are 
>> ELF64 images.
>>
>> However, vmlinux inside compressed cannot boot successfully.
>>
>> Only vmlinux.bin inside compressed can boot successfully, and this is 
>> what I am using now.
>>
>> Regarding X server (GUI) unable to start, I have a backtrace inside 
>> /var/log/Xorg.0.log.
>>
>> It complains about Fatal Server error:
>> Caught signal 11. Server aborting.
>>
> The bzImage has nothing to do with bzip2 compression and the current 
> dom0 loader can only decode that CONFIG_KERNEL_GZIP based image.
> Please change your config to use CONFIG_KERNEL_GZIP instead of 
> CONFIG_KERNEL_BZIP2.
>
> Marc
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Vt-d not working with 3.4.1

[Marc - A. Dahlhaus]

Mr. Teo En Ming (Zhang Enming) schrieb:
> Dear Marc,
>
> I am aware that bzImage is not related to bzip2 compression at all. In 
> fact bzImage stands for big zImage.
>
> http://en.wikipedia.org/wiki/Vmlinux
>
> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
> successfully. Why is it I am only able to use gzip now?
>
The dom0 builder only supports that as far as i know.

Marc

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Strange. I was able to use bzip2 compression for the Xen dom 0 pv-ops 
kernel and boot the Xen Dom 0 pv-ops kernel successfully in OpenSUSE 
11.1. But for Fedora 11 I can't. Very strange.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 09:09:56PM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
> Strange. I was able to use bzip2 compression for the Xen dom 0 pv-ops 
> kernel and boot the Xen Dom 0 pv-ops kernel successfully in OpenSUSE 
> 11.1. But for Fedora 11 I can't. Very strange.
>

Maybe there's a separate patch for this in OpenSUSE 11.1 Xen.

-- Pasi
 
> -- 
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) 
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> Alma Maters: Singapore Polytechnic, National University of Singapore
> 
> 
> 
> On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> >Mr. Teo En Ming (Zhang Enming) schrieb:
> >>Dear Marc,
> >>
> >>I am aware that bzImage is not related to bzip2 compression at all. 
> >>In fact bzImage stands for big zImage.
> >>
> >>http://en.wikipedia.org/wiki/Vmlinux
> >>
> >>In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
> >>successfully. Why is it I am only able to use gzip now?
> >>
> >The dom0 builder only supports that as far as i know.
> >
> >Marc
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

<QUOTE monz at nV News Forums>

The problem with video on Xen is that the driver needs to be Xen-aware.

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:49 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

<QUOTE drivesoslow>

I was able to get it to compile and install no problem finally, but it locks
up when I startx. I can compile it for non-XEN 64bit no problem. The non-XEN
kernel is significantly newer (2.6.23 vs 2.6.21)

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395

Same problem as what I am getting.

I am using the NVidia Geforce 8 series drivers for 64-bit.

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:52 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE monz at nV News Forums>

The problem with video on Xen is that the driver needs to be Xen-aware.

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:49 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

<QUOTE drivesoslow>

SOLVED!

It was a kernel issue. The current Fedora 8 XEN kernel was the issue. Since
there was not a newer one available I enabled the development repo and
installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
with the drive source and I have a working NVIDIA 169.07 driver. I assume
when the next kernel is release for Fedora 8 it will resolve this issue.

Was:
Code:

kernel-xen-2.6.21-2952.fc8
kernel-xen-devel-2.6.21-2952.fc8

Now:
Code:

kernel-xen-2.6.21.7-2892.fc9
kernel-xen-devel-2.6.21.7-2892.fc9

</QUOTE>


Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 9:10 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE drivesoslow>

I was able to get it to compile and install no problem finally, but it locks
up when I startx. I can compile it for non-XEN 64bit no problem. The non-XEN
kernel is significantly newer (2.6.23 vs 2.6.21)

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395

Same problem as what I am getting.

I am using the NVidia Geforce 8 series drivers for 64-bit.

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:52 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE monz at nV News Forums>

The problem with video on Xen is that the driver needs to be Xen-aware.

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:49 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

This certainly looks promising. No need to apply any patch to NVIDIA
graphics drivers for it to be Xen-aware.

Link: http://www.nvnews.net/vbulletin/showthread.php?t=122900

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 9:21 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE drivesoslow>

SOLVED!

It was a kernel issue. The current Fedora 8 XEN kernel was the issue. Since
there was not a newer one available I enabled the development repo and
installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
with the drive source and I have a working NVIDIA 169.07 driver. I assume
when the next kernel is release for Fedora 8 it will resolve this issue.

Was:
Code:

kernel-xen-2.6.21-2952.fc8
kernel-xen-devel-2.6.21-2952.fc8

Now:
Code:

kernel-xen-2.6.21.7-2892.fc9
kernel-xen-devel-2.6.21.7-2892.fc9

</QUOTE>


Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 9:10 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE drivesoslow>

I was able to get it to compile and install no problem finally, but it locks
up when I startx. I can compile it for non-XEN 64bit no problem. The non-XEN
kernel is significantly newer (2.6.23 vs 2.6.21)

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395

Same problem as what I am getting.

I am using the NVidia Geforce 8 series drivers for 64-bit.

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:52 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE monz at nV News Forums>

The problem with video on Xen is that the driver needs to be Xen-aware.

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:49 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

This certainly looks promising. No need to apply any patch to NVIDIA
graphics drivers for it to be Xen-aware.

Link: http://www.nvnews.net/vbulletin/showthread.php?t=122900

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 9:21 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE drivesoslow>

SOLVED!

It was a kernel issue. The current Fedora 8 XEN kernel was the issue. Since
there was not a newer one available I enabled the development repo and
installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
with the drive source and I have a working NVIDIA 169.07 driver. I assume
when the next kernel is release for Fedora 8 it will resolve this issue.

Was:
Code:

kernel-xen-2.6.21-2952.fc8
kernel-xen-devel-2.6.21-2952.fc8

Now:
Code:

kernel-xen-2.6.21.7-2892.fc9
kernel-xen-devel-2.6.21.7-2892.fc9

</QUOTE>


Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 9:10 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE drivesoslow>

I was able to get it to compile and install no problem finally, but it locks
up when I startx. I can compile it for non-XEN 64bit no problem. The non-XEN
kernel is significantly newer (2.6.23 vs 2.6.21)

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395

Same problem as what I am getting.

I am using the NVidia Geforce 8 series drivers for 64-bit.

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:52 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

<QUOTE monz at nV News Forums>

The problem with video on Xen is that the driver needs to be Xen-aware.

</QUOTE>

Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:49 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

Will the Xen patch for NVIDIA graphics drivers mentioned in the below
opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
below.

<CODE>

diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
--- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
+++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
@@ -42,8 +42,26 @@
 
 int nv_pat_enabled = 0;
 
+/*
+ * disable PAT support if XEN or PREEMPT_RT is configured in kernel
+ */
+
+#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
+
+/*
+ * you can re-enable PAT support for PREEMPT_RT when applying
+ * "nv_disable_pat=0" as kernel parameter for the sake of slightly
+ * better 3D performance but at the expense of higher latencies.
+ * if XEN is configured, then PAT support can't be enabled!
+ */
+
+#if !defined(CONFIG_XEN)
 NV_MODULE_PARAMETER(nv_disable_pat);
+#endif
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
 NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
--- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
@@ -226,7 +226,7 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user
that
  * they need to boost the size of their pool.
  */
-#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
+#if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32) && !defined(CONFIG_XEN)
 #define NV_SWIOTLB 1
 #endif
 
@@ -734,7 +734,10 @@
 #define NV_VM_INSERT_PAGE(vma, addr, page) \
     vm_insert_page(vma, addr, page)
 #endif
-#if defined(NV_REMAP_PFN_RANGE_PRESENT)
+#if defined(CONFIG_XEN)
+#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
+    io_remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
+#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
 #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
     remap_pfn_range(vma, from, ((offset) >> PAGE_SHIFT), x)
 #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
@@ -746,6 +749,9 @@
 #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
 #endif
 
+#if !defined(CONFIG_XEN)
+#define phys_to_machine(x) x
+#endif
 
 #define NV_PGD_OFFSET(address, kernel, mm)              \
    ({                                                   \
diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
--- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
@@ -352,6 +352,9 @@
 
 static void nv_flush_caches(void)
 {
+#if defined(CONFIG_PREEMPT_RT)
+    if(!nv_pat_enabled) return;
+#endif
 #if defined(KERNEL_2_4)
     // for 2.4 kernels, just automatically flush the caches and invalidate
tlbs
 #ifdef CONFIG_SMP
@@ -508,7 +511,7 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
-        page_ptr->dma_addr = page_ptr->phys_addr;
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
--- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
@@ -286,7 +286,7 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
-         page_ptr->dma_addr  = page_ptr->phys_addr;
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
     }
 
     return RM_OK;
diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
--- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
+++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
@@ -527,6 +527,7 @@
     MicroSeconds = MilliSeconds * 1000;
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
+#if !defined(CONFIG_XEN)
     NV_TIMERADD(&tm_aux, &tm_end, &tm_end);
 
     /* do we have a full jiffie to wait? */
@@ -564,6 +565,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

</CODE>

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 8:37 PM
To: enming.teo@asiasoftsea.net; mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: RE: [Xen-devel] Vt-d not working with 3.4.1

No wonder compiling official NVidia drivers against the Xen domain 0
paravirt operations kernel doesn't work. It causes my X server to show a
blank screen and freeze. NVidia drivers need to be patched for it to work
with Xen kernels.

http://en.opensuse.org/Use_Nvidia_driver_with_Xen

May I know where I can get the patch?

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Thursday, August 20, 2009 1:06 AM
To: mad@wol.de
Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

Dear All,

I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using 
gzip compression works. I can use the generated bzImage to boot up Domain 0.

If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2 
compression, you won't be able to boot up Domain 0 using the generated 
bzImage. You will get an ELF error and kernel panic on CPU 0.

As for X server, I haven't got much luck yet.

I was able to download and compile NVIDIA's kernel module directly from 
official NVIDIA website for Fedora 11 Default shipping kernel. I was 
able to start X server successfully and launch a desktop environment 
using nvidia.ko.

However, if I want to compile the nvidia kernel module against Xen dom 0 
pv_ops kernel sources, the kernel module compiles successfully, but when 
I start X, the screen becomes blank and the whole system freezes there.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/19/2009 09:06 PM, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
>> Dear Marc,
>>
>> I am aware that bzImage is not related to bzip2 compression at all. 
>> In fact bzImage stands for big zImage.
>>
>> http://en.wikipedia.org/wiki/Vmlinux
>>
>> In the past, I was able to use bzip2 for Xen kernel in OpenSUSE 11.1 
>> successfully. Why is it I am only able to use gzip now?
>>
> The dom0 builder only supports that as far as i know.
>
> Marc




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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2312 - Release Date: 08/18/09
18:05:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Dear All,

I followed the XEN - NVIDIA - STEP BY STEP instructions at nV news 
forums but I still couldn't get X to work under Xen pv-ops domain 0 
kernel. It still shows me a freezed blank screen. I couldn't switch to 
any tty (1 to 7 inclusive).

Here are the scenarios I have tried:

1)     IGNORE_XEN_PRESENCE=y ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run

2)     IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT 
-DNV_SIGNAL_STRUCT_RLIM" ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run

3)

./NVIDIA-Linux-x86_64-185.18.31-pkg2.run --extract-only

cd usr/src/nv

IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT 
-DNV_SIGNAL_STRUCT_RLIM" make 
SYSSRC=/usr/src/kernels/2.6.30-rc3-enming.teo-tip module

cp nvidia.ko /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video

cd /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video

depmod -a

rmmod nvidia

lsmod | grep nvidia

modprobe nvidia

lsmod | grep nvidia

None of the above three scenarios I have attempted worked for me.

When I tried to load the newly compiled nvidia driver (against the Xen 
Domain 0 paravirt operations kernel), it gives me the following message:

NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 
17:52:27 PDT 2009

NVRM: PAT configuration unsupported, falling back to MTRRs.

Any more ideas?

My home PC configuration:

Intel Pentium processor E6300 LGA775
Intel Desktop Board DQ45CB
BIOS Version 0093
8 GB DDR2-800
NVIDIA Geforce 8400 GS 512 MB DDR2 PCI Express x16

Fedora 11 64-bit Host operating system
Xen hypervisor 3.4.1
Jeremy Fitzhardinge's pv-ops dom 0 Xen kernel 2.6.30-rc3 and 2.6.31-rc6
Default shipping X server
mesa-lib upgraded

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 12:23 AM, Teo En Ming (Zhang Enming) wrote:
> This certainly looks promising. No need to apply any patch to NVIDIA
> graphics drivers for it to be Xen-aware.
>
> Link: http://www.nvnews.net/vbulletin/showthread.php?t=122900
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 9:21 PM
> To: enming.teo@asiasoftsea.net; mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>
> <QUOTE drivesoslow>
>
> SOLVED!
>
> It was a kernel issue. The current Fedora 8 XEN kernel was the issue. Since
> there was not a newer one available I enabled the development repo and
> installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
> with the drive source and I have a working NVIDIA 169.07 driver. I assume
> when the next kernel is release for Fedora 8 it will resolve this issue.
>
> Was:
> Code:
>
> kernel-xen-2.6.21-2952.fc8
> kernel-xen-devel-2.6.21-2952.fc8
>
> Now:
> Code:
>
> kernel-xen-2.6.21.7-2892.fc9
> kernel-xen-devel-2.6.21.7-2892.fc9
>
> </QUOTE>
>
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 9:10 PM
> To: enming.teo@asiasoftsea.net; mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>
> <QUOTE drivesoslow>
>
> I was able to get it to compile and install no problem finally, but it locks
> up when I startx. I can compile it for non-XEN 64bit no problem. The non-XEN
> kernel is significantly newer (2.6.23 vs 2.6.21)
>
> </QUOTE>
>
> Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395
>
> Same problem as what I am getting.
>
> I am using the NVidia Geforce 8 series drivers for 64-bit.
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 8:52 PM
> To: enming.teo@asiasoftsea.net; mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>
> <QUOTE monz at nV News Forums>
>
> The problem with video on Xen is that the driver needs to be Xen-aware.
>
> </QUOTE>
>
> Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 8:49 PM
> To: enming.teo@asiasoftsea.net; mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>
> Will the Xen patch for NVIDIA graphics drivers mentioned in the below
> opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
> 2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
> below.
>
> <CODE>
>
> diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
> --- nv-1.0-9625/nv.c	2006-09-26 21:33:35.000000000 +0200
> +++ nv-1.0-9625-xenrt/nv.c	2006-10-03 01:15:42.000000000 +0200
> @@ -42,8 +42,26 @@
>
>   int nv_pat_enabled = 0;
>
> +/*
> + * disable PAT support if XEN or PREEMPT_RT is configured in kernel
> + */
> +
> +#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
> +static int nv_disable_pat = 1;
> +#else
>   static int nv_disable_pat = 0;
> +#endif
> +
> +/*
> + * you can re-enable PAT support for PREEMPT_RT when applying
> + * "nv_disable_pat=0" as kernel parameter for the sake of slightly
> + * better 3D performance but at the expense of higher latencies.
> + * if XEN is configured, then PAT support can't be enabled!
> + */
> +
> +#if !defined(CONFIG_XEN)
>   NV_MODULE_PARAMETER(nv_disable_pat);
> +#endif
>
>   #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
>   NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
> diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
> --- nv-1.0-9625/nv-linux.h	2006-09-26 21:33:37.000000000 +0200
> +++ nv-1.0-9625-xenrt/nv-linux.h	2006-10-03 01:15:42.000000000 +0200
> @@ -226,7 +226,7 @@
>    * tiny, and the kernel panics when it is exhausted. try to warn the user
> that
>    * they need to boost the size of their pool.
>    */
> -#if defined(CONFIG_SWIOTLB)&&  !defined(GFP_DMA32)
> +#if defined(CONFIG_SWIOTLB)&&  !defined(GFP_DMA32)&&  !defined(CONFIG_XEN)
>   #define NV_SWIOTLB 1
>   #endif
>
> @@ -734,7 +734,10 @@
>   #define NV_VM_INSERT_PAGE(vma, addr, page) \
>       vm_insert_page(vma, addr, page)
>   #endif
> -#if defined(NV_REMAP_PFN_RANGE_PRESENT)
> +#if defined(CONFIG_XEN)
> +#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
> +    io_remap_pfn_range(vma, from, ((offset)>>  PAGE_SHIFT), x)
> +#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
>   #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
>       remap_pfn_range(vma, from, ((offset)>>  PAGE_SHIFT), x)
>   #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
> @@ -746,6 +749,9 @@
>   #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
>   #endif
>
> +#if !defined(CONFIG_XEN)
> +#define phys_to_machine(x) x
> +#endif
>
>   #define NV_PGD_OFFSET(address, kernel, mm)              \
>      ({                                                   \
> diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
> --- nv-1.0-9625/nv-vm.c	2006-09-26 21:33:37.000000000 +0200
> +++ nv-1.0-9625-xenrt/nv-vm.c	2006-10-03 01:24:31.000000000 +0200
> @@ -352,6 +352,9 @@
>
>   static void nv_flush_caches(void)
>   {
> +#if defined(CONFIG_PREEMPT_RT)
> +    if(!nv_pat_enabled) return;
> +#endif
>   #if defined(KERNEL_2_4)
>       // for 2.4 kernels, just automatically flush the caches and invalidate
> tlbs
>   #ifdef CONFIG_SMP
> @@ -508,7 +511,7 @@
>           page_ptr->phys_addr = phys_addr;
>           page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
>           page_ptr->virt_addr = virt_addr;
> -        page_ptr->dma_addr = page_ptr->phys_addr;
> +        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
>
>           /* lock the page for dma purposes */
>           nv_lock_page(page_ptr);
> diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
> --- nv-1.0-9625/os-agp.c	2006-09-26 21:33:37.000000000 +0200
> +++ nv-1.0-9625-xenrt/os-agp.c	2006-10-03 01:15:42.000000000 +0200
> @@ -286,7 +286,7 @@
>
>            page_ptr->phys_addr = (ptr->memory[i]&  PAGE_MASK);
>            page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
> -         page_ptr->dma_addr  = page_ptr->phys_addr;
> +         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
>       }
>
>       return RM_OK;
> diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
> --- nv-1.0-9625/os-interface.c	2006-09-26 21:33:37.000000000 +0200
> +++ nv-1.0-9625-xenrt/os-interface.c	2006-10-03 01:15:42.000000000 +0200
> @@ -527,6 +527,7 @@
>       MicroSeconds = MilliSeconds * 1000;
>       tm_end.tv_usec = MicroSeconds;
>       tm_end.tv_sec = 0;
> +#if !defined(CONFIG_XEN)
>       NV_TIMERADD(&tm_aux,&tm_end,&tm_end);
>
>       /* do we have a full jiffie to wait? */
> @@ -564,6 +565,7 @@
>                   MicroSeconds = 0;
>           } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
>       }
> +#endif
>
>       if (MicroSeconds>  1000)
>       {
>
> </CODE>
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 8:37 PM
> To: enming.teo@asiasoftsea.net; mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>
> No wonder compiling official NVidia drivers against the Xen domain 0
> paravirt operations kernel doesn't work. It causes my X server to show a
> blank screen and freeze. NVidia drivers need to be patched for it to work
> with Xen kernels.
>
> http://en.opensuse.org/Use_Nvidia_driver_with_Xen
>
> May I know where I can get the patch?
>
> Regards,
>
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
> (Zhang Enming)
> Sent: Thursday, August 20, 2009 1:06 AM
> To: mad@wol.de
> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
>
> Dear All,
>
> I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using
> gzip compression works. I can use the generated bzImage to boot up Domain 0.
>
> If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2
> compression, you won't be able to boot up Domain 0 using the generated
> bzImage. You will get an ELF error and kernel panic on CPU 0.
>
> As for X server, I haven't got much luck yet.
>
> I was able to download and compile NVIDIA's kernel module directly from
> official NVIDIA website for Fedora 11 Default shipping kernel. I was
> able to start X server successfully and launch a desktop environment
> using nvidia.ko.
>
> However, if I want to compile the nvidia kernel module against Xen dom 0
> pv_ops kernel sources, the kernel module compiles successfully, but when
> I start X, the screen becomes blank and the whole system freezes there.
>
>    

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Hi,

I saw this posting by Boris.

http://article.gmane.org/gmane.comp.emulators.xen.devel/61143

Perhaps the Xen dom 0 pvops kernel I am using is too new (2.6.30-rc3), 
and the NVIDIA driver I am using does not support it.

-- 

Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 12:41 AM, Mr. Teo En Ming (Zhang Enming) wrote:
> Dear All,
>
> I followed the XEN - NVIDIA - STEP BY STEP instructions at nV news 
> forums but I still couldn't get X to work under Xen pv-ops domain 0 
> kernel. It still shows me a freezed blank screen. I couldn't switch to 
> any tty (1 to 7 inclusive).
>
> Here are the scenarios I have tried:
>
> 1)     IGNORE_XEN_PRESENCE=y ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>
> 2)     IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT 
> -DNV_SIGNAL_STRUCT_RLIM" ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>
> 3)
>
> ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run --extract-only
>
> cd usr/src/nv
>
> IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT 
> -DNV_SIGNAL_STRUCT_RLIM" make 
> SYSSRC=/usr/src/kernels/2.6.30-rc3-enming.teo-tip module
>
> cp nvidia.ko /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>
> cd /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>
> depmod -a
>
> rmmod nvidia
>
> lsmod | grep nvidia
>
> modprobe nvidia
>
> lsmod | grep nvidia
>
> None of the above three scenarios I have attempted worked for me.
>
> When I tried to load the newly compiled nvidia driver (against the Xen 
> Domain 0 paravirt operations kernel), it gives me the following message:
>
> NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 
> 17:52:27 PDT 2009
>
> NVRM: PAT configuration unsupported, falling back to MTRRs.
>
> Any more ideas?
>
> My home PC configuration:
>
> Intel Pentium processor E6300 LGA775
> Intel Desktop Board DQ45CB
> BIOS Version 0093
> 8 GB DDR2-800
> NVIDIA Geforce 8400 GS 512 MB DDR2 PCI Express x16
>
> Fedora 11 64-bit Host operating system
> Xen hypervisor 3.4.1
> Jeremy Fitzhardinge's pv-ops dom 0 Xen kernel 2.6.30-rc3 and 2.6.31-rc6
> Default shipping X server
> mesa-lib upgraded
>

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

[-- Attachment #1.1: Type: text/plain, Size: 2326 bytes --]

Hi All,

I saw this posting by jam834 on nvidia forums:

http://forums.nvidia.com/index.php?showtopic=82229&view=findpost&p=471582

<QUOTE jam834>
I've fixed my problem. It was a conflict with the nvidia kernel module 
and the Myrinet 10G ethernet card module where they were trying to 
enable write-combining on two different PAT indexes (whatever that means).

 From myrinet's documentation:
QUOTE
If you are using another vendor's driver which also sets up PAT write
combining, and that vendor's driver uses a different PAT index than
our driver, the other vendor's driver may note a conflict and run in
reduced performance mode. Examples of other drivers which use PAT
include the Nvidia graphics driver, and various Infiniband drivers.

One way to work around this PAT conflict is to change the PAT index
used by the Myri10GE driver by rebooting, and loading the module using
the myri10ge_pat_idx modparam to specify a different PAT index. We
currently default to 6, while some other vendors use 1. Good values
to try are 1, 4, 5, and 7.


I added the line: options myri10ge myri10ge_pat_idx=1
to my /etc/modprobe.conf, made a new initrd image and rebooted.

The "NVRM: PAT configuration unsupported, falling back to MTRRs." error 
has gone away and everything is now working like it should. This is 
running the 180.06 driver with the CUDA 2.1 beta, but I'm assuming it 
will also work with CUDA 2.0 and its appropriate driver.
</QUOTE>


If I change the PAT index for my nvidia graphics driver, it may solve 
the problem. What PAT indices should I attempt? Is it possible to change 
the PAT index when loading the nvidia module?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 01:00 AM, Mr. Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I saw this posting by Boris.
>
> http://article.gmane.org/gmane.comp.emulators.xen.devel/61143
>
> Perhaps the Xen dom 0 pvops kernel I am using is too new (2.6.30-rc3), 
> and the NVIDIA driver I am using does not support it.
>



[-- Attachment #1.2: Type: text/html, Size: 3256 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Vt-d not working with 3.4.1

[Andrew Lyon]

On Thu, Aug 20, 2009 at 5:41 PM, Mr. Teo En Ming (Zhang
Enming)<enming.teo@asiasoftsea.net> wrote:
> Dear All,
>
> I followed the XEN - NVIDIA - STEP BY STEP instructions at nV news forums
> but I still couldn't get X to work under Xen pv-ops domain 0 kernel. It
> still shows me a freezed blank screen. I couldn't switch to any tty (1 to 7
> inclusive).
>
> Here are the scenarios I have tried:
>
> 1)     IGNORE_XEN_PRESENCE=y ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>
> 2)     IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT
> -DNV_SIGNAL_STRUCT_RLIM" ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>
> 3)
>
> ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run --extract-only
>
> cd usr/src/nv
>
> IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM"
> make SYSSRC=/usr/src/kernels/2.6.30-rc3-enming.teo-tip module
>
> cp nvidia.ko /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>
> cd /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>
> depmod -a
>
> rmmod nvidia
>
> lsmod | grep nvidia
>
> modprobe nvidia
>
> lsmod | grep nvidia
>
> None of the above three scenarios I have attempted worked for me.
>
> When I tried to load the newly compiled nvidia driver (against the Xen
> Domain 0 paravirt operations kernel), it gives me the following message:
>
> NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 17:52:27
> PDT 2009
>
> NVRM: PAT configuration unsupported, falling back to MTRRs.
>
> Any more ideas?
>
> My home PC configuration:
>
> Intel Pentium processor E6300 LGA775
> Intel Desktop Board DQ45CB
> BIOS Version 0093
> 8 GB DDR2-800
> NVIDIA Geforce 8400 GS 512 MB DDR2 PCI Express x16
>
> Fedora 11 64-bit Host operating system
> Xen hypervisor 3.4.1
> Jeremy Fitzhardinge's pv-ops dom 0 Xen kernel 2.6.30-rc3 and 2.6.31-rc6
> Default shipping X server
> mesa-lib upgraded
>
> --
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
> BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN: teoenming@hotmail.com
> Alma Maters: Singapore Polytechnic, National University of Singapore
>
>
>
> On 08/21/2009 12:23 AM, Teo En Ming (Zhang Enming) wrote:
>>
>> This certainly looks promising. No need to apply any patch to NVIDIA
>> graphics drivers for it to be Xen-aware.
>>
>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=122900
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 9:21 PM
>> To: enming.teo@asiasoftsea.net; mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>
>> <QUOTE drivesoslow>
>>
>> SOLVED!
>>
>> It was a kernel issue. The current Fedora 8 XEN kernel was the issue.
>> Since
>> there was not a newer one available I enabled the development repo and
>> installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
>> with the drive source and I have a working NVIDIA 169.07 driver. I assume
>> when the next kernel is release for Fedora 8 it will resolve this issue.
>>
>> Was:
>> Code:
>>
>> kernel-xen-2.6.21-2952.fc8
>> kernel-xen-devel-2.6.21-2952.fc8
>>
>> Now:
>> Code:
>>
>> kernel-xen-2.6.21.7-2892.fc9
>> kernel-xen-devel-2.6.21.7-2892.fc9
>>
>> </QUOTE>
>>
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 9:10 PM
>> To: enming.teo@asiasoftsea.net; mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>
>> <QUOTE drivesoslow>
>>
>> I was able to get it to compile and install no problem finally, but it
>> locks
>> up when I startx. I can compile it for non-XEN 64bit no problem. The
>> non-XEN
>> kernel is significantly newer (2.6.23 vs 2.6.21)
>>
>> </QUOTE>
>>
>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395
>>
>> Same problem as what I am getting.
>>
>> I am using the NVidia Geforce 8 series drivers for 64-bit.
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 8:52 PM
>> To: enming.teo@asiasoftsea.net; mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>
>> <QUOTE monz at nV News Forums>
>>
>> The problem with video on Xen is that the driver needs to be Xen-aware.
>>
>> </QUOTE>
>>
>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 8:49 PM
>> To: enming.teo@asiasoftsea.net; mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>
>> Will the Xen patch for NVIDIA graphics drivers mentioned in the below
>> opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
>> 2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
>> below.
>>
>> <CODE>
>>
>> diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
>> --- nv-1.0-9625/nv.c    2006-09-26 21:33:35.000000000 +0200
>> +++ nv-1.0-9625-xenrt/nv.c      2006-10-03 01:15:42.000000000 +0200
>> @@ -42,8 +42,26 @@
>>
>>  int nv_pat_enabled = 0;
>>
>> +/*
>> + * disable PAT support if XEN or PREEMPT_RT is configured in kernel
>> + */
>> +
>> +#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
>> +static int nv_disable_pat = 1;
>> +#else
>>  static int nv_disable_pat = 0;
>> +#endif
>> +
>> +/*
>> + * you can re-enable PAT support for PREEMPT_RT when applying
>> + * "nv_disable_pat=0" as kernel parameter for the sake of slightly
>> + * better 3D performance but at the expense of higher latencies.
>> + * if XEN is configured, then PAT support can't be enabled!
>> + */
>> +
>> +#if !defined(CONFIG_XEN)
>>  NV_MODULE_PARAMETER(nv_disable_pat);
>> +#endif
>>
>>  #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
>>  NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
>> diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
>> --- nv-1.0-9625/nv-linux.h      2006-09-26 21:33:37.000000000 +0200
>> +++ nv-1.0-9625-xenrt/nv-linux.h        2006-10-03 01:15:42.000000000
>> +0200
>> @@ -226,7 +226,7 @@
>>   * tiny, and the kernel panics when it is exhausted. try to warn the user
>> that
>>   * they need to boost the size of their pool.
>>   */
>> -#if defined(CONFIG_SWIOTLB)&&  !defined(GFP_DMA32)
>> +#if defined(CONFIG_SWIOTLB)&&  !defined(GFP_DMA32)&&
>>  !defined(CONFIG_XEN)
>>  #define NV_SWIOTLB 1
>>  #endif
>>
>> @@ -734,7 +734,10 @@
>>  #define NV_VM_INSERT_PAGE(vma, addr, page) \
>>      vm_insert_page(vma, addr, page)
>>  #endif
>> -#if defined(NV_REMAP_PFN_RANGE_PRESENT)
>> +#if defined(CONFIG_XEN)
>> +#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
>> +    io_remap_pfn_range(vma, from, ((offset)>>  PAGE_SHIFT), x)
>> +#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
>>  #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
>>      remap_pfn_range(vma, from, ((offset)>>  PAGE_SHIFT), x)
>>  #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
>> @@ -746,6 +749,9 @@
>>  #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
>>  #endif
>>
>> +#if !defined(CONFIG_XEN)
>> +#define phys_to_machine(x) x
>> +#endif
>>
>>  #define NV_PGD_OFFSET(address, kernel, mm)              \
>>     ({                                                   \
>> diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
>> --- nv-1.0-9625/nv-vm.c 2006-09-26 21:33:37.000000000 +0200
>> +++ nv-1.0-9625-xenrt/nv-vm.c   2006-10-03 01:24:31.000000000 +0200
>> @@ -352,6 +352,9 @@
>>
>>  static void nv_flush_caches(void)
>>  {
>> +#if defined(CONFIG_PREEMPT_RT)
>> +    if(!nv_pat_enabled) return;
>> +#endif
>>  #if defined(KERNEL_2_4)
>>      // for 2.4 kernels, just automatically flush the caches and
>> invalidate
>> tlbs
>>  #ifdef CONFIG_SMP
>> @@ -508,7 +511,7 @@
>>          page_ptr->phys_addr = phys_addr;
>>          page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
>>          page_ptr->virt_addr = virt_addr;
>> -        page_ptr->dma_addr = page_ptr->phys_addr;
>> +        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
>>
>>          /* lock the page for dma purposes */
>>          nv_lock_page(page_ptr);
>> diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
>> --- nv-1.0-9625/os-agp.c        2006-09-26 21:33:37.000000000 +0200
>> +++ nv-1.0-9625-xenrt/os-agp.c  2006-10-03 01:15:42.000000000 +0200
>> @@ -286,7 +286,7 @@
>>
>>           page_ptr->phys_addr = (ptr->memory[i]&  PAGE_MASK);
>>           page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
>> -         page_ptr->dma_addr  = page_ptr->phys_addr;
>> +         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
>>      }
>>
>>      return RM_OK;
>> diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
>> --- nv-1.0-9625/os-interface.c  2006-09-26 21:33:37.000000000 +0200
>> +++ nv-1.0-9625-xenrt/os-interface.c    2006-10-03 01:15:42.000000000
>> +0200
>> @@ -527,6 +527,7 @@
>>      MicroSeconds = MilliSeconds * 1000;
>>      tm_end.tv_usec = MicroSeconds;
>>      tm_end.tv_sec = 0;
>> +#if !defined(CONFIG_XEN)
>>      NV_TIMERADD(&tm_aux,&tm_end,&tm_end);
>>
>>      /* do we have a full jiffie to wait? */
>> @@ -564,6 +565,7 @@
>>                  MicroSeconds = 0;
>>          } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
>>      }
>> +#endif
>>
>>      if (MicroSeconds>  1000)
>>      {
>>
>> </CODE>
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 8:37 PM
>> To: enming.teo@asiasoftsea.net; mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>
>> No wonder compiling official NVidia drivers against the Xen domain 0
>> paravirt operations kernel doesn't work. It causes my X server to show a
>> blank screen and freeze. NVidia drivers need to be patched for it to work
>> with Xen kernels.
>>
>> http://en.opensuse.org/Use_Nvidia_driver_with_Xen
>>
>> May I know where I can get the patch?
>>
>> Regards,
>>
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En
>> Ming
>> (Zhang Enming)
>> Sent: Thursday, August 20, 2009 1:06 AM
>> To: mad@wol.de
>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
>>
>> Dear All,
>>
>> I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using
>> gzip compression works. I can use the generated bzImage to boot up Domain
>> 0.
>>
>> If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2
>> compression, you won't be able to boot up Domain 0 using the generated
>> bzImage. You will get an ELF error and kernel panic on CPU 0.
>>
>> As for X server, I haven't got much luck yet.
>>
>> I was able to download and compile NVIDIA's kernel module directly from
>> official NVIDIA website for Fedora 11 Default shipping kernel. I was
>> able to start X server successfully and launch a desktop environment
>> using nvidia.ko.
>>
>> However, if I want to compile the nvidia kernel module against Xen dom 0
>> pv_ops kernel sources, the kernel module compiles successfully, but when
>> I start X, the screen becomes blank and the whole system freezes there.
>>
>>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

I am fairly sure that IGNORE_XEN_PRESENCE=y only makes the driver work
with a traditional (not pvops) patched xen kernel, I don't think it
will help to make the module compile or work with a pv_ops kernel.

Andy

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

Sigh...

Looks like I have to compile the nouveau driver sources against the pvops kernel instead and give up official nvidia drivers. Any ideas it might work?

Because for pvops dom 0 kernel, CONFIG_DRM_NOUVEAU is not supported.
CONFIG_DRM_NOUVEAU is only supported in the default shipping Fedora 11 kernel.

When I look at this wiki page http://nouveau.freedesktop.org/wiki/InstallDRM , I got a bit confused as there are too many alternatives suggested.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 02:03 AM, Andrew Lyon wrote:
> On Thu, Aug 20, 2009 at 5:41 PM, Mr. Teo En Ming (Zhang
> Enming)<enming.teo@asiasoftsea.net>  wrote:
>    
>> Dear All,
>>
>> I followed the XEN - NVIDIA - STEP BY STEP instructions at nV news forums
>> but I still couldn't get X to work under Xen pv-ops domain 0 kernel. It
>> still shows me a freezed blank screen. I couldn't switch to any tty (1 to 7
>> inclusive).
>>
>> Here are the scenarios I have tried:
>>
>> 1)     IGNORE_XEN_PRESENCE=y ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>>
>> 2)     IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT
>> -DNV_SIGNAL_STRUCT_RLIM" ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run
>>
>> 3)
>>
>> ./NVIDIA-Linux-x86_64-185.18.31-pkg2.run --extract-only
>>
>> cd usr/src/nv
>>
>> IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM"
>> make SYSSRC=/usr/src/kernels/2.6.30-rc3-enming.teo-tip module
>>
>> cp nvidia.ko /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>>
>> cd /lib/modules/2.6.30-rc3-enming.teo-tip/kernel/drivers/video
>>
>> depmod -a
>>
>> rmmod nvidia
>>
>> lsmod | grep nvidia
>>
>> modprobe nvidia
>>
>> lsmod | grep nvidia
>>
>> None of the above three scenarios I have attempted worked for me.
>>
>> When I tried to load the newly compiled nvidia driver (against the Xen
>> Domain 0 paravirt operations kernel), it gives me the following message:
>>
>> NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 17:52:27
>> PDT 2009
>>
>> NVRM: PAT configuration unsupported, falling back to MTRRs.
>>
>> Any more ideas?
>>
>> My home PC configuration:
>>
>> Intel Pentium processor E6300 LGA775
>> Intel Desktop Board DQ45CB
>> BIOS Version 0093
>> 8 GB DDR2-800
>> NVIDIA Geforce 8400 GS 512 MB DDR2 PCI Express x16
>>
>> Fedora 11 64-bit Host operating system
>> Xen hypervisor 3.4.1
>> Jeremy Fitzhardinge's pv-ops dom 0 Xen kernel 2.6.30-rc3 and 2.6.31-rc6
>> Default shipping X server
>> mesa-lib upgraded
>>
>> --
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>> BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN: teoenming@hotmail.com
>> Alma Maters: Singapore Polytechnic, National University of Singapore
>>
>>
>>
>> On 08/21/2009 12:23 AM, Teo En Ming (Zhang Enming) wrote:
>>      
>>> This certainly looks promising. No need to apply any patch to NVIDIA
>>> graphics drivers for it to be Xen-aware.
>>>
>>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=122900
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 9:21 PM
>>> To: enming.teo@asiasoftsea.net; mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> <QUOTE drivesoslow>
>>>
>>> SOLVED!
>>>
>>> It was a kernel issue. The current Fedora 8 XEN kernel was the issue.
>>> Since
>>> there was not a newer one available I enabled the development repo and
>>> installed the Fedora 9 XEN kernel that was in it. A couple of small hacks
>>> with the drive source and I have a working NVIDIA 169.07 driver. I assume
>>> when the next kernel is release for Fedora 8 it will resolve this issue.
>>>
>>> Was:
>>> Code:
>>>
>>> kernel-xen-2.6.21-2952.fc8
>>> kernel-xen-devel-2.6.21-2952.fc8
>>>
>>> Now:
>>> Code:
>>>
>>> kernel-xen-2.6.21.7-2892.fc9
>>> kernel-xen-devel-2.6.21.7-2892.fc9
>>>
>>> </QUOTE>
>>>
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 9:10 PM
>>> To: enming.teo@asiasoftsea.net; mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> <QUOTE drivesoslow>
>>>
>>> I was able to get it to compile and install no problem finally, but it
>>> locks
>>> up when I startx. I can compile it for non-XEN 64bit no problem. The
>>> non-XEN
>>> kernel is significantly newer (2.6.23 vs 2.6.21)
>>>
>>> </QUOTE>
>>>
>>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=106395
>>>
>>> Same problem as what I am getting.
>>>
>>> I am using the NVidia Geforce 8 series drivers for 64-bit.
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 8:52 PM
>>> To: enming.teo@asiasoftsea.net; mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> <QUOTE monz at nV News Forums>
>>>
>>> The problem with video on Xen is that the driver needs to be Xen-aware.
>>>
>>> </QUOTE>
>>>
>>> Link: http://www.nvnews.net/vbulletin/showthread.php?t=60125
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 8:49 PM
>>> To: enming.teo@asiasoftsea.net; mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> Will the Xen patch for NVIDIA graphics drivers mentioned in the below
>>> opensuse.org link work with Xen 3.4.1 rc and Jeremy's pv-ops dom 0 kernel
>>> 2.6.30-rc3 or 2.6.31-rc6 under Fedora 11 64-bit? Please see the patch code
>>> below.
>>>
>>> <CODE>
>>>
>>> diff -urN nv-1.0-9625/nv.c nv-1.0-9625-xenrt/nv.c
>>> --- nv-1.0-9625/nv.c    2006-09-26 21:33:35.000000000 +0200
>>> +++ nv-1.0-9625-xenrt/nv.c      2006-10-03 01:15:42.000000000 +0200
>>> @@ -42,8 +42,26 @@
>>>
>>>   int nv_pat_enabled = 0;
>>>
>>> +/*
>>> + * disable PAT support if XEN or PREEMPT_RT is configured in kernel
>>> + */
>>> +
>>> +#if defined(CONFIG_XEN) || defined(CONFIG_PREEMPT_RT)
>>> +static int nv_disable_pat = 1;
>>> +#else
>>>   static int nv_disable_pat = 0;
>>> +#endif
>>> +
>>> +/*
>>> + * you can re-enable PAT support for PREEMPT_RT when applying
>>> + * "nv_disable_pat=0" as kernel parameter for the sake of slightly
>>> + * better 3D performance but at the expense of higher latencies.
>>> + * if XEN is configured, then PAT support can't be enabled!
>>> + */
>>> +
>>> +#if !defined(CONFIG_XEN)
>>>   NV_MODULE_PARAMETER(nv_disable_pat);
>>> +#endif
>>>
>>>   #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
>>>   NvU64 __nv_supported_pte_mask = ~_PAGE_NX;
>>> diff -urN nv-1.0-9625/nv-linux.h nv-1.0-9625-xenrt/nv-linux.h
>>> --- nv-1.0-9625/nv-linux.h      2006-09-26 21:33:37.000000000 +0200
>>> +++ nv-1.0-9625-xenrt/nv-linux.h        2006-10-03 01:15:42.000000000
>>> +0200
>>> @@ -226,7 +226,7 @@
>>>    * tiny, and the kernel panics when it is exhausted. try to warn the user
>>> that
>>>    * they need to boost the size of their pool.
>>>    */
>>> -#if defined(CONFIG_SWIOTLB)&&    !defined(GFP_DMA32)
>>> +#if defined(CONFIG_SWIOTLB)&&    !defined(GFP_DMA32)&&
>>>   !defined(CONFIG_XEN)
>>>   #define NV_SWIOTLB 1
>>>   #endif
>>>
>>> @@ -734,7 +734,10 @@
>>>   #define NV_VM_INSERT_PAGE(vma, addr, page) \
>>>       vm_insert_page(vma, addr, page)
>>>   #endif
>>> -#if defined(NV_REMAP_PFN_RANGE_PRESENT)
>>> +#if defined(CONFIG_XEN)
>>> +#define NV_REMAP_PAGE_RANGE(from, offset, x...) \
>>> +    io_remap_pfn_range(vma, from, ((offset)>>    PAGE_SHIFT), x)
>>> +#elif defined(NV_REMAP_PFN_RANGE_PRESENT)
>>>   #define NV_REMAP_PAGE_RANGE(from, offset, x...) \
>>>       remap_pfn_range(vma, from, ((offset)>>    PAGE_SHIFT), x)
>>>   #elif defined(NV_REMAP_PAGE_RANGE_5_PRESENT)
>>> @@ -746,6 +749,9 @@
>>>   #define NV_REMAP_PAGE_RANGE(x...) remap_page_range(x)
>>>   #endif
>>>
>>> +#if !defined(CONFIG_XEN)
>>> +#define phys_to_machine(x) x
>>> +#endif
>>>
>>>   #define NV_PGD_OFFSET(address, kernel, mm)              \
>>>      ({                                                   \
>>> diff -urN nv-1.0-9625/nv-vm.c nv-1.0-9625-xenrt/nv-vm.c
>>> --- nv-1.0-9625/nv-vm.c 2006-09-26 21:33:37.000000000 +0200
>>> +++ nv-1.0-9625-xenrt/nv-vm.c   2006-10-03 01:24:31.000000000 +0200
>>> @@ -352,6 +352,9 @@
>>>
>>>   static void nv_flush_caches(void)
>>>   {
>>> +#if defined(CONFIG_PREEMPT_RT)
>>> +    if(!nv_pat_enabled) return;
>>> +#endif
>>>   #if defined(KERNEL_2_4)
>>>       // for 2.4 kernels, just automatically flush the caches and
>>> invalidate
>>> tlbs
>>>   #ifdef CONFIG_SMP
>>> @@ -508,7 +511,7 @@
>>>           page_ptr->phys_addr = phys_addr;
>>>           page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
>>>           page_ptr->virt_addr = virt_addr;
>>> -        page_ptr->dma_addr = page_ptr->phys_addr;
>>> +        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
>>>
>>>           /* lock the page for dma purposes */
>>>           nv_lock_page(page_ptr);
>>> diff -urN nv-1.0-9625/os-agp.c nv-1.0-9625-xenrt/os-agp.c
>>> --- nv-1.0-9625/os-agp.c        2006-09-26 21:33:37.000000000 +0200
>>> +++ nv-1.0-9625-xenrt/os-agp.c  2006-10-03 01:15:42.000000000 +0200
>>> @@ -286,7 +286,7 @@
>>>
>>>            page_ptr->phys_addr = (ptr->memory[i]&    PAGE_MASK);
>>>            page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
>>> -         page_ptr->dma_addr  = page_ptr->phys_addr;
>>> +         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
>>>       }
>>>
>>>       return RM_OK;
>>> diff -urN nv-1.0-9625/os-interface.c nv-1.0-9625-xenrt/os-interface.c
>>> --- nv-1.0-9625/os-interface.c  2006-09-26 21:33:37.000000000 +0200
>>> +++ nv-1.0-9625-xenrt/os-interface.c    2006-10-03 01:15:42.000000000
>>> +0200
>>> @@ -527,6 +527,7 @@
>>>       MicroSeconds = MilliSeconds * 1000;
>>>       tm_end.tv_usec = MicroSeconds;
>>>       tm_end.tv_sec = 0;
>>> +#if !defined(CONFIG_XEN)
>>>       NV_TIMERADD(&tm_aux,&tm_end,&tm_end);
>>>
>>>       /* do we have a full jiffie to wait? */
>>> @@ -564,6 +565,7 @@
>>>                   MicroSeconds = 0;
>>>           } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
>>>       }
>>> +#endif
>>>
>>>       if (MicroSeconds>    1000)
>>>       {
>>>
>>> </CODE>
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Teo En Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 8:37 PM
>>> To: enming.teo@asiasoftsea.net; mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: RE: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> No wonder compiling official NVidia drivers against the Xen domain 0
>>> paravirt operations kernel doesn't work. It causes my X server to show a
>>> blank screen and freeze. NVidia drivers need to be patched for it to work
>>> with Xen kernels.
>>>
>>> http://en.opensuse.org/Use_Nvidia_driver_with_Xen
>>>
>>> May I know where I can get the patch?
>>>
>>> Regards,
>>>
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
>>> BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Mobile: +65-9648-9798
>>> MSN: teoenming@hotmail.com
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En
>>> Ming
>>> (Zhang Enming)
>>> Sent: Thursday, August 20, 2009 1:06 AM
>>> To: mad@wol.de
>>> Cc: xen-devel@lists.xensource.com; weidong.han@intel.com; 'Bonenkamp,Ralf'
>>> Subject: Re: [Xen-devel] Vt-d not working with 3.4.1
>>>
>>> Dear All,
>>>
>>> I can confirm that recompiling the Xen dom 0 paravirt-ops kernel using
>>> gzip compression works. I can use the generated bzImage to boot up Domain
>>> 0.
>>>
>>> If you attempt to compile the Xen Dom 0 pv-ops kernel using bzip2
>>> compression, you won't be able to boot up Domain 0 using the generated
>>> bzImage. You will get an ELF error and kernel panic on CPU 0.
>>>
>>> As for X server, I haven't got much luck yet.
>>>
>>> I was able to download and compile NVIDIA's kernel module directly from
>>> official NVIDIA website for Fedora 11 Default shipping kernel. I was
>>> able to start X server successfully and launch a desktop environment
>>> using nvidia.ko.
>>>
>>> However, if I want to compile the nvidia kernel module against Xen dom 0
>>> pv_ops kernel sources, the kernel module compiles successfully, but when
>>> I start X, the screen becomes blank and the whole system freezes there.
>>>
>>>
>>>        
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>      
> I am fairly sure that IGNORE_XEN_PRESENCE=y only makes the driver work
> with a traditional (not pvops) patched xen kernel, I don't think it
> will help to make the module compile or work with a pv_ops kernel.
>
> Andy
>    

Re: Vt-d not working with 3.4.1

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2009 at 02:10:41AM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
> Sigh...
>
> Looks like I have to compile the nouveau driver sources against the pvops kernel instead and give up official nvidia drivers. Any ideas it might work?
>
> Because for pvops dom 0 kernel, CONFIG_DRM_NOUVEAU is not supported.
> CONFIG_DRM_NOUVEAU is only supported in the default shipping Fedora 11 kernel.
>
> When I look at this wiki page http://nouveau.freedesktop.org/wiki/InstallDRM , I got a bit confused as there are too many alternatives suggested.

Follow either a)Completely out-of-tree build for your existing kernel or b) Rebuilding your existing kernel with new DRM and Nouveau parts

Re: Vt-d not working with 3.4.1

[Mr. Teo En Ming (Zhang Enming)]

I will give it a try.

Thank you!

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 02:43 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2009 at 02:10:41AM +0800, Mr. Teo En Ming (Zhang Enming) wrote:
>    
>> Sigh...
>>
>> Looks like I have to compile the nouveau driver sources against the pvops kernel instead and give up official nvidia drivers. Any ideas it might work?
>>
>> Because for pvops dom 0 kernel, CONFIG_DRM_NOUVEAU is not supported.
>> CONFIG_DRM_NOUVEAU is only supported in the default shipping Fedora 11 kernel.
>>
>> When I look at this wiki page http://nouveau.freedesktop.org/wiki/InstallDRM , I got a bit confused as there are too many alternatives suggested.
>>      
> Follow either a)Completely out-of-tree build for your existing kernel or b) Rebuilding your existing kernel with new DRM and Nouveau parts
>    

RE: Vt-d not working with 3.4.1

[Teo En Ming (Zhang Enming)]

I think I can quite follow the nouveau build instructions here:

http://nouveau.freedesktop.org/wiki/InstallDRM

Regards,
 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering) 
Technical Support Engineer 
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza 
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: Friday, August 21, 2009 8:24 AM
To: konrad.wilk@oracle.com
Cc: Bonenkamp, Ralf; andrew.lyon@gmail.com; weidong.han@intel.com;
xen-devel@lists.xensource.com; mad@wol.de
Subject: Re: [Xen-devel] Vt-d not working with 3.4.1

I will give it a try.

Thank you!

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore



On 08/21/2009 02:43 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2009 at 02:10:41AM +0800, Mr. Teo En Ming (Zhang Enming)
wrote:
>    
>> Sigh...
>>
>> Looks like I have to compile the nouveau driver sources against the pvops
kernel instead and give up official nvidia drivers. Any ideas it might work?
>>
>> Because for pvops dom 0 kernel, CONFIG_DRM_NOUVEAU is not supported.
>> CONFIG_DRM_NOUVEAU is only supported in the default shipping Fedora 11
kernel.
>>
>> When I look at this wiki page
http://nouveau.freedesktop.org/wiki/InstallDRM , I got a bit confused as
there are too many alternatives suggested.
>>      
> Follow either a)Completely out-of-tree build for your existing kernel or
b) Rebuilding your existing kernel with new DRM and Nouveau parts
>    



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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/19/09
18:06:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.61/2314 - Release Date: 08/20/09
18:06:00

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 02:45:54PM +0200, Marc - A. Dahlhaus wrote:
> Mr. Teo En Ming (Zhang Enming) schrieb:
> >Dear Pasi,
> >
> >I suspect that there may be some problems with the Xen 3.4.1 changeset 
> >of 6 August 2009.
> >
> >The bzImage kernel image that I compiled is not a bzip2 file, hence I 
> >cannot bzcat it. If I tried to do so, it will complain that it is not 
> >a bzip2 file.
> >
> >I did specify the following in my kernel configuration:
> >
> >CONFIG_HAVE_KERNEL_BZIP2=y
> >CONFIG_KERNEL_BZIP2=y
> >CONFIG_RD_BZIP2=y
> >CONFIG_DECOMPRESS_BZIP2=y
> >
> >When I do a "xm dmesg" command, I see the following output:
> >
> >(XEN) Intel VT-d DMAR tables have been parsed.
> >(XEN) Intel VT-d Snoop Control not supported.
> >(XEN) Intel VT-d DMA Passthrough not supported.
> >(XEN) Intel VT-d Queued Invalidation not supported.
> >(XEN) Intel VT-d Interrupt Remapping not supported.
> >(XEN) I/O virtualisation enabled
> >(XEN) I/O virtualisation for PV guests disabled
> >
> >So can I confirm that I have VT-d support enabled?
> >
> >I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
> >NOT ELF images.
> >
> >Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
> >images.
> >
> >However, vmlinux inside compressed cannot boot successfully.
> >
> >Only vmlinux.bin inside compressed can boot successfully, and this is 
> >what I am using now.
> >
> >Regarding X server (GUI) unable to start, I have a backtrace inside 
> >/var/log/Xorg.0.log.
> >
> >It complains about Fatal Server error:
> >Caught signal 11. Server aborting.
> >
> The bzImage has nothing to do with bzip2 compression and the current 
> dom0 loader can only decode that CONFIG_KERNEL_GZIP based image.
> Please change your config to use CONFIG_KERNEL_GZIP instead of 
> CONFIG_KERNEL_BZIP2.
> 

Actually there is a patch to support bzip2 and LZMA compression:
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg00351.html

-- Pasi

Re: Vt-d not working with 3.4.1

[Marc - A. Dahlhaus]

Pasi Kärkkäinen schrieb:
> On Wed, Aug 19, 2009 at 02:45:54PM +0200, Marc - A. Dahlhaus wrote:
>   
>> Mr. Teo En Ming (Zhang Enming) schrieb:
>>     
>>> Dear Pasi,
>>>
>>> I suspect that there may be some problems with the Xen 3.4.1 changeset 
>>> of 6 August 2009.
>>>
>>> The bzImage kernel image that I compiled is not a bzip2 file, hence I 
>>> cannot bzcat it. If I tried to do so, it will complain that it is not 
>>> a bzip2 file.
>>>
>>> I did specify the following in my kernel configuration:
>>>
>>> CONFIG_HAVE_KERNEL_BZIP2=y
>>> CONFIG_KERNEL_BZIP2=y
>>> CONFIG_RD_BZIP2=y
>>> CONFIG_DECOMPRESS_BZIP2=y
>>>
>>> When I do a "xm dmesg" command, I see the following output:
>>>
>>> (XEN) Intel VT-d DMAR tables have been parsed.
>>> (XEN) Intel VT-d Snoop Control not supported.
>>> (XEN) Intel VT-d DMA Passthrough not supported.
>>> (XEN) Intel VT-d Queued Invalidation not supported.
>>> (XEN) Intel VT-d Interrupt Remapping not supported.
>>> (XEN) I/O virtualisation enabled
>>> (XEN) I/O virtualisation for PV guests disabled
>>>
>>> So can I confirm that I have VT-d support enabled?
>>>
>>> I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
>>> NOT ELF images.
>>>
>>> Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
>>> images.
>>>
>>> However, vmlinux inside compressed cannot boot successfully.
>>>
>>> Only vmlinux.bin inside compressed can boot successfully, and this is 
>>> what I am using now.
>>>
>>> Regarding X server (GUI) unable to start, I have a backtrace inside 
>>> /var/log/Xorg.0.log.
>>>
>>> It complains about Fatal Server error:
>>> Caught signal 11. Server aborting.
>>>
>>>       
>> The bzImage has nothing to do with bzip2 compression and the current 
>> dom0 loader can only decode that CONFIG_KERNEL_GZIP based image.
>> Please change your config to use CONFIG_KERNEL_GZIP instead of 
>> CONFIG_KERNEL_BZIP2.
>>
>>     
>
> Actually there is a patch to support bzip2 and LZMA compression:
> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg00351.html
This is for the domU builder in userspace... Dom0 builder is located in 
xen/arch/x86/ ...

Marc

Re: Vt-d not working with 3.4.1

[Pasi Kärkkäinen]

On Wed, Aug 19, 2009 at 03:16:35PM +0200, Marc - A. Dahlhaus wrote:
> Pasi Kärkkäinen schrieb:
> >On Wed, Aug 19, 2009 at 02:45:54PM +0200, Marc - A. Dahlhaus wrote:
> >  
> >>Mr. Teo En Ming (Zhang Enming) schrieb:
> >>    
> >>>Dear Pasi,
> >>>
> >>>I suspect that there may be some problems with the Xen 3.4.1 changeset 
> >>>of 6 August 2009.
> >>>
> >>>The bzImage kernel image that I compiled is not a bzip2 file, hence I 
> >>>cannot bzcat it. If I tried to do so, it will complain that it is not 
> >>>a bzip2 file.
> >>>
> >>>I did specify the following in my kernel configuration:
> >>>
> >>>CONFIG_HAVE_KERNEL_BZIP2=y
> >>>CONFIG_KERNEL_BZIP2=y
> >>>CONFIG_RD_BZIP2=y
> >>>CONFIG_DECOMPRESS_BZIP2=y
> >>>
> >>>When I do a "xm dmesg" command, I see the following output:
> >>>
> >>>(XEN) Intel VT-d DMAR tables have been parsed.
> >>>(XEN) Intel VT-d Snoop Control not supported.
> >>>(XEN) Intel VT-d DMA Passthrough not supported.
> >>>(XEN) Intel VT-d Queued Invalidation not supported.
> >>>(XEN) Intel VT-d Interrupt Remapping not supported.
> >>>(XEN) I/O virtualisation enabled
> >>>(XEN) I/O virtualisation for PV guests disabled
> >>>
> >>>So can I confirm that I have VT-d support enabled?
> >>>
> >>>I have checked. Both bzImage and vmlinux.bin inside arch/x86/boot are 
> >>>NOT ELF images.
> >>>
> >>>Only vmlinux and vmlinux.bin inside arch/x86/boot/compressed are ELF64 
> >>>images.
> >>>
> >>>However, vmlinux inside compressed cannot boot successfully.
> >>>
> >>>Only vmlinux.bin inside compressed can boot successfully, and this is 
> >>>what I am using now.
> >>>
> >>>Regarding X server (GUI) unable to start, I have a backtrace inside 
> >>>/var/log/Xorg.0.log.
> >>>
> >>>It complains about Fatal Server error:
> >>>Caught signal 11. Server aborting.
> >>>
> >>>      
> >>The bzImage has nothing to do with bzip2 compression and the current 
> >>dom0 loader can only decode that CONFIG_KERNEL_GZIP based image.
> >>Please change your config to use CONFIG_KERNEL_GZIP instead of 
> >>CONFIG_KERNEL_BZIP2.
> >>
> >>    
> >
> >Actually there is a patch to support bzip2 and LZMA compression:
> >http://lists.xensource.com/archives/html/xen-devel/2009-08/msg00351.html
> This is for the domU builder in userspace... Dom0 builder is located in 
> xen/arch/x86/ ...
> 

That's true. Thanks for correcting me. 

-- Pasi

RE: Vt-d not working with 3.4.1

[Han, Weidong]

Mr. Teo En Ming (Zhang Enming) wrote:
> Dear Pasi,
> 
> I suspect that there may be some problems with the Xen 3.4.1
> changeset of 6 August 2009. 
> 
> The bzImage kernel image that I compiled is not a bzip2 file, hence I
> cannot bzcat it. If I tried to do so, it will complain that it is not
> a bzip2 file.  
> 
> I did specify the following in my kernel configuration:
> 
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_KERNEL_BZIP2=y
> CONFIG_RD_BZIP2=y
> CONFIG_DECOMPRESS_BZIP2=y
> 
> When I do a "xm dmesg" command, I see the following output:
> 
> (XEN) Intel VT-d DMAR tables have been parsed.
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> 
> So can I confirm that I have VT-d support enabled?
> 

Yes, "(XEN) I/O virtualisation enabled" means VT-d is enabled. 

> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.

Above messages mean those VT-d features are not supported, it may be they are not available or disabled explicitly by 'iommu' parameter. Here, obviously your platform doesn't support those features.

Regards,
Weidong