Xen users - Jul 2013 - Have you ever met this behavior with IGD passthrough?

Hi guys,

I know that both of you are playing with IGD passthrough. So I would
like to check with you if I''m the only one that saw this behavior.
In my system, the panel becomes flickering rapidly with different
colors after domU starts. This lasts until the guest loads gfx driver.
There is a workaround by loading the VGA module in GRUB2, which
greatly shorten the time it flickers. But with a natively installed
windows guest, the flickering lasts until the OS get the login screen
prepared. But if the windows is not properly shutdown and the system
enters the repairing screen in next boot, you can simply see nothing
in this case.

This is not show-stopper but is quite annoying. But to my surprise, it
seems that nobody mentions this behavior in blogs / mail-lists. What''s
your case then?

PS: Previously (e.g. xen 4.2.x), this flickering only happens happen
on a second guest boot and later-on (Per host reboot). I just upgraded
to xen 4.3.0, and haven''t got chance to see if this behavior has
changed.

Thanks,
Timothy

On Fri, Jul 26, 2013 at 3:04 AM, G.R. <firemeteor@users.sourceforge.net>
wrote:
> Hi guys,
>
> I know that both of you are playing with IGD passthrough. So I would
> like to check with you if I''m the only one that saw this behavior.
> In my system, the panel becomes flickering rapidly with different
> colors after domU starts. This lasts until the guest loads gfx driver.
> There is a workaround by loading the VGA module in GRUB2, which
> greatly shorten the time it flickers. But with a natively installed
> windows guest, the flickering lasts until the OS get the login screen
> prepared. But if the windows is not properly shutdown and the system
> enters the repairing screen in next boot, you can simply see nothing
> in this case.
>
> This is not show-stopper but is quite annoying. But to my surprise, it
> seems that nobody mentions this behavior in blogs / mail-lists.
What''s
> your case then?
>
> PS: Previously (e.g. xen 4.2.x), this flickering only happens happen
> on a second guest boot and later-on (Per host reboot). I just upgraded
> to xen 4.3.0, and haven''t got chance to see if this behavior has
> changed.
>
> Thanks,
> Timothy

Hello Timothy,

This is actually one of the more infuriating problems with secondary
passthrough...  Windows Startup Repair will just sit there forever.

To disable it, run the following command in your Windows DomU from an
elevated command prompt:
> bcdedit /set {default} recoveryenabled No
That will at least prevent your guest boot from getting hijacked.

You said something about being able to fix that flickering problem by
loading a GRUB2 module.   Does this module allow you to see bootloader
output on a non-primary passedthrough GPU if you chainload the Windows
Boot Manager from it?  That would be a pretty neat workaround!

Cheers,
Andrew Bobulsky

On Fri, Jul 26, 2013 at 6:41 PM, Andrew Bobulsky <rulerof@gmail.com>
wrote:
> On Fri, Jul 26, 2013 at 3:04 AM, G.R.
<firemeteor@users.sourceforge.net> wrote:
>> Hi guys,
>>
>> I know that both of you are playing with IGD passthrough. So I would
>> like to check with you if I''m the only one that saw this
behavior.
>> In my system, the panel becomes flickering rapidly with different
>> colors after domU starts. This lasts until the guest loads gfx driver.
>> There is a workaround by loading the VGA module in GRUB2, which
>> greatly shorten the time it flickers. But with a natively installed
>> windows guest, the flickering lasts until the OS get the login screen
>> prepared. But if the windows is not properly shutdown and the system
>> enters the repairing screen in next boot, you can simply see nothing
>> in this case.
>>
>> This is not show-stopper but is quite annoying. But to my surprise, it
>> seems that nobody mentions this behavior in blogs / mail-lists.
What''s
>> your case then?
>>
>> PS: Previously (e.g. xen 4.2.x), this flickering only happens happen
>> on a second guest boot and later-on (Per host reboot). I just upgraded
>> to xen 4.3.0, and haven''t got chance to see if this behavior
has
>> changed.
>>
>> Thanks,
>> Timothy
>
>
> Hello Timothy,
>
> This is actually one of the more infuriating problems with secondary
> passthrough...  Windows Startup Repair will just sit there forever.
>
> To disable it, run the following command in your Windows DomU from an
> elevated command prompt:
>
>> bcdedit /set {default} recoveryenabled No
Thanks for the sharing. This absolutely helps.
>
> That will at least prevent your guest boot from getting hijacked.
>
> You said something about being able to fix that flickering problem by
> loading a GRUB2 module.   Does this module allow you to see bootloader
> output on a non-primary passedthrough GPU if you chainload the Windows
> Boot Manager from it?  That would be a pretty neat workaround!
>
I believe it''s a different case for a secondary GPU passthrough.
If I understand correctly, you should still be able to see the boot
sequence in the VNC since the boot happens on the emulated primary VGA
which is still available in your case.

