[Xen-devel] Testing Xen 4.5 and PCI/VGA Passthrough - my regression was fixed

[Zir Blazer <zir_blazer@xxxxxxxxxxx>]

This E-Mail is a followup of the previous one about the regression I had in Xen 
4.4 compared to 4.3, here:
http://www.gossamer-threads.com/lists/xen/devel/351336
http://lists.xen.org/archives/html/xen-devel/2014-10/msg01341.html ;(This one is 
missing from the previous link, here I discovered a workaround)

I recall Konrad mentioning that he was able to reproduce the issue in 4.4, and 
said that it didn't happened in 4.5, but didn't catch anything suspicious on 
the bisect to identify what it was. I also recall that there were two guys at 
IRC which described a similar issue when passing the Sound Card in Xen 4.4.


Since Xen 4.5 recently appeared in the Arch Linux User Repository, I tested it. 
Dom0 config should be identical to what I had at that time (Linux Kernel 
3.17.1, BIOS Boot with Syslinux), since I didn't touched my Arch Linux install 
after those. With the pacman package manager, I uninstalled Xen 4.3, rebooted 
into plain Arch Linux, builded Xen 4.5, installed it, enabled the systemd 
services and modified the Boot Loader config file accordingly, rebooted into 
Xen, and finally, launched my WXP x64 DomU. And... EVERYTHING WORKS. No issues 
migrating from 4.3 to 4.5. Since I didn't tested the newer Xen 4.4.x released I 
don't know if my issue was fixed, but at least in 4.5, it is.

But there is more. Since qemu-xen-traditional is going to be deprecated in Xen 
4.6, I decided to change my DomU config file to use qemu-xen and SeaBIOS. 
Created it... and guess what, IT WORKS TOO! WXP x64 detected a few new PCI 
devices and installed Drivers. Jst to make sure, I uninstalled the GPLPV 
Drivers, rebooted into Safe Mode, launched cmd, then did...

set DEVMGR_SHOW_NONPRESENT_DEVICES=1
devmgmt.msc

This way, I can open the Device Manager with a special flag set. Ticking 
View/Show Hidden devices, I can also see devices whose Drivers are installed 
but are not present, so I could remove everything QEMU and Xen related, reboot 
again, then reinstall the GPLPV Drivers. This is as clean as I think it was 
possible for me to do the migration from qemu-xen-traditional to qemu-xen 
without carrying remants from the previous setup.


While I didn't tested a lot, nearly everything seems to be working. The only 
discovered two issues are:
It may be just placebo, but I think that the DomU takes a bit more time while 
booting, and also after I shut down it from inside. With xl list, I see that it 
stays around 20 secs or so after the SDL Window closes in Dom0, first with the 
normal DomU name, then with (null) for some seconds before dissapearing from xl 
list. At that point I can create that DomU again. I think it used to take less 
time previously, but I could be wrong, I don't reboot this DomU often since 
things were rock solid for months of usage.
I also noticed that the Monitor connected to the Intel IGP, which is controlled 
by Dom0, ocassionally black screens like if it was entering Sleep Mode, then 
inmediately shows the X.org desktop again after a second or two. It did that 
even when I was actively using the DomU. However, I confirmed than that is 
actually Sleep Mode, since at least once, the Monitor had the screen off with 
the power on light flashing, then turned on after moving the Mouse. Its rare 
since I don't recall ever seeing that Monitor entering Sleep Mode with Xen 4.3. 
The problem is that I was not able to reproduce what generates activity, or 
know the delay before entering Sleep Mode (Basically, if it enters Sleep while 
I'm Idle in the DomU, or if I need to Ctrl + Alt to Dom0 and leave Idle there 
instead of inside a DomU), to know if its working as intended. Turning off then 
on is not normal, but until knowing what generates activity, it could be bad 
timming.


Even then, congratulations on the 4.5 release. For me, it finally merged a lot 
of scattered features into a single version.                                    
   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel