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

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

[Zir Blazer]

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. 		 	   		  

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

[Andrew Cooper]

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 D
 omU), 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

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

[Zir Blazer]

>> 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.


After one day of "production" usage, I must add: The Monitor that is connected to the IGP that Dom0 has control of, tries consistently to enter Sleep Mode. I'm currently using a single DomU, and when I'm actively using it, every a few minutes the Monitor black screens, then either enters sleep, or wakes up inmediately. If at the moment it black screens I move the Mouse or use the Keyboard (Which is very probable, since chances are it will try to do so while I'm playing a game), the screen returns inmediately, but if I don't do anything, it enters sleep. What is weird is that I interrupt it nearly always before the screen powers off. It seems like what I'm doing in the DomU doesn't reset the Dom0 activity counter, so it thinks its on Idle and the Monitor enters Sleep Mode, yet still DomU in
 put usage does work for waking it up, reason why I can interrupt when it black screens just before powering off the screen and entering sleep. Still, this on/sleep cycle is rather annoying.
I don't recall if it happens on Xen 4.4 because I barely used it. It didn't happened with Xen 4.3. Since in Dom0 the only thing that I did was uninstalling the older Xen and installing the new one, I suppose it has to be either Xen itself, or some of the associated systemd services (The xen package had custom systemd support before it was officially integrated for 4.5, and it switched). If someone has any ideas for figuring out the actual cause, and how to fix it, I'm all ears.