In my case, since the emulated VGA is totally replaced by the
passthrough device, I have no alternative if it does not work. (Linux
serial console is not discussed here)

I guess the VBIOS is not properly executed in my case, so the device
is not properly initialized until the guest driver is load.
Grub2 VGA module helps by performing some preliminary initialization.
But I believe it won''t help in your case.

Thanks,
Timothy

Hi guys, any comment on this?

On Fri, Jul 26, 2013 at 3:04 PM, G.R. <firemeteor@users.sourceforge.net>
wrote:
> Hi guys,
>
> I know that both of you are playing with IGD passthrough. So I would
> like to check with you if I''m the only one that saw this behavior.
> In my system, the panel becomes flickering rapidly with different
> colors after domU starts. This lasts until the guest loads gfx driver.
> There is a workaround by loading the VGA module in GRUB2, which
> greatly shorten the time it flickers. But with a natively installed
> windows guest, the flickering lasts until the OS get the login screen
> prepared. But if the windows is not properly shutdown and the system
> enters the repairing screen in next boot, you can simply see nothing
> in this case.
>
> This is not show-stopper but is quite annoying. But to my surprise, it
> seems that nobody mentions this behavior in blogs / mail-lists.
What''s
> your case then?
>
> PS: Previously (e.g. xen 4.2.x), this flickering only happens happen
> on a second guest boot and later-on (Per host reboot). I just upgraded
> to xen 4.3.0, and haven''t got chance to see if this behavior has
> changed.
>
> Thanks,
> Timothy

On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
> Hi guys, any comment on this?
>
Can you please remind about your configuration:

- Which CPU? Which IDG/GPU? 
- HVM guest Windows version? 32b/64b? 
- Xen version
- I assume you''re using qemu-traditional.. which additional patches? 
- dom0 kernel version
- xm or xl?
- HVM guest configfile


Thanks,

-- Pasi
 
> On Fri, Jul 26, 2013 at 3:04 PM, G.R.
<firemeteor@users.sourceforge.net> wrote:
> > Hi guys,
> >
> > I know that both of you are playing with IGD passthrough. So I would
> > like to check with you if I''m the only one that saw this
behavior.
> > In my system, the panel becomes flickering rapidly with different
> > colors after domU starts. This lasts until the guest loads gfx driver.
> > There is a workaround by loading the VGA module in GRUB2, which
> > greatly shorten the time it flickers. But with a natively installed
> > windows guest, the flickering lasts until the OS get the login screen
> > prepared. But if the windows is not properly shutdown and the system
> > enters the repairing screen in next boot, you can simply see nothing
> > in this case.
> >
> > This is not show-stopper but is quite annoying. But to my surprise, it
> > seems that nobody mentions this behavior in blogs / mail-lists.
What''s
> > your case then?
> >
> > PS: Previously (e.g. xen 4.2.x), this flickering only happens happen
> > on a second guest boot and later-on (Per host reboot). I just upgraded
> > to xen 4.3.0, and haven''t got chance to see if this behavior
has
> > changed.
> >
> > Thanks,
> > Timothy

Actually I appreciate if you can share your experience.
I really want to make sure if the issue is specific to my HW.
More below.

