Re: [Xen-devel] VGA passthrough and AMD drivers

[Aurélien MILLIAT <Aurelien.MILLIAT@xxxxxxxxxxxxxx>]

On 07/12/12 16:51, Aur?lien MILLIAT wrote:
>>
>> >> Hi all,
>>
>> >>
>>
>> >> I have made some tests to find a good driver for FirePro V8800 on
>>
>> >> windows 7 64bit HVM.
>>
>> >>
>>
>> >> I have been focused on ?advanced features?: quad buffer and active
>>
>> >> stereoscopy, synchronization ?
>>
>> >>
>>
>> >> The results, for all FirePro drivers (of this year); I can?t get 
>> >> the
>>
>> >> quad buffer/active stereoscopy feature.
>>
>> >>
>>
>> >> But they work on a native installation.
>>
>> >>
>>
>> >Can you describe the setup a little more?
>>
>> I?ve got 2 HP Z800 workstation with FirePro V8800, one per computer.
>>
>> It?s a setup used in CAVE system, I try (and its works, minus some
>> issues) to virtualize ?virtual reality contexts? that needs full 
>> graphics card features.
>>
>> Intel Xeon E5640 CPU with Intel 5520 chipset
>>
>> cores_per_socket : 4
>>
>> threads_per_core : 2
>>
>> cpu_mhz : 2660
>>
>> total_memory : 4079
>>
>> >How many graphic cards per guest?
>>
>> One card per guest.
>>
>> >How many guests? On how many hosts?
>>
>> One guest per computer.
>>
>
>And of course, I just thought of some other questions:
>What version of Xen are you using?
>What kernel are you using in Dom0?

release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sun May 6 08:57:29 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2660
hw_caps                : 
bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 4079
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Sun Jul 22 16:37:25 2012 +0100 25622:3c426da4788e
xen_commandline        : placeholder
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
xend_config_format     : 4

I will change to a newer version and use  xl toolstack when VGA passthrough 
will be supported.

>And just to be clear, there is only Dom0 and one Windows 7 HVM guest on each 
>machine?

Yes

>> >>
>>
>> >> The only driver that allows this feature is a Radeon HD driver
>>
>> >> (Catalyst 12.10 WHQL).
>>
>> >>
>>
>> >> But this driver becomes unstable when an application using active
>>
>> >> stereo and synchronization is closed:
>>
>> >>
>>
>> >> -The synchronization between two computers is lost.
>>
>> >>
>>
>> >> -The CCC can crash when the synchronization is made again.
>>
>> >>
>>
>> >> Someone have any clues about this?
>>
>> >>
>>
>> >I don't know exactly how this works on AMD/ATI graphics cards, but I
>>
>> >have worked with synchronisation on other graphics cards about 7 
>> >years
>>
>> >ago, so I have some idea of how you solve the various problems.
>>
>> >
>>
>> >What I don't quite understand is why it would be different between a
>>
>> >virtual environment and the bare-metal ("native") install. My 
>> >immediate
>>
>> >guess is that there is a timing difference, for one of two reasons:
>>
>> >1. IOMMU is adding extra delays to the graphics card reading system memory.
>>
>> >2. Interrupt delays due to hypervisor.
>>
>> >3. Dom0 or other guest domains "stealing" CPU from the guest.
>>
>> >I don't think those are easy to work around (as they all have to
>>
>> >"happen" in a virtual system), but I also don't REALLY understand why
>>
>> >this should cause problems in the first place, as there isn't any
>>
>> >guarantee as to the timings of either memory reads, interrupt
>>
>> >latency/responsiveness or CPU availability in Windows, so the same
>>
>> >problem would appear in native systems as well, given "the right"
>>
>> >circumstances.
>>
>> >
>>
>> >
>>
>> >What exactly is the crash in CCC?
>>
>> >
>>
>> >(CCC stands for "Catalyst Control Center" - which I think is a 
>> >Windows
>>
>> >"service" to handle certain requests from the driver that can't be 
>> >done
>>
>> >in kernel mode [or shouldn't be done in the driver in general]).
>>
>> After the application is closed, I launch the Catalyst Control Center, 
>> the synchronization state seems to be good. But there is no 
>> synchronization.
>>
>> If I try to apply any modifications of synchronization (synchro server 
>> or client), CCC freeze and I need to kill it manually.
>>
>> I can set the synchronization back after this.
>>
>
>This clearly sounds like a software issue in the CCC itself. I could be wrong, 
>but that's what I think right now. It would be rather difficult to figure out 
>what is going wrong without at least a repro environment.

I've made a bunch of tests this morning: 
-CCC crash when I've got two displays: I set one to be the synchronization 
server and the other a client at the same time. When I set the server, apply 
this configuration and set the client after, it didn't crash. 
-If my application (Virtools) crash, synchronization is reset.
-Eyes are sometimes inverted with the same trigger edge.

I've got all this behaviors with both HVM and native installation under 7 
64bits.  So I think it's clearly a software issue.

Next step:  7 32bits.

>Whilst I'm all for using Xen for everything, there are sometimes situations 
>when "not using Xen" may actually be the right choice. Can you explain why 
>running your guests in Xen is of benefit? [If you'd like to answer "none of 
>>your business", that's fine, but it may help to understand what the "business 
>case" is for this].

The objective is to mutualize graphical cluster for immersive systems. Virtual 
Reality applications are sensitive in their configurations; it's a pain to 
manage multiple users and it's nearly impossible to have different 
configurations for these users. Usually immersive systems are stuck in one 
configuration (OS, drivers, applications ...), and only few people are allowed 
to change settings. 
The idea is to use Xen and VGA passthrough, for create personals environments 
that allow every user to make their own configurations without impacts on 
others. 

Be able to have VR configurations in virtual machines and to able to run it 
with 3D features, is a serious benefit for Virtual Reality users.

Aurélien
--
Mats
>
> I will try next week with others computers.
>
> Thanks for the reply,
>
> Aurelien
>
> --
>
> Mats
> > Thanks,
> > Aurelien


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel