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

Re: [win-pv-devel] Question about windows domU long boot time in xen and help for update libxl virtio patch (for a test)



Il 08/05/2015 18:47, Paul Durrant ha scritto:
-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: 08 May 2015 16:11
To: Paul Durrant; xen-devel; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Cc: Anthony Perard; Wei Liu; Ian Campbell; Stefano Stabellini
Subject: Re: [win-pv-devel] Question about windows domU long boot time in
xen and help for update libxl virtio patch (for a test)

Il 08/05/2015 16:59, Paul Durrant ha scritto:
-----Original Message-----
From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Fabio Fantoni
Sent: 08 May 2015 15:54
To: xen-devel; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Cc: Anthony Perard; Wei Liu; Ian Campbell; Stefano Stabellini
Subject: [win-pv-devel] Question about windows domU long boot time in
xen and help for update libxl virtio patch (for a test)

In latest years hvm domUs support and performance was increased but
windows boot time is still too long.
I tried out all sort of combinations (without pv, with old gplpv and new
winpv, with vnc, spice or without both, with different vgas and many
other options) with same result: strange long boot time (before arrive
to user login).
On kvm (trying with same qemu/seabios versions, qdisk with raw ecc...)
instead for example the boot time is faster and similar to the phisical
pc one with same vcpu ram ecc as assigned.
Is there something that need to be improved/fixed in windows pv drivers
or xen?

Which version of QEMU are you using. I tend to use upstream, but I see a
*very* long pause between the end of firmware logging and sampling the
viridian cpuid leaves (which is generally the next thing to cause some logging)
so my suspicion is that the int13 handling in seabios is probably the culprit.
That's only a hunch, but using rombios and qemu trad is quite a lot faster.

Thanks for reply.
With qemu-trad if I remember good was faster on initial boot but have
lower general performance, I don't use anymore qemu-trad on dom0 with
xen >= 4.3
About qemu upstream I started use it on 1.2 if I remember good and after
I always tested all versions up to 2.2 and seabios I keeped updated
rebuilding from debian sid package (now 1.8.1)

I'm using the seabios image from the Xen build. Turns out that it's built with 
CONFIG_ATA_DMA off (because that's not set when you run make defconfig). 
Turning that on manually in the config and rebuilding makes things a *lot* 
faster :-)

   Paul

Once the kernel starts to boot I see no significant delays. PV drivers are not
wonderfully fast to start up as the xenstore state dance does take a while. It
is somewhat unavoidable though.
    Paul

I tried to narrow down my search trying with virtio disk on xen but I
was unable to have libxl patch working.
I taken very old Wei Liu patch from here:
http://downloads.xen.org/Wiki/VirtioOnXen/libxl-virtio-support.patch

And I tried to adapt it but there is something that I not understand and
causing the build fails:
libxl.c:2339:32: error: LIBXL__DEVICE_KIND_VIRTIO undeclared (first use
in this function)

Here the path I updated and tried failing, I did only disks part (nic
need only model change in xl.cfg FWIK):

https://github.com/Fantu/Xen/commit/783c1739df3a87689ab8c152632b2493
34d92f0a

Can someone help me to complete/fix it please?

Can someone help me about virtio disks support in libxl please?

After this reply about seabios seems can be useful try virtio:
http://lists.xen.org/archives/html/xen-devel/2015-05/msg01257.html

Thanks for any reply and sorry for my bad english.



_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel


 


Rackspace

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