On Wed, Aug 7, 2013 at 6:25 PM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
>> Hi guys, any comment on this?
>>
>
> Can you please remind about your configuration:
>
> - Which CPU? Which IDG/GPU?
I7 3770 with IGD 4000.
> - HVM guest Windows version? 32b/64b?
win7 64 bit version.
> - Xen version
All version from xen 4.1.x to xen 4.3
> - I assume you''re using qemu-traditional.. which additional
patches?
You should know the patch set I used -- the patch series I created and
tried to submit (you pinged me several times on it).
> - dom0 kernel version
All kernel versions I ever used. 3.6.x 3.8.7 3.9.8
> - xm or xl?
xl
> - HVM guest configfile
name = ''gamebox''
builder = ''hvm''
vcpus = ''4''
cpus = "0-4"
memory = ''3072''

disk = [''file:/mnt/vmfs/Windows/GameBox/gamebox.img,xvda,w'']
boot = ''c''

vif = [ ''mac=00:18:3E:51:60:4C,bridge=xenbr0,model=e1000'' ]

on_poweroff = ''destroy''
on_reboot = ''restart''
on_crash = ''restart''

#Para-virtualisation support
xen_platform_pci=''1''
#Microsoft Hyper-V support
viridian=''1''

# Use local time instead of UTC
localtime=''1''
# Absolute coordinate pointer device, better support VNC for windows.
usbdevice=''tablet''

#Passthrough
device_model_version="qemu-xen-traditional"
gfx_passthru=1
pci=[''00:02.0'', ''00:1b.0'',
''00:1a.0'']

vnclisten = ''0.0.0.0''
vncpasswd = ''''
serial=''pty''
>
>
> Thanks,
>
> -- Pasi
>
>> On Fri, Jul 26, 2013 at 3:04 PM, G.R.
<firemeteor@users.sourceforge.net> wrote:
>> > Hi guys,
>> >
>> > I know that both of you are playing with IGD passthrough. So I
would
>> > like to check with you if I''m the only one that saw this
behavior.
>> > In my system, the panel becomes flickering rapidly with different
>> > colors after domU starts. This lasts until the guest loads gfx
driver.
>> > There is a workaround by loading the VGA module in GRUB2, which
>> > greatly shorten the time it flickers. But with a natively
installed
>> > windows guest, the flickering lasts until the OS get the login
screen
>> > prepared. But if the windows is not properly shutdown and the
system
>> > enters the repairing screen in next boot, you can simply see
nothing
>> > in this case.
>> >
>> > This is not show-stopper but is quite annoying. But to my
surprise, it
>> > seems that nobody mentions this behavior in blogs / mail-lists.
What''s
>> > your case then?
>> >
>> > PS: Previously (e.g. xen 4.2.x), this flickering only happens
happen
>> > on a second guest boot and later-on (Per host reboot). I just
upgraded
>> > to xen 4.3.0, and haven''t got chance to see if this
behavior has
>> > changed.
>> >
>> > Thanks,
>> > Timothy

On Wed, Aug 07, 2013 at 09:07:40PM +0800, G.R. wrote:
> Actually I appreciate if you can share your experience.
> I really want to make sure if the issue is specific to my HW.
> More below.
>
I think I have a similar CPU available, so I can try with that in a week or so..

 
> On Wed, Aug 7, 2013 at 6:25 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
> >> Hi guys, any comment on this?
> >>
> >
> > Can you please remind about your configuration:
> >
> > - Which CPU? Which IDG/GPU?
> I7 3770 with IGD 4000.
> 
> > - HVM guest Windows version? 32b/64b?
> win7 64 bit version.
> > - Xen version
> All version from xen 4.1.x to xen 4.3
> > - I assume you''re using qemu-traditional.. which additional
patches?
> You should know the patch set I used -- the patch series I created and
> tried to submit (you pinged me several times on it).
> 
Yep, I do :) but I mostly meant if you have any other patches in addition to
those 3 patches from the IGD passthru series.
> > - dom0 kernel version
> All kernel versions I ever used. 3.6.x 3.8.7 3.9.8
> 
> > - xm or xl?
> xl
> > - HVM guest configfile
> 
> name = ''gamebox''
> builder = ''hvm''
> vcpus = ''4''
> cpus = "0-4"
> memory = ''3072''
> 
Did you try with only 2GB? or 1GB? Does it affect anything? 


-- Pasi

> disk =
[''file:/mnt/vmfs/Windows/GameBox/gamebox.img,xvda,w'']
> boot = ''c''
> 
> vif = [ ''mac=00:18:3E:51:60:4C,bridge=xenbr0,model=e1000''
]
> 
> on_poweroff = ''destroy''
> on_reboot = ''restart''
> on_crash = ''restart''
> 
> #Para-virtualisation support
> xen_platform_pci=''1''
> #Microsoft Hyper-V support
> viridian=''1''
> 
> # Use local time instead of UTC
> localtime=''1''
> # Absolute coordinate pointer device, better support VNC for windows.
> usbdevice=''tablet''
> 
> #Passthrough
> device_model_version="qemu-xen-traditional"
> gfx_passthru=1
> pci=[''00:02.0'', ''00:1b.0'',
''00:1a.0'']
> 
> vnclisten = ''0.0.0.0''
> vncpasswd = ''''
> serial=''pty''
> 
> >
> >
> > Thanks,
> >
> > -- Pasi
> >
> >> On Fri, Jul 26, 2013 at 3:04 PM, G.R.
<firemeteor@users.sourceforge.net> wrote:
> >> > Hi guys,
> >> >
> >> > I know that both of you are playing with IGD passthrough. So
I would
> >> > like to check with you if I''m the only one that saw
this behavior.
> >> > In my system, the panel becomes flickering rapidly with
different
> >> > colors after domU starts. This lasts until the guest loads
gfx driver.
> >> > There is a workaround by loading the VGA module in GRUB2,
which
> >> > greatly shorten the time it flickers. But with a natively
installed
> >> > windows guest, the flickering lasts until the OS get the
login screen
> >> > prepared. But if the windows is not properly shutdown and the
system
> >> > enters the repairing screen in next boot, you can simply see
nothing
> >> > in this case.
> >> >
> >> > This is not show-stopper but is quite annoying. But to my
surprise, it
> >> > seems that nobody mentions this behavior in blogs /
mail-lists. What''s
> >> > your case then?
> >> >
> >> > PS: Previously (e.g. xen 4.2.x), this flickering only happens
happen
> >> > on a second guest boot and later-on (Per host reboot). I just
upgraded
> >> > to xen 4.3.0, and haven''t got chance to see if this
behavior has
> >> > changed.
> >> >
> >> > Thanks,
> >> > Timothy

On Wed, Aug 7, 2013 at 9:12 PM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> On Wed, Aug 07, 2013 at 09:07:40PM +0800, G.R. wrote:
>> Actually I appreciate if you can share your experience.
>> I really want to make sure if the issue is specific to my HW.
>> More below.
>>
>
> I think I have a similar CPU available, so I can try with that in a week or
so..
>
Do you mean that you don''t see this in your current config?
So what''s your HW spec?
>
>> On Wed, Aug 7, 2013 at 6:25 PM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
>> > On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
>> >> Hi guys, any comment on this?
>> >>
>> >
>> > Can you please remind about your configuration:
>> >
>> > - Which CPU? Which IDG/GPU?
>> I7 3770 with IGD 4000.
>>
>> > - HVM guest Windows version? 32b/64b?
>> win7 64 bit version.
>> > - Xen version
>> All version from xen 4.1.x to xen 4.3
>> > - I assume you''re using qemu-traditional.. which
additional patches?
>> You should know the patch set I used -- the patch series I created and
>> tried to submit (you pinged me several times on it).
>>
>
> Yep, I do :) but I mostly meant if you have any other patches in addition
to those 3 patches from the IGD passthru series.
>
>> > - dom0 kernel version
>> All kernel versions I ever used. 3.6.x 3.8.7 3.9.8
>>
>> > - xm or xl?
>> xl
>> > - HVM guest configfile
>>
>> name = ''gamebox''
>> builder = ''hvm''
>> vcpus = ''4''
>> cpus = "0-4"
>> memory = ''3072''
>>
>
> Did you try with only 2GB? or 1GB? Does it affect anything?
>
I used to stick on 2048 and only increased to this value recently.
This appear to have something to do with the IO mmap.
But as long as it boots, it has nothing to do with the behavior I
mentioned in my thread.
>
> -- Pasi
>
>
>> disk =
[''file:/mnt/vmfs/Windows/GameBox/gamebox.img,xvda,w'']
>> boot = ''c''
>>
>> vif = [
''mac=00:18:3E:51:60:4C,bridge=xenbr0,model=e1000'' ]
>>
>> on_poweroff = ''destroy''
>> on_reboot = ''restart''
>> on_crash = ''restart''
>>
>> #Para-virtualisation support
>> xen_platform_pci=''1''
>> #Microsoft Hyper-V support
>> viridian=''1''
>>
>> # Use local time instead of UTC
>> localtime=''1''
>> # Absolute coordinate pointer device, better support VNC for windows.
>> usbdevice=''tablet''
>>
>> #Passthrough
>> device_model_version="qemu-xen-traditional"
>> gfx_passthru=1
>> pci=[''00:02.0'', ''00:1b.0'',
''00:1a.0'']
>>
>> vnclisten = ''0.0.0.0''
>> vncpasswd = ''''
>> serial=''pty''
>>
>> >
>> >
>> > Thanks,
>> >
>> > -- Pasi
>> >
>> >> On Fri, Jul 26, 2013 at 3:04 PM, G.R.
<firemeteor@users.sourceforge.net> wrote:
>> >> > Hi guys,
>> >> >
>> >> > I know that both of you are playing with IGD passthrough.
So I would
>> >> > like to check with you if I''m the only one that
saw this behavior.
>> >> > In my system, the panel becomes flickering rapidly with
different
>> >> > colors after domU starts. This lasts until the guest
loads gfx driver.
>> >> > There is a workaround by loading the VGA module in GRUB2,
which
>> >> > greatly shorten the time it flickers. But with a natively
installed
>> >> > windows guest, the flickering lasts until the OS get the
login screen
>> >> > prepared. But if the windows is not properly shutdown and
the system
>> >> > enters the repairing screen in next boot, you can simply
see nothing
>> >> > in this case.
>> >> >
>> >> > This is not show-stopper but is quite annoying. But to my
surprise, it
>> >> > seems that nobody mentions this behavior in blogs /
mail-lists. What''s
>> >> > your case then?
>> >> >
>> >> > PS: Previously (e.g. xen 4.2.x), this flickering only
happens happen
>> >> > on a second guest boot and later-on (Per host reboot). I
just upgraded
>> >> > to xen 4.3.0, and haven''t got chance to see if
this behavior has
>> >> > changed.
>> >> >
>> >> > Thanks,
>> >> > Timothy

On Wed, Aug 07, 2013 at 09:26:38PM +0800, G.R. wrote:
> On Wed, Aug 7, 2013 at 9:12 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Wed, Aug 07, 2013 at 09:07:40PM +0800, G.R. wrote:
> >> Actually I appreciate if you can share your experience.
> >> I really want to make sure if the issue is specific to my HW.
> >> More below.
> >>
> >
> > I think I have a similar CPU available, so I can try with that in a
week or so..
> >
> 
> Do you mean that you don''t see this in your current config?
> So what''s your HW spec?
> 
It has been a while since I last used IGD passthru, so I''m not sure.

I started setting up the testbox for IGD passthru to Win7 last weekend,
but it seems harddisk is broken in the testbox :(

So it''ll take a while until I can try it again.. I''ll let you
know then!

> >
> >> On Wed, Aug 7, 2013 at 6:25 PM, Pasi Kärkkäinen
<pasik@iki.fi> wrote:
> >> > On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
> >> >> Hi guys, any comment on this?
> >> >>
> >> >
> >> > Can you please remind about your configuration:
> >> >
> >> > - Which CPU? Which IDG/GPU?
> >> I7 3770 with IGD 4000.
> >>
> >> > - HVM guest Windows version? 32b/64b?
> >> win7 64 bit version.
> >> > - Xen version
> >> All version from xen 4.1.x to xen 4.3
> >> > - I assume you''re using qemu-traditional.. which
additional patches?
> >> You should know the patch set I used -- the patch series I created
and
> >> tried to submit (you pinged me several times on it).
> >>
> >
> > Yep, I do :) but I mostly meant if you have any other patches in
addition to those 3 patches from the IGD passthru series.
> >
> >> > - dom0 kernel version
> >> All kernel versions I ever used. 3.6.x 3.8.7 3.9.8
> >>
> >> > - xm or xl?
> >> xl
> >> > - HVM guest configfile
> >>
> >> name = ''gamebox''
> >> builder = ''hvm''
> >> vcpus = ''4''
> >> cpus = "0-4"
> >> memory = ''3072''
> >>
> >
> > Did you try with only 2GB? or 1GB? Does it affect anything?
> >
> I used to stick on 2048 and only increased to this value recently.
> This appear to have something to do with the IO mmap.
> But as long as it boots, it has nothing to do with the behavior I
> mentioned in my thread.
> 
OK.


-- Pasi

On Mon, Aug 12, 2013 at 11:47 PM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> On Wed, Aug 07, 2013 at 09:26:38PM +0800, G.R. wrote:
>> On Wed, Aug 7, 2013 at 9:12 PM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
>> > On Wed, Aug 07, 2013 at 09:07:40PM +0800, G.R. wrote:
>> >> Actually I appreciate if you can share your experience.
>> >> I really want to make sure if the issue is specific to my HW.
>> >> More below.
>> >>
>> >
>> > I think I have a similar CPU available, so I can try with that in
a week or so..
>> >
>>
>> Do you mean that you don''t see this in your current config?
>> So what''s your HW spec?
>>
>
> It has been a while since I last used IGD passthru, so I''m not
sure.
>
> I started setting up the testbox for IGD passthru to Win7 last weekend,
> but it seems harddisk is broken in the testbox :(
>
> So it''ll take a while until I can try it again.. I''ll let
you know then!
>
Thank you so much for your effort.
Waiting for your feedback.
PS: please remember to boot the domU several times, the syndrome does
not show up in the first boot.
>
>> >
>> >> On Wed, Aug 7, 2013 at 6:25 PM, Pasi Kärkkäinen
<pasik@iki.fi> wrote:
>> >> > On Wed, Aug 07, 2013 at 06:16:31PM +0800, G.R. wrote:
>> >> >> Hi guys, any comment on this?
>> >> >>
>> >> >
>> >> > Can you please remind about your configuration:
>> >> >
>> >> > - Which CPU? Which IDG/GPU?
>> >> I7 3770 with IGD 4000.
>> >>
>> >> > - HVM guest Windows version? 32b/64b?
>> >> win7 64 bit version.
>> >> > - Xen version
>> >> All version from xen 4.1.x to xen 4.3
>> >> > - I assume you''re using qemu-traditional.. which
additional patches?
>> >> You should know the patch set I used -- the patch series I
created and
>> >> tried to submit (you pinged me several times on it).
>> >>
>> >
>> > Yep, I do :) but I mostly meant if you have any other patches in
addition to those 3 patches from the IGD passthru series.
>> >
>> >> > - dom0 kernel version
>> >> All kernel versions I ever used. 3.6.x 3.8.7 3.9.8
>> >>
>> >> > - xm or xl?
>> >> xl
>> >> > - HVM guest configfile
>> >>
>> >> name = ''gamebox''
>> >> builder = ''hvm''
>> >> vcpus = ''4''
>> >> cpus = "0-4"
>> >> memory = ''3072''
>> >>
>> >
>> > Did you try with only 2GB? or 1GB? Does it affect anything?
>> >
>> I used to stick on 2048 and only increased to this value recently.
>> This appear to have something to do with the IO mmap.
>> But as long as it boots, it has nothing to do with the behavior I
>> mentioned in my thread.
>>
>
> OK.
>
>
> -- Pasi
>