From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: VGA passthrough and AMD drivers Date: Mon, 10 Dec 2012 14:29:19 +0000 Message-ID: <50C5F1BF.1060604@citrix.com> References: <36774CA35642C143BCDE93BA0C68DC5702C53B78@dulac> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <36774CA35642C143BCDE93BA0C68DC5702C53B78@dulac> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 10/12/12 14:11, Aur=E9lien MILLIAT wrote: > 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:000= 00000: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 hv= m-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=3D0xffff800000000000 > 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 passthrou= gh 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 me= mory. >>>> 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 f= igure 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 synchronizatio= n server and the other a client at the same time. When I set the server, ap= ply 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 saw that problem with the product I was working on once or twice. = Makes it look really "confusing". This was a settings problem in my case = (because I wrote my own "controls", I could set almost every aspect of = everything that could possibly be changed, with a very basic command = line application that interacted pretty straight down to the driver - = with the usual caveat of "make sure you know what you are doing" - the = normal GUI Control panel setup was much more "you can only set things = that make sense for you to set"). That is probably not really what your = problem is... But could be a configuration of driver or application = issue, of course. > > 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. So, this is not a Xen issue... Report it to the ATI/AMD folks! > >> Whilst I'm all for using Xen for everything, there are sometimes situati= ons 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 "non= e 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. Vi= rtual Reality applications are sensitive in their configurations; it's a pa= in to manage multiple users and it's nearly impossible to have different co= nfigurations for these users. Usually immersive systems are stuck in one co= nfiguration (OS, drivers, applications ...), and only few people are allowe= d to change settings. > The idea is to use Xen and VGA passthrough, for create personals environm= ents 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. Thanks for your explanation. Makes some sense, however, I feel that it = also makes things more complex - if the system is so sensitive, it may = get "upset" simply by having the differences in system behaviour that = you automatically get from running on a virtual machine vs. "bare = metal". Don't let that stop you, I'm just saying there may be issues = caused by Xen (or other Virtualisation products) are not quite as = transparent as they really should be. -- Mats > > Aur=E9lien > -- > Mats >> I will try next week with others computers. >> >> Thanks for the reply, >> >> Aurelien >> >> -- >> >> Mats >>> Thanks, >>> Aurelien > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > >