From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBrsc-00070o-0O for qemu-devel@nongnu.org; Tue, 20 Aug 2013 15:46:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBrsW-00055F-Um for qemu-devel@nongnu.org; Tue, 20 Aug 2013 15:46:13 -0400 Date: Tue, 20 Aug 2013 15:45:26 -0400 From: Konrad Rzeszutek Wilk Message-ID: <20130820194526.GK12037@phenom.dumpdata.com> References: <33183CC9F5247A488A2544077AF190207EF6BEC3@szxeml538-mbx.china.huawei.com> <33183CC9F5247A488A2544077AF190207EF6BF06@szxeml538-mbx.china.huawei.com> <51F24949.4070109@suse.de> <51F24D24.4020201@redhat.com> <20130727115118.GM2924@reaktio.net> <33183CC9F5247A488A2544077AF190207EF6F2CC@szxeml538-mbs.china.huawei.com> <20130729105810.GR2924@reaktio.net> <33183CC9F5247A488A2544077AF19020815935E0@SZXEMA503-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33183CC9F5247A488A2544077AF19020815935E0@SZXEMA503-MBS.china.huawei.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gonglei (Arei)" , benjamin.guthro@citrix.com Cc: "ggrebus@virtualiron.com" , Yangxiaowei , Hanweidong , "vgabios-developers@nongnu.org" , Yanqiangjun , "Ian.Jackson@eu.citrix.com" , "qemu-devel@nongnu.org" , Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= , "xen-devel@lists.xen.org" , "bguthro@virtualron.com" , Gerd Hoffmann , Anthony Liguori , Luonengjun , "keir.fraser@citrix.com" , Andreas =?iso-8859-1?Q?F=E4rber?= , "Huangweidong (Hardware)" On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote: > Hi, > The fundamental reason is traditional qemu-dm and upstream qemu using a= different vgabios-cirrus.bin, > qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.= cirrus.bin,=20 > but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin >=20 > the pivotal patch is : >=20 > # HG changeset patch > # User Keir Fraser > # Date 1193391667 -3600 > # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7 > # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012 >=20 > x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO w= rites. >=20 > Signed-off-by: Ben Guthro > Signed-off-by: Gary Grebus Ben's new address is . CC-ing him here. >=20 > diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c > --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100 > +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100 > @@ -1489,14 +1489,26 @@ > mov dx, #0x3ce > out dx, ax > push ax > - mov cx, #0xa000 > - mov es, cx > - xor di, di > + > +;; Windows Vista appears to be emulating this sequence as part of chan= ging=20 > +;; screen resolution, but it generates 4096 writes per iteration. > +;; Instead, use a magic register sequence to write the whole bank. > +;;mov cx, #0xa000 > +;;mov es, cx > +;;xor di, di > +;;mov ax, si > +;;mov cx, #8192 > +;;cld > +;;rep > +;; stosw > mov ax, si > - mov cx, #8192 > - cld > - rep > - stosw > + shl ax, #8 > + mov al, #0xfe > + out dx, ax ;; Low byte of value to be written to the bank > + mov ax, si > + mov al, #0xff =20 > + out dx, ax ;; High byte and trigger the write > + > pop ax > inc ah > cmp ah, bl > diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c > --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100 > +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100 > @@ -294,6 +294,7 @@ > =20 > static void cirrus_bitblt_reset(CirrusVGAState *s); > static void cirrus_update_memory_access(CirrusVGAState *s); > +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t add= r, uint32_t val); > =20 > /*************************************** > * > @@ -1497,6 +1498,17 @@ > case 0x31: // BLT STATUS/START > cirrus_write_bitblt(s, reg_value); > break; > + > + // Extension to allow BIOS to clear 16K VRAM bank in one operation > + case 0xFE: > + s->gr[reg_index] =3D reg_value; // Lower byte of value to be written > + break; > + case 0xFF: { > + target_phys_addr_t addr; > + for (addr =3D 0xa0000; addr < 0xa4000; addr +=3D 2) > + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]); > + } > + break; > default: > #ifdef DEBUG_CIRRUS > printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index, >=20 > By replacing the vgabios-cirrus.bin, the windows XP guest screen updati= ng is fast with upstream qemu. >=20 > And I test the latest vgabios-0.7a come from=20 > http://www.nongnu.org/vgabios/#DOWNLOAD > but the problem of blank screen remain. >=20 > Best Regards! > -Gonglei > =20 >=20 > > -----Original Message----- > > From: Gonglei (Arei) > > Sent: Friday, August 16, 2013 5:10 PM > > To: Gonglei (Arei); 'Pasi K=C3=A4rkk=C3=A4inen' > > Cc: 'Gerd Hoffmann'; 'Andreas F=C3=A4rber'; Hanweidong; Luonengjun; > > 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori'= ; > > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguor= i'; > > Yanqiangjun; Yangxiaowei > > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, = show > > blank screen last 13s or so for windows XP guest > >=20 > > Hi, all > > I compared the traditional qemu-dm and upstream qemu, > > and I found the upstream qemu will create the expansion ROM at f30000= 00, > > but qemu-dm don't. > > the details as below (by "lspci -vnnn"): > >=20 > > 1) traditional qemu-dm: > > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:= 00b8] > > (prog-if 00 [VGA controller]) > > Subsystem: XenSource, Inc. Device [5853:0001] > > Flags: bus master, fast devsel, latency 0, IRQ 11 > > Memory at f0000000 (32-bit, prefetchable) [size=3D32M] > > Memory at f3000000 (32-bit, non-prefetchable) [size=3D4K] > > Kernel modules: cirrusfb > >=20 > > 2) upstream qemu: > > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:= 00b8] > > (prog-if 00 [VGA controller]) > > Subsystem: XenSource, Inc. Device [5853:0001] > > Physical Slot: 2 > > Flags: bus master, fast devsel, latency 0, IRQ 11 > > Memory at f0000000 (32-bit, prefetchable) [size=3D32M] > > Memory at f3020000 (32-bit, non-prefetchable) [size=3D4K] > > Expansion ROM at f3000000 [disabled] [size=3D64K] > > Kernel modules: cirrusfb > >=20 > > I tried to simply delete the expansion ROM at function pci_add_option= _rom, > > such as > >=20 > > //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); > >=20 > > but the VNC viewer only can see black screen, but RDP works well. > > Any ideas about the cirrus's expansion ROM? > > Slow screen refresh has any relationship with cirrus's expansion ROM? > > Thank you in advance=EF=BC=81 > >=20 > > BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm): > > static int stdvga_intercept_mmio(ioreq_t *p) > > { > > struct domain *d =3D current->domain; > > struct hvm_hw_stdvga *s =3D &d->arch.hvm_domain.stdvga; > > int buf =3D 0, rc; > > static int count_1 =3D 0; > > static int count_2 =3D 0; > >=20 > > if ( p->size > 8 ) > > { > > gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->si= ze); > > return X86EMUL_UNHANDLEABLE; > > } > >=20 > > spin_lock(&s->lock); > >=20 > > if ( s->stdvga && s->cache ) > > { > > switch ( p->type ) > > { > > case IOREQ_TYPE_COPY: > > buf =3D mmio_move(s, p); > > count_1++; > > if (count_1 % 1000 =3D=3D 0) > > gdprintk(XENLOG_WARNING, " =3Duvp=3D enter mmio_move, > > count_1=3D%d\n", count_1); > > if ( !buf ) > > s->cache =3D 0; > > break; > > default: > > gdprintk(XENLOG_WARNING, "unsupported mmio request > > type:%d " > > "addr:0x%04x data:0x%04x size:%d count:%d > > state:%d " > > "isptr:%d dir:%d df:%d\n", > > p->type, (int)p->addr, (int)p->data, (int)p->siz= e, > > (int)p->count, p->state, > > p->data_is_ptr, p->dir, p->df); > > s->cache =3D 0; > > } > > } > > else > > { > > buf =3D (p->dir =3D=3D IOREQ_WRITE); > > count_2++; > > if (count_2 % 5000 =3D=3D 0) > > gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=3D%d\n", > > count_2); > > } > >=20 > > rc =3D (buf && hvm_buffered_io_send(p)); > >=20 > > spin_unlock(&s->lock); > >=20 > > return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE; > > } > >=20 > > and I got the below result with upstream qemu and tranditional qemu-d= m: > >=20 > > 1) traditional qemu-dm: > > (XEN) stdvga.c:152:d2 entering stdvga and caching modes > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D460000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D461000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D462000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D463000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D464000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D465000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D466000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D467000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D468000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D469000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D470000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D471000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D472000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D473000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D474000 > > (XEN) stdvga.c:577:d2 =3Duvp=3D enter mmio_move, count_1=3D475000 > > (XEN) stdvga.c:156:d2 leaving stdvga > >=20 > > 2) upstream qemu: > > (XEN) stdvga.c:152:d1 entering stdvga and caching modes > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D233000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D234000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D235000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D236000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D237000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D238000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D239000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D240000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D241000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D242000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D243000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D244000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D245000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D246000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D247000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D248000 > > (XEN) stdvga.c:577:d1 =3Duvp=3D enter mmio_move, count_1=3D249000 > > (XEN) stdvga.c:156:d1 leaving stdvga > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D8400000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D8405000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D8410000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D8415000 > > ... ... //Omit some similar > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D12570000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D12575000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D12580000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D12585000 > > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=3D12590000 > >=20 > > Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000 > > than traditional qemu-dm. > >=20 > > Best Regards! > >=20 > > -Gonglei > >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel