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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/04/15 18:26, Zir Blazer wrote:
> 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.                              
>        

This is very great to hear.  Enjoy your working system!

The first issue might not be placebo, but might relate to some of the
recent fix for long running hypercalls. i.e. it might take a longer
elapsed time, but you are not skewing the scheduling of dom0 by a large
quantity while it is happening.

~Andrew


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