[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Have you ever met this behavior with IGD passthrough?



On Wed, Aug 7, 2013 at 9:12 PM, Pasi Kärkkäinen <pasik@xxxxxx> 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@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 
>> >> 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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.