Re: [Xen-devel] [PATCH] Std VGA Performance

["Robert Phillips" <rsp.vi.xen@xxxxxxxxx>]

Good questions, Keir.  Answers below:

On 10/25/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:

On 24/10/07 22:36, "Ben Guthro" <bguthro@xxxxxxxxxxxxxxx > wrote:

> This patch improves the performance of Standard VGA,
> the mode used during Windows boot and by the Linux
> splash screen.
>
> It does so by buffering all the stdvga programmed output ops
> and memory mapped ops (both reads and writes) that are sent to QEMU.

How much benefit comes from immediate servicing of PIO input ops versus the
massive increase in buffered-io slots? Removing the former optimisation
would certainly make the patch a lot smaller!

Subjectively, the performance improvement appears substantial.  We have tested the code with the stdvga emulation and with and without the increased number of slots. With more slots the screen painting goes from being fast to very fast.

As you've noticed, the increase in number of slots is compensated by the decrease in slot size (so there is no increase in memory use) at the cost of packing (and unpacking) ioreqs as they are written to (and read from) the buffer.

What happens across save/restore? The hypervisor's state cache will go away,
won't it? I suppose it's okay if the guest is in SVGA LFB mode at that point
(actually, that's another thing - do you correctly handle hand-off between
VGA and SVGA modes), but I don't know that we want to rely on that.

This hasn't been a problem in practice.  The guest quickly switches from
VGA to SVGA mode causing the stdvga code to be largely inactive,
and we have only seen it switch back when the guest blue-screens.
The stdvga code detects that transition correctly and paints the blue-screen quickly.

After a restore, the code assumes it is not in standard VGA mode so is largely inactive. 
That conservative assumption might not be optimal but it is correct.

I don't believe the failure to save/restore the stdvga cache will prove problematic but
if it becomes so I will add corrective code.

One might ask (and we did) what is the point of all this VGA emulation code when it is only
active during the boot process (or during blue-screen painting).

The answer is that one wants the user's first experience with Xen to be positive;
as watching an excruciatingly slow Windows boot screen or Linux splash panel is not.
 
-- rsp

-- Keir

> We maintain locally essential VGA state so we can respond
> immediately to input and read ops without waiting for
> QEMU.  We snoop output and write ops to keep our state
> up-to-date.
>
> PIO input ops are satisfied from cached state without
> bothering QEMU.
>
> PIO output and mmio ops are passed through to QEMU, including
> mmio read ops.  This is necessary because mmio reads
> can have side effects.
>
> I have changed the format of the buffered_iopage.
> It used to contain 80 elements of type ioreq_t (48 bytes each).
> Now it contains 672 elements of type buf_ioreq_t (6 bytes each).
> Being able to pipeline 8 times as many ops improves
> VGA performance by a factor of 8.
>
> I changed hvm_buffered_io_intercept to use the same
> registration and callback mechanism as hvm_portio_intercept
> rather than the hacky hardcoding it used before.
>
> In platform.c , I fixed send_timeoffset_req() to sets its
> ioreq size to 8 (rather than 4), and its count to 1 (which
> was missing).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

-- 
--------------------------------------------------------------------
Robert
S.
Phillips                          Virtual
Iron Software
rphillips@xxxxxxxxxxxxxxx                Tower
1, Floor 2
978-849-1220                                
900 Chelmsford Street
                                                    Lowell,
MA 01851
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel