* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
@ 2013-07-30 2:01 ` Gonglei (Arei)
2013-07-30 2:01 ` [Qemu-devel] " Gonglei (Arei)
` (4 subsequent siblings)
5 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-07-30 2:01 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: aliguori, Hanweidong, Ian.Jackson, Luonengjun, qemu-devel,
xen-devel, Gerd Hoffmann, Anthony Liguori, Andreas Färber,
Huangweidong (Hardware)
> On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > -----Original Message-----
> > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > Sent: Saturday, July 27, 2013 7:51 PM
> > > To: Gerd Hoffmann
> > > Cc: Andreas Färber; Hanweidong; Luonengjun; qemu-devel@nongnu.org;
> > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > (Hardware)
> > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > > blank screen last 13s or so for windows XP guest
> > >
> > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > >
> > > > Maybe the xen guys did some optimizations in qemu-dm which where not
> > > > merged upstream. Try asking @ xen-devel.
> > > >
> > >
> > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > upstream qemu.
> >
> > Hi, Pasi. Would you give me some more details? Thanks!
> >
>
> Unfortunately I don't have any more details.. I was just assuming if xen
> qemu-dm is fast,
> but upstream qemu is slow, there might be some optimization in xen
> qemu-dm ..
>
> Did you check the xen qemu-dm (traditional) history / commits?
>
> -- Pasi
Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history commit.
But the qemu-dm mainline merged other branches, such as branch 'upstream' and branch 'qemu',
so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and Anthony.
-Gonglei
>
> > -Gonglei
> >
> > > > Beside that the standard vga usually is the better choice anyway as it
> > > > supports more video memory and higher resolutions than cirrus.
> > > >
> > >
> > > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > > Is there one for the emulated stdvga adapter?
> > >
> > > -- Pasi
> >
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
@ 2013-07-30 2:01 ` Gonglei (Arei)
2013-08-16 9:09 ` Gonglei (Arei)
` (3 subsequent siblings)
5 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-07-30 2:01 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: aliguori, Hanweidong, Ian.Jackson, Luonengjun, qemu-devel,
xen-devel, Gerd Hoffmann, Anthony Liguori, Andreas Färber,
Huangweidong (Hardware)
> On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > -----Original Message-----
> > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > Sent: Saturday, July 27, 2013 7:51 PM
> > > To: Gerd Hoffmann
> > > Cc: Andreas Färber; Hanweidong; Luonengjun; qemu-devel@nongnu.org;
> > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > (Hardware)
> > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > > blank screen last 13s or so for windows XP guest
> > >
> > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > >
> > > > Maybe the xen guys did some optimizations in qemu-dm which where not
> > > > merged upstream. Try asking @ xen-devel.
> > > >
> > >
> > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > upstream qemu.
> >
> > Hi, Pasi. Would you give me some more details? Thanks!
> >
>
> Unfortunately I don't have any more details.. I was just assuming if xen
> qemu-dm is fast,
> but upstream qemu is slow, there might be some optimization in xen
> qemu-dm ..
>
> Did you check the xen qemu-dm (traditional) history / commits?
>
> -- Pasi
Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history commit.
But the qemu-dm mainline merged other branches, such as branch 'upstream' and branch 'qemu',
so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and Anthony.
-Gonglei
>
> > -Gonglei
> >
> > > > Beside that the standard vga usually is the better choice anyway as it
> > > > supports more video memory and higher resolutions than cirrus.
> > > >
> > >
> > > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > > Is there one for the emulated stdvga adapter?
> > >
> > > -- Pasi
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
2013-07-30 2:01 ` [Qemu-devel] " Gonglei (Arei)
@ 2013-08-16 9:09 ` Gonglei (Arei)
2013-08-16 9:09 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
` (2 subsequent siblings)
5 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-16 9:09 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen
Cc: Hanweidong, Ian.Jackson, Yanqiangjun, Luonengjun, qemu-devel,
xen-devel, Yangxiaowei, Gerd Hoffmann, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
Hi, all
I compared the traditional qemu-dm and upstream qemu,
and I found the upstream qemu will create the expansion ROM at f3000000, but qemu-dm don't.
the details as below (by "lspci -vnnn"):
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=32M]
Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
Kernel modules: cirrusfb
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=32M]
Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f3000000 [disabled] [size=64K]
Kernel modules: cirrusfb
I tried to simply delete the expansion ROM at function pci_add_option_rom, such as
//pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
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！
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 = current->domain;
struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
int buf = 0, rc;
static int count_1 = 0;
static int count_2 = 0;
if ( p->size > 8 )
{
gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
return X86EMUL_UNHANDLEABLE;
}
spin_lock(&s->lock);
if ( s->stdvga && s->cache )
{
switch ( p->type )
{
case IOREQ_TYPE_COPY:
buf = mmio_move(s, p);
count_1++;
if (count_1 % 1000 == 0)
gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move, count_1=%d\n", count_1);
if ( !buf )
s->cache = 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->size,
(int)p->count, p->state,
p->data_is_ptr, p->dir, p->df);
s->cache = 0;
}
}
else
{
buf = (p->dir == IOREQ_WRITE);
count_2++;
if (count_2 % 5000 == 0)
gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n", count_2);
}
rc = (buf && hvm_buffered_io_send(p));
spin_unlock(&s->lock);
return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
}
and I got the below result with upstream qemu and tranditional qemu-dm:
1) traditional qemu-dm:
(XEN) stdvga.c:152:d2 entering stdvga and caching modes
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
(XEN) stdvga.c:156:d2 leaving stdvga
2) upstream qemu:
(XEN) stdvga.c:152:d1 entering stdvga and caching modes
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
(XEN) stdvga.c:156:d1 leaving stdvga
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
... ... //Omit some similar
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000 than traditional qemu-dm.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Monday, August 05, 2013 8:50 PM
> To: 'Gonglei (Arei)'; 'Pasi Kärkkäinen'
> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; 'Hanweidong'; 'Luonengjun';
> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> 'Huangweidong (Hardware)'; 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori'
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi,
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Tuesday, July 30, 2013 10:01 AM
> > To: 'Pasi Kärkkäinen'
> > Cc: Gerd Hoffmann; Andreas Färber; Hanweidong; Luonengjun;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori;
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori;
> > 'aliguori@us.ibm.com'
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > > On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > > > -----Original Message-----
> > > > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > > > Sent: Saturday, July 27, 2013 7:51 PM
> > > > > To: Gerd Hoffmann
> > > > > Cc: Andreas Färber; Hanweidong; Luonengjun;
> qemu-devel@nongnu.org;
> > > > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > > > (Hardware)
> > > > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update,
> > show
> > > > > blank screen last 13s or so for windows XP guest
> > > > >
> > > > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > > > >
> > > > > > Maybe the xen guys did some optimizations in qemu-dm which where
> > not
> > > > > > merged upstream. Try asking @ xen-devel.
> > > > > >
> > > > >
> > > > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > > > upstream qemu.
> > > >
> > > > Hi, Pasi. Would you give me some more details? Thanks!
> > > >
> > >
> > > Unfortunately I don't have any more details.. I was just assuming if xen
> > > qemu-dm is fast,
> > > but upstream qemu is slow, there might be some optimization in xen
> > > qemu-dm ..
> > >
> > > Did you check the xen qemu-dm (traditional) history / commits?
> > >
> > > -- Pasi
> >
> > Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history
> > commit.
> > But the qemu-dm mainline merged other branches, such as branch
> 'upstream'
> > and branch 'qemu',
> > so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and
> > Anthony.
> >
> By analyzing xentrace data, I found that there is lot's of VMEXIT between
> memory region 0xa0000~0xaffff with upstream qemu,
> but only 256 VMEXIT on traditional qemu-dm, when Windows XP guest booting
> up or change the method connecting the VM from VNC(RDP) to RDP(VNC):
>
> linux-sAGhxH:# cat qemu-upstrem.log |grep 0x00000000000a|wc -l
> 640654
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a|wc -l
> 256
> And the 256 VMEXIT of qemu-dm as the same as the top 256 VMEXIT of
> qemu-upstream
>
> linux-sAGhxH:# cat qemu-upstream.log |grep 0x00000000000a| tail
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b08 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0c mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0e mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b10 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b12 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b14 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b16 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b18 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b1a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ec0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ee0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f00 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f20 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f40 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f60 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f80 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fa0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fc0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fe0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
>
> Please see attachment for more information.
>
> Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive
> little scheduling,
> and cirrus_vga_write_gr execution interval of more than 32ms twice per, so
> that the blank screen time over 13 second with upstream qemu on Xen.
> I don't know why the Windows XP guest access the memory region
> 0xa0000~0xaffff with upstream qemu but with traditional qemu-dm is not,
> Anyone can give me some suggestion?
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (2 preceding siblings ...)
2013-08-16 9:09 ` Gonglei (Arei)
@ 2013-08-16 9:09 ` Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-16 9:09 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen
Cc: Hanweidong, Ian.Jackson, Yanqiangjun, Luonengjun, qemu-devel,
xen-devel, Yangxiaowei, Gerd Hoffmann, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
Hi, all
I compared the traditional qemu-dm and upstream qemu,
and I found the upstream qemu will create the expansion ROM at f3000000, but qemu-dm don't.
the details as below (by "lspci -vnnn"):
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=32M]
Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
Kernel modules: cirrusfb
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=32M]
Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f3000000 [disabled] [size=64K]
Kernel modules: cirrusfb
I tried to simply delete the expansion ROM at function pci_add_option_rom, such as
//pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
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！
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 = current->domain;
struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
int buf = 0, rc;
static int count_1 = 0;
static int count_2 = 0;
if ( p->size > 8 )
{
gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
return X86EMUL_UNHANDLEABLE;
}
spin_lock(&s->lock);
if ( s->stdvga && s->cache )
{
switch ( p->type )
{
case IOREQ_TYPE_COPY:
buf = mmio_move(s, p);
count_1++;
if (count_1 % 1000 == 0)
gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move, count_1=%d\n", count_1);
if ( !buf )
s->cache = 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->size,
(int)p->count, p->state,
p->data_is_ptr, p->dir, p->df);
s->cache = 0;
}
}
else
{
buf = (p->dir == IOREQ_WRITE);
count_2++;
if (count_2 % 5000 == 0)
gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n", count_2);
}
rc = (buf && hvm_buffered_io_send(p));
spin_unlock(&s->lock);
return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
}
and I got the below result with upstream qemu and tranditional qemu-dm:
1) traditional qemu-dm:
(XEN) stdvga.c:152:d2 entering stdvga and caching modes
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
(XEN) stdvga.c:156:d2 leaving stdvga
2) upstream qemu:
(XEN) stdvga.c:152:d1 entering stdvga and caching modes
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
(XEN) stdvga.c:156:d1 leaving stdvga
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
... ... //Omit some similar
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000 than traditional qemu-dm.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Monday, August 05, 2013 8:50 PM
> To: 'Gonglei (Arei)'; 'Pasi Kärkkäinen'
> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; 'Hanweidong'; 'Luonengjun';
> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> 'Huangweidong (Hardware)'; 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori'
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi,
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Tuesday, July 30, 2013 10:01 AM
> > To: 'Pasi Kärkkäinen'
> > Cc: Gerd Hoffmann; Andreas Färber; Hanweidong; Luonengjun;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori;
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori;
> > 'aliguori@us.ibm.com'
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > > On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > > > -----Original Message-----
> > > > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > > > Sent: Saturday, July 27, 2013 7:51 PM
> > > > > To: Gerd Hoffmann
> > > > > Cc: Andreas Färber; Hanweidong; Luonengjun;
> qemu-devel@nongnu.org;
> > > > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > > > (Hardware)
> > > > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update,
> > show
> > > > > blank screen last 13s or so for windows XP guest
> > > > >
> > > > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > > > >
> > > > > > Maybe the xen guys did some optimizations in qemu-dm which where
> > not
> > > > > > merged upstream. Try asking @ xen-devel.
> > > > > >
> > > > >
> > > > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > > > upstream qemu.
> > > >
> > > > Hi, Pasi. Would you give me some more details? Thanks!
> > > >
> > >
> > > Unfortunately I don't have any more details.. I was just assuming if xen
> > > qemu-dm is fast,
> > > but upstream qemu is slow, there might be some optimization in xen
> > > qemu-dm ..
> > >
> > > Did you check the xen qemu-dm (traditional) history / commits?
> > >
> > > -- Pasi
> >
> > Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history
> > commit.
> > But the qemu-dm mainline merged other branches, such as branch
> 'upstream'
> > and branch 'qemu',
> > so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and
> > Anthony.
> >
> By analyzing xentrace data, I found that there is lot's of VMEXIT between
> memory region 0xa0000~0xaffff with upstream qemu,
> but only 256 VMEXIT on traditional qemu-dm, when Windows XP guest booting
> up or change the method connecting the VM from VNC(RDP) to RDP(VNC):
>
> linux-sAGhxH:# cat qemu-upstrem.log |grep 0x00000000000a|wc -l
> 640654
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a|wc -l
> 256
> And the 256 VMEXIT of qemu-dm as the same as the top 256 VMEXIT of
> qemu-upstream
>
> linux-sAGhxH:# cat qemu-upstream.log |grep 0x00000000000a| tail
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b08 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0c mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0e mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b10 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b12 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b14 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b16 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b18 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b1a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ec0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ee0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f00 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f20 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f40 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f60 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f80 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fa0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fc0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fe0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
>
> Please see attachment for more information.
>
> Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive
> little scheduling,
> and cirrus_vga_write_gr execution interval of more than 32ms twice per, so
> that the blank screen time over 13 second with upstream qemu on Xen.
> I don't know why the Windows XP guest access the memory region
> 0xa0000~0xaffff with upstream qemu but with traditional qemu-dm is not,
> Anyone can give me some suggestion?
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (3 preceding siblings ...)
2013-08-16 9:09 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
@ 2013-08-17 9:04 ` Gonglei (Arei)
2013-08-20 19:45 ` [Qemu-devel] " Konrad Rzeszutek Wilk
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 2 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-17 9:04 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen, vgabios-developers
Cc: ggrebus, bguthro, Hanweidong, Ian.Jackson, Yanqiangjun,
Luonengjun, qemu-devel, xen-devel, Yangxiaowei, Gerd Hoffmann,
Anthony Liguori, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
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,
but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
the pivotal patch is :
# HG changeset patch
# User Keir Fraser <keir@xensource.com>
# Date 1193391667 -3600
# Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
# Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
Signed-off-by: Ben Guthro <bguthro@virtualron.com>
Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
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 changing
+;; 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
+ 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 @@
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 addr, uint32_t val);
/***************************************
*
@@ -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] = reg_value; // Lower byte of value to be written
+ break;
+ case 0xFF: {
+ target_phys_addr_t addr;
+ for (addr = 0xa0000; addr < 0xa4000; addr += 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,
By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
And I test the latest vgabios-0.7a come from
http://www.nongnu.org/vgabios/#DOWNLOAD
but the problem of blank screen remain.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, August 16, 2013 5:10 PM
> To: Gonglei (Arei); 'Pasi Kärkkäinen'
> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
> Yanqiangjun; Yangxiaowei
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi, all
> I compared the traditional qemu-dm and upstream qemu,
> and I found the upstream qemu will create the expansion ROM at f3000000,
> but qemu-dm don't.
> the details as below (by "lspci -vnnn"):
>
> 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=32M]
> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> Kernel modules: cirrusfb
>
> 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=32M]
> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at f3000000 [disabled] [size=64K]
> Kernel modules: cirrusfb
>
> I tried to simply delete the expansion ROM at function pci_add_option_rom,
> such as
>
> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>
> 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！
>
> 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 = current->domain;
> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> int buf = 0, rc;
> static int count_1 = 0;
> static int count_2 = 0;
>
> if ( p->size > 8 )
> {
> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> return X86EMUL_UNHANDLEABLE;
> }
>
> spin_lock(&s->lock);
>
> if ( s->stdvga && s->cache )
> {
> switch ( p->type )
> {
> case IOREQ_TYPE_COPY:
> buf = mmio_move(s, p);
> count_1++;
> if (count_1 % 1000 == 0)
> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> count_1=%d\n", count_1);
> if ( !buf )
> s->cache = 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->size,
> (int)p->count, p->state,
> p->data_is_ptr, p->dir, p->df);
> s->cache = 0;
> }
> }
> else
> {
> buf = (p->dir == IOREQ_WRITE);
> count_2++;
> if (count_2 % 5000 == 0)
> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> count_2);
> }
>
> rc = (buf && hvm_buffered_io_send(p));
>
> spin_unlock(&s->lock);
>
> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> }
>
> and I got the below result with upstream qemu and tranditional qemu-dm:
>
> 1) traditional qemu-dm:
> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> (XEN) stdvga.c:156:d2 leaving stdvga
>
> 2) upstream qemu:
> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> (XEN) stdvga.c:156:d1 leaving stdvga
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> ... ... //Omit some similar
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>
> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> than traditional qemu-dm.
>
> Best Regards!
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-17 9:04 ` Gonglei (Arei)
@ 2013-08-20 19:45 ` Konrad Rzeszutek Wilk
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
1 sibling, 0 replies; 50+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-08-20 19:45 UTC (permalink / raw)
To: Gonglei (Arei), benjamin.guthro
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian.Jackson, qemu-devel, xen-devel, bguthro,
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
Andreas Färber, 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,
> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>
> the pivotal patch is :
>
> # HG changeset patch
> # User Keir Fraser <keir@xensource.com>
> # Date 1193391667 -3600
> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>
> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>
> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> 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 changing
> +;; 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
> + 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 @@
>
> 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 addr, uint32_t val);
>
> /***************************************
> *
> @@ -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] = reg_value; // Lower byte of value to be written
> + break;
> + case 0xFF: {
> + target_phys_addr_t addr;
> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
>
> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>
> And I test the latest vgabios-0.7a come from
> http://www.nongnu.org/vgabios/#DOWNLOAD
> but the problem of blank screen remain.
>
> Best Regards!
> -Gonglei
>
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Friday, August 16, 2013 5:10 PM
> > To: Gonglei (Arei); 'Pasi Kärkkäinen'
> > Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
> > 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
> > Yanqiangjun; Yangxiaowei
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > Hi, all
> > I compared the traditional qemu-dm and upstream qemu,
> > and I found the upstream qemu will create the expansion ROM at f3000000,
> > but qemu-dm don't.
> > the details as below (by "lspci -vnnn"):
> >
> > 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=32M]
> > Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> > Kernel modules: cirrusfb
> >
> > 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=32M]
> > Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> > Expansion ROM at f3000000 [disabled] [size=64K]
> > Kernel modules: cirrusfb
> >
> > I tried to simply delete the expansion ROM at function pci_add_option_rom,
> > such as
> >
> > //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
> >
> > 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！
> >
> > 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 = current->domain;
> > struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> > int buf = 0, rc;
> > static int count_1 = 0;
> > static int count_2 = 0;
> >
> > if ( p->size > 8 )
> > {
> > gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> > return X86EMUL_UNHANDLEABLE;
> > }
> >
> > spin_lock(&s->lock);
> >
> > if ( s->stdvga && s->cache )
> > {
> > switch ( p->type )
> > {
> > case IOREQ_TYPE_COPY:
> > buf = mmio_move(s, p);
> > count_1++;
> > if (count_1 % 1000 == 0)
> > gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> > count_1=%d\n", count_1);
> > if ( !buf )
> > s->cache = 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->size,
> > (int)p->count, p->state,
> > p->data_is_ptr, p->dir, p->df);
> > s->cache = 0;
> > }
> > }
> > else
> > {
> > buf = (p->dir == IOREQ_WRITE);
> > count_2++;
> > if (count_2 % 5000 == 0)
> > gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> > count_2);
> > }
> >
> > rc = (buf && hvm_buffered_io_send(p));
> >
> > spin_unlock(&s->lock);
> >
> > return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> > }
> >
> > and I got the below result with upstream qemu and tranditional qemu-dm:
> >
> > 1) traditional qemu-dm:
> > (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> > (XEN) stdvga.c:156:d2 leaving stdvga
> >
> > 2) upstream qemu:
> > (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> > (XEN) stdvga.c:156:d1 leaving stdvga
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> > ... ... //Omit some similar
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
> >
> > Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> > than traditional qemu-dm.
> >
> > Best Regards!
> >
> > -Gonglei
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-17 9:04 ` Gonglei (Arei)
2013-08-20 19:45 ` [Qemu-devel] " Konrad Rzeszutek Wilk
@ 2013-08-20 19:45 ` Konrad Rzeszutek Wilk
2013-08-21 0:02 ` [Qemu-devel] " Ben Guthro
1 sibling, 1 reply; 50+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-08-20 19:45 UTC (permalink / raw)
To: Gonglei (Arei), benjamin.guthro
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian.Jackson, qemu-devel, Pasi Kärkkäinen,
xen-devel, bguthro, Gerd Hoffmann, Anthony Liguori, Luonengjun,
keir.fraser, Andreas Färber, 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,
> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>
> the pivotal patch is :
>
> # HG changeset patch
> # User Keir Fraser <keir@xensource.com>
> # Date 1193391667 -3600
> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>
> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>
> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> 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 changing
> +;; 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
> + 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 @@
>
> 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 addr, uint32_t val);
>
> /***************************************
> *
> @@ -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] = reg_value; // Lower byte of value to be written
> + break;
> + case 0xFF: {
> + target_phys_addr_t addr;
> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
>
> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>
> And I test the latest vgabios-0.7a come from
> http://www.nongnu.org/vgabios/#DOWNLOAD
> but the problem of blank screen remain.
>
> Best Regards!
> -Gonglei
>
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Friday, August 16, 2013 5:10 PM
> > To: Gonglei (Arei); 'Pasi Kärkkäinen'
> > Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
> > 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
> > Yanqiangjun; Yangxiaowei
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > Hi, all
> > I compared the traditional qemu-dm and upstream qemu,
> > and I found the upstream qemu will create the expansion ROM at f3000000,
> > but qemu-dm don't.
> > the details as below (by "lspci -vnnn"):
> >
> > 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=32M]
> > Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> > Kernel modules: cirrusfb
> >
> > 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=32M]
> > Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> > Expansion ROM at f3000000 [disabled] [size=64K]
> > Kernel modules: cirrusfb
> >
> > I tried to simply delete the expansion ROM at function pci_add_option_rom,
> > such as
> >
> > //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
> >
> > 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！
> >
> > 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 = current->domain;
> > struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> > int buf = 0, rc;
> > static int count_1 = 0;
> > static int count_2 = 0;
> >
> > if ( p->size > 8 )
> > {
> > gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> > return X86EMUL_UNHANDLEABLE;
> > }
> >
> > spin_lock(&s->lock);
> >
> > if ( s->stdvga && s->cache )
> > {
> > switch ( p->type )
> > {
> > case IOREQ_TYPE_COPY:
> > buf = mmio_move(s, p);
> > count_1++;
> > if (count_1 % 1000 == 0)
> > gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> > count_1=%d\n", count_1);
> > if ( !buf )
> > s->cache = 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->size,
> > (int)p->count, p->state,
> > p->data_is_ptr, p->dir, p->df);
> > s->cache = 0;
> > }
> > }
> > else
> > {
> > buf = (p->dir == IOREQ_WRITE);
> > count_2++;
> > if (count_2 % 5000 == 0)
> > gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> > count_2);
> > }
> >
> > rc = (buf && hvm_buffered_io_send(p));
> >
> > spin_unlock(&s->lock);
> >
> > return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> > }
> >
> > and I got the below result with upstream qemu and tranditional qemu-dm:
> >
> > 1) traditional qemu-dm:
> > (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> > (XEN) stdvga.c:156:d2 leaving stdvga
> >
> > 2) upstream qemu:
> > (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> > (XEN) stdvga.c:156:d1 leaving stdvga
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> > ... ... //Omit some similar
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
> >
> > Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> > than traditional qemu-dm.
> >
> > Best Regards!
> >
> > -Gonglei
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
@ 2013-08-21 0:02 ` Ben Guthro
0 siblings, 0 replies; 50+ messages in thread
From: Ben Guthro @ 2013-08-21 0:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Pasi Kärkkäinen,
Ben Guthro, bguthro, Gonglei (Arei),
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
xen-devel, Andreas Färber, Huangweidong (Hardware)
On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote:
> 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,
>> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>>
>> the pivotal patch is :
>>
>> # HG changeset patch
>> # User Keir Fraser <keir@xensource.com>
>> # Date 1193391667 -3600
>> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
>> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>>
>> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>>
>> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
>> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
>
> Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
FWIW, I took Gary's patch, and made it apply to unstable, at that time.
He was the primary developer, in that case.
That's how I recall it, anyhow...from 6 years ago.
I don't have Gary's new contact info.
Regards,
Ben
>
>>
>> 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 changing
>> +;; 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
>> + 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 @@
>>
>> 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 addr, uint32_t val);
>>
>> /***************************************
>> *
>> @@ -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] = reg_value; // Lower byte of value to be written
>> + break;
>> + case 0xFF: {
>> + target_phys_addr_t addr;
>> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
>>
>> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>>
>> And I test the latest vgabios-0.7a come from
>> http://www.nongnu.org/vgabios/#DOWNLOAD
>> but the problem of blank screen remain.
>>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); 'Pasi Kärkkäinen'
>>> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
>>> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
>>> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 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=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 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=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> 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！
>>>
>>> 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 = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 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->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-08-21 0:02 ` Ben Guthro
0 siblings, 0 replies; 50+ messages in thread
From: Ben Guthro @ 2013-08-21 0:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Ben Guthro, bguthro,
Gonglei (Arei),
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
xen-devel, Andreas Färber, Huangweidong (Hardware)
On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote:
> 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,
>> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>>
>> the pivotal patch is :
>>
>> # HG changeset patch
>> # User Keir Fraser <keir@xensource.com>
>> # Date 1193391667 -3600
>> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
>> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>>
>> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>>
>> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
>> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
>
> Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
FWIW, I took Gary's patch, and made it apply to unstable, at that time.
He was the primary developer, in that case.
That's how I recall it, anyhow...from 6 years ago.
I don't have Gary's new contact info.
Regards,
Ben
>
>>
>> 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 changing
>> +;; 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
>> + 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 @@
>>
>> 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 addr, uint32_t val);
>>
>> /***************************************
>> *
>> @@ -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] = reg_value; // Lower byte of value to be written
>> + break;
>> + case 0xFF: {
>> + target_phys_addr_t addr;
>> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
>>
>> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>>
>> And I test the latest vgabios-0.7a come from
>> http://www.nongnu.org/vgabios/#DOWNLOAD
>> but the problem of blank screen remain.
>>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); 'Pasi Kärkkäinen'
>>> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
>>> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
>>> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 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=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 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=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> 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！
>>>
>>> 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 = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 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->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-21 0:02 ` [Qemu-devel] " Ben Guthro
@ 2013-08-27 15:08 ` Gonglei (Arei)
-1 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-27 15:08 UTC (permalink / raw)
To: Ben Guthro, Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, seabios, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Pasi Kärkkäinen,
xen-devel, bguthro, kevin, Gerd Hoffmann, Anthony Liguori,
Luonengjun, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
[-- Attachment #1: Type: text/plain, Size: 11727 bytes --]
Hi all.
I got another trouble after I using that patch, which windows 2003 32bit guest VNC display wasn't normal,
please see the attached. In addition, windows 2003 64bit guest had a normal display.
I couldn't understand it, anyone can help me? Thanks you in advance.
The patch is:
http://xen.1045712.n5.nabble.com/PATCH-QEMU-Clear-bios-framebuffer-with-minimal-writes-td2511735.html
Best Regards,
-Gonglei
> -----Original Message-----
> Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
>
> On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>
> wrote:
>
> > 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,
> >> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
> >>
> >> the pivotal patch is :
> >>
> >> # HG changeset patch
> >> # User Keir Fraser <keir@xensource.com>
> >> # Date 1193391667 -3600
> >> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> >> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
> >>
> >> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO
> writes.
> >>
> >> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> >> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
> >
> > Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> FWIW, I took Gary's patch, and made it apply to unstable, at that time.
> He was the primary developer, in that case.
>
> That's how I recall it, anyhow...from 6 years ago.
>
> I don't have Gary's new contact info.
>
> Regards,
> Ben
>
> >
> >>
> >> 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
> changing
> >> +;; 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
> >> + 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 @@
> >>
> >> 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
> addr, uint32_t val);
> >>
> >> /***************************************
> >> *
> >> @@ -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] = reg_value; // Lower byte of value to be written
> >> + break;
> >> + case 0xFF: {
> >> + target_phys_addr_t addr;
> >> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
> >>
> >> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is
> fast with upstream qemu.
> >>
> >> And I test the latest vgabios-0.7a come from
> >> http://www.nongnu.org/vgabios/#DOWNLOAD
> >> but the problem of blank screen remain.
> >>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); 'Pasi Kärkkäinen'
>>> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
>>> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
>>> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 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=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 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=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> 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！
>>>
>>> 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 = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 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->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
[-- Attachment #2: win2003.jpg --]
[-- Type: image/jpeg, Size: 143573 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-08-27 15:08 ` Gonglei (Arei)
0 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-27 15:08 UTC (permalink / raw)
To: Ben Guthro, Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, seabios, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, xen-devel, bguthro, kevin,
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
Andreas Färber, Huangweidong (Hardware)
[-- Attachment #1: Type: text/plain, Size: 11727 bytes --]
Hi all.
I got another trouble after I using that patch, which windows 2003 32bit guest VNC display wasn't normal,
please see the attached. In addition, windows 2003 64bit guest had a normal display.
I couldn't understand it, anyone can help me? Thanks you in advance.
The patch is:
http://xen.1045712.n5.nabble.com/PATCH-QEMU-Clear-bios-framebuffer-with-minimal-writes-td2511735.html
Best Regards,
-Gonglei
> -----Original Message-----
> Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
>
> On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>
> wrote:
>
> > 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,
> >> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
> >>
> >> the pivotal patch is :
> >>
> >> # HG changeset patch
> >> # User Keir Fraser <keir@xensource.com>
> >> # Date 1193391667 -3600
> >> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> >> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
> >>
> >> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO
> writes.
> >>
> >> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> >> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
> >
> > Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> FWIW, I took Gary's patch, and made it apply to unstable, at that time.
> He was the primary developer, in that case.
>
> That's how I recall it, anyhow...from 6 years ago.
>
> I don't have Gary's new contact info.
>
> Regards,
> Ben
>
> >
> >>
> >> 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
> changing
> >> +;; 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
> >> + 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 @@
> >>
> >> 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
> addr, uint32_t val);
> >>
> >> /***************************************
> >> *
> >> @@ -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] = reg_value; // Lower byte of value to be written
> >> + break;
> >> + case 0xFF: {
> >> + target_phys_addr_t addr;
> >> + for (addr = 0xa0000; addr < 0xa4000; addr += 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,
> >>
> >> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is
> fast with upstream qemu.
> >>
> >> And I test the latest vgabios-0.7a come from
> >> http://www.nongnu.org/vgabios/#DOWNLOAD
> >> but the problem of blank screen remain.
> >>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); 'Pasi Kärkkäinen'
>>> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
>>> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
>>> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 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=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 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=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> 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！
>>>
>>> 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 = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 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->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
[-- Attachment #2: win2003.jpg --]
[-- Type: image/jpeg, Size: 143573 bytes --]
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (4 preceding siblings ...)
2013-08-17 9:04 ` Gonglei (Arei)
@ 2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 0 replies; 50+ messages in thread
From: Gonglei (Arei) @ 2013-08-17 9:04 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen, vgabios-developers
Cc: ggrebus, bguthro, Hanweidong, Ian.Jackson, Yanqiangjun,
Luonengjun, qemu-devel, xen-devel, Yangxiaowei, Gerd Hoffmann,
Anthony Liguori, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
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,
but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
the pivotal patch is :
# HG changeset patch
# User Keir Fraser <keir@xensource.com>
# Date 1193391667 -3600
# Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
# Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
Signed-off-by: Ben Guthro <bguthro@virtualron.com>
Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
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 changing
+;; 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
+ 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 @@
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 addr, uint32_t val);
/***************************************
*
@@ -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] = reg_value; // Lower byte of value to be written
+ break;
+ case 0xFF: {
+ target_phys_addr_t addr;
+ for (addr = 0xa0000; addr < 0xa4000; addr += 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,
By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
And I test the latest vgabios-0.7a come from
http://www.nongnu.org/vgabios/#DOWNLOAD
but the problem of blank screen remain.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, August 16, 2013 5:10 PM
> To: Gonglei (Arei); 'Pasi Kärkkäinen'
> Cc: 'Gerd Hoffmann'; 'Andreas Färber'; Hanweidong; Luonengjun;
> 'qemu-devel@nongnu.org'; 'xen-devel@lists.xen.org'; 'Anthony Liguori';
> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; 'Anthony Liguori';
> Yanqiangjun; Yangxiaowei
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi, all
> I compared the traditional qemu-dm and upstream qemu,
> and I found the upstream qemu will create the expansion ROM at f3000000,
> but qemu-dm don't.
> the details as below (by "lspci -vnnn"):
>
> 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=32M]
> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> Kernel modules: cirrusfb
>
> 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=32M]
> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at f3000000 [disabled] [size=64K]
> Kernel modules: cirrusfb
>
> I tried to simply delete the expansion ROM at function pci_add_option_rom,
> such as
>
> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>
> 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！
>
> 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 = current->domain;
> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> int buf = 0, rc;
> static int count_1 = 0;
> static int count_2 = 0;
>
> if ( p->size > 8 )
> {
> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> return X86EMUL_UNHANDLEABLE;
> }
>
> spin_lock(&s->lock);
>
> if ( s->stdvga && s->cache )
> {
> switch ( p->type )
> {
> case IOREQ_TYPE_COPY:
> buf = mmio_move(s, p);
> count_1++;
> if (count_1 % 1000 == 0)
> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> count_1=%d\n", count_1);
> if ( !buf )
> s->cache = 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->size,
> (int)p->count, p->state,
> p->data_is_ptr, p->dir, p->df);
> s->cache = 0;
> }
> }
> else
> {
> buf = (p->dir == IOREQ_WRITE);
> count_2++;
> if (count_2 % 5000 == 0)
> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> count_2);
> }
>
> rc = (buf && hvm_buffered_io_send(p));
>
> spin_unlock(&s->lock);
>
> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> }
>
> and I got the below result with upstream qemu and tranditional qemu-dm:
>
> 1) traditional qemu-dm:
> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> (XEN) stdvga.c:156:d2 leaving stdvga
>
> 2) upstream qemu:
> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> (XEN) stdvga.c:156:d1 leaving stdvga
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> ... ... //Omit some similar
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>
> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> than traditional qemu-dm.
>
> Best Regards!
>
> -Gonglei
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
![[-- Attachment #2: win2003.jpg --] [-- Type: image/jpeg, Size: 143573 bytes --]](../../33183CC9F5247A488A2544077AF190208159411B@SZXEMA503-MBS.china.huawei.com/2-win2003.jpg){kind=link}