Re: Re: Attempt to start X-Server at Xen 3.5 Dom0 ( 2.6.31) on top of Ubuntu 9.04 Server

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/24/09 09:48, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 23, 2009 at 10:54:09PM -0700, Boris Derzhavets wrote:
>   
>> Sorry , there is difference in dmesg reports under xen and as vanilla.
>>
>> dmesg under xen:-
>>
>> [  243.858191] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [  243.858263] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [  244.132051] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [  244.132115] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [  244.132181] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [  244.157265] [drm] Setting GART location based on new memory map
>> [  244.190885] [drm] Loading RV730/RV740 PFP Microcode
>> [  244.190911] [drm] Loading RV730/RV740 CP Microcode
>> [  244.205974] [drm] Resetting GPU
>> ->    [  244.310103] [drm] writeback test failed
>> [  251.220092] [drm] Resetting GPU
>>
>> dmesg 2.6.31 vanilla:-
>>
>> [   36.941430] [drm] Initialized drm 1.1.0 20060810
>> [   36.988225] pci 0000:01:00.0: setting latency timer to 64
>> [   36.988341] [drm] Initialized radeon 1.31.0 20080528 for 0000:01:00.0 on minor 0
>> [   36.989222] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [   37.210900] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [   37.210940] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [   37.210976] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>> [   37.232744] [drm] Setting GART location based on new memory map
>> [   37.248205] [drm] Loading RV730/RV740 PFP Microcode
>> [   37.248227] [drm] Loading RV730/RV740 CP Microcode
>> [   37.263281] [drm] Resetting GPU
>> -> [   37.263336] [drm] writeback test succeeded in 1 usecs
>>     
> I think I know why this is not working.
>
> The DRM and its AGP modules call virt_to_gart and gart_to_virt, which is defined as:
>
> #define virt_to_gart(x) (phys_to_gart(virt_to_phys(x)))
> #define gart_to_virt(x) (phys_to_virt(gart_to_phys(x)))
> and phys_to_gart and gart_to_phys are:
> #define phys_to_gart(x) swiotlb_phys_to_bus(NULL, (x))
> #define gart_to_phys(x) swiotlb_bus_to_phys(NULL, (x))
>
> The swiotlb_* calls do return the wrong information when the
> kernel is running under Xen.
>   

Ah, yes.  They used to be the right thing to call.  I guess we can put
in something hacky to get things going for now: (xen_pv_domain() ?
xen_swiotlb_bus_to_phys(NULL, (x) : (x)).

But it might be time to bite the bullet:

In this current merge window these functions are removed altogether, in
favour of making the dri drivers use the dma-mapping api properly to do
all those conversions.  AFAIK the only driver so converted is the Intel
graphics one, and then only when the Intel IOMMU is configured in. 
However, in discussions with the the dri folks I had no objection to
making it unconditional and adding the changes to other drivers (so long
as we can test them, since normal hardware configs won't generally have
any IOMMU for typical gfx hardware).

    J