Update Seabios on xen-unstable

Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 559 bytes --]

I saw good news about qemu-xen on xen-unstable updates to latest stable 
version (1.3), I already start test it and report bugs found.
I saw no seabios updates for now on xen-unstable, there is 1.7.1 
upstream version since few months that include all vgabios.
Is possible to update seabios on xen-unstable please?
I have tried it time ago for probably resolution of qxl vga problem 
without result.
It probably needs some particular settings or modification for correct 
integration in xen about vgabios that I not know of.
Thanks for any reply.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 1520 bytes --]

Il 20/12/2012 13:34, Fabio Fantoni ha scritto:
> I saw good news about qemu-xen on xen-unstable updates to latest 
> stable version (1.3), I already start test it and report bugs found.
> I saw no seabios updates for now on xen-unstable, there is 1.7.1 
> upstream version since few months that include all vgabios.
> Is possible to update seabios on xen-unstable please?
> I have tried it time ago for probably resolution of qxl vga problem 
> without result.
> It probably needs some particular settings or modification for correct 
> integration in xen about vgabios that I not know of.
> Thanks for any reply.
>
Updated debian seabios package to 1.7.1 (on personal repository for 
now), tested with wheezy and xen-unstable and is working.

Package repository: https://github.com/Fantu/pkg-seabios

Changelog of my build:
-------------------------------------------------------------------
seabios (1.7.1-0.1) experimental; urgency=low

   * Non-maintainer upload
   * New upstream release 1.7.1 featuring xen support (Closes: #678042)
   * Removed debian/patches/fix-==-in-shell.patch (applied upstream).
   * Updated debian/optionrom from qemu 1.3.0 keeping debian changes.

  -- Fabio Fantoni <fabio.fantoni@heliman.it> Thu, 28 Dec 2012 16:18:06 
+0100
-------------------------------------------------------------------

Could someone test it and tell me if is sufficent good to propose upload 
into Debian and hence enabling qemu upstream into xen on experimental 
repository?


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Ian Campbell]

On Thu, 2012-12-20 at 12:34 +0000, Fabio Fantoni wrote:
> I saw good news about qemu-xen on xen-unstable updates to latest stable 
> version (1.3), I already start test it and report bugs found.
> I saw no seabios updates for now on xen-unstable, there is 1.7.1 
> upstream version since few months that include all vgabios.
> Is possible to update seabios on xen-unstable please?
> I have tried it time ago for probably resolution of qxl vga problem 
> without result.
> It probably needs some particular settings or modification for correct 
> integration in xen about vgabios that I not know of.
> Thanks for any reply.

This is on my todo list, however it is made a bit tricky because SeaBIOS
is quite picky about the compiler which is used (specifically the newest
SeaBIOS won't build on a Debian Stable system, which affects both me and
the Xen.org test system)

The solution will probably be to ship a binary and only rebuild when
explicitly asked to. I haven't quite got round to it yet though.

Ian.

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 2283 bytes --]

Il 02/01/2013 13:10, Ian Campbell ha scritto:
> On Thu, 2012-12-20 at 12:34 +0000, Fabio Fantoni wrote:
>> I saw good news about qemu-xen on xen-unstable updates to latest stable
>> version (1.3), I already start test it and report bugs found.
>> I saw no seabios updates for now on xen-unstable, there is 1.7.1
>> upstream version since few months that include all vgabios.
>> Is possible to update seabios on xen-unstable please?
>> I have tried it time ago for probably resolution of qxl vga problem
>> without result.
>> It probably needs some particular settings or modification for correct
>> integration in xen about vgabios that I not know of.
>> Thanks for any reply.
> This is on my todo list, however it is made a bit tricky because SeaBIOS
> is quite picky about the compiler which is used (specifically the newest
> SeaBIOS won't build on a Debian Stable system, which affects both me and
> the Xen.org test system)
>
> The solution will probably be to ship a binary and only rebuild when
> explicitly asked to. I haven't quite got round to it yet though.
>
> Ian.
Thanks for your reply.
Seabios 1.7.1 is now on Debian sid repository, I tested it with Wheezy 
and xen-unstable and it is working.


Qemu still crashes if qxl is active and used but I don't think it is a 
seabios problem.

I've been looking for the problem in xen but I didn't find a solution at 
the moment. I can tell that seabios is called by hvmloader that sets a 
few things like acpi and e820 mapping before calling it. Could it be 
that hvmloader does something that interferes with seabios, like 
imposing restrictions?

In practice if I activate qxl but I use it only as stdvga I don't 
experience any problem except low video performance, but if I use it 
fully qemu crashes when spice start using qxl features, logging this error:
(/usr/sbin/xl:4658): Spice-CRITICAL **: red_memslots.c:123:get_virt: 
slot_id 194 too big, addr=c2c2c2c2c2c2c2c2

The only other possibility that comes to mind is that not enough 
videoram is successifully set. I thought this problem was already solved 
some months ago with xen and qemu upstream patches. Could there be other 
problems preventing the assignment and use 128 mb of videoram?

Thanks for any reply.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 2071 bytes --]

Il 02/01/2013 15:41, Fabio Fantoni ha scritto:
> Qemu still crashes if qxl is active and used but I don't think it is a 
> seabios problem.
>
> I've been looking for the problem in xen but I didn't find a solution 
> at the moment. I can tell that seabios is called by hvmloader that 
> sets a few things like acpi and e820 mapping before calling it. Could 
> it be that hvmloader does something that interferes with seabios, like 
> imposing restrictions?
>
> In practice if I activate qxl but I use it only as stdvga I don't 
> experience any problem except low video performance, but if I use it 
> fully qemu crashes when spice start using qxl features, logging this 
> error:
> (/usr/sbin/xl:4658): Spice-CRITICAL **: red_memslots.c:123:get_virt: 
> slot_id 194 too big, addr=c2c2c2c2c2c2c2c2
>
> The only other possibility that comes to mind is that not enough 
> videoram is successifully set. I thought this problem was already 
> solved some months ago with xen and qemu upstream patches. Could there 
> be other problems preventing the assignment and use 128 mb of videoram?
>
> Thanks for any reply.
>
I see this commit on seabios:

> Commit:74c78786719b202557d4f177bd290ddd98e979fe
>
> * Add support for use as Xen HVM BIOS.
>
> SeaBIOS is called by Xen's hvmloader which does the basic platform
> setup (PCI, APIC, etc) and provides the various BIOS tables. Therefore
> avoid re-doing that setup and copy out the tables as necessary. A
> simple data structure is defined to pass the addresses of these
> tables.
>
> This patch also establishes the basic infrastructure to make
> hypercalls, although it currently only uses it to query the hypervisor
> version.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Can be enabled the reconstruction of the bios tables with seabios 
instead of mantain hvmloader tables or is necessary hvmloader tables for 
correct domU working?
I want try if seabios tables solves the problem.
If yes what I must change on seabios code for test it?
Thanks for any reply


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Ian Campbell]

On Fri, 2013-01-04 at 11:58 +0000, Fabio Fantoni wrote:
> Can be enabled the reconstruction of the bios tables with seabios 
> instead of mantain hvmloader tables or is necessary hvmloader tables for 
> correct domU working?

The hvmloader provided tables are the correct ones to use. This is the
same as the coreboot model where coreboot provides the tables to
SeaBIOS.

AFAIK the SeaBIOS tables are a qemu/kvm-ism.

> I want try if seabios tables solves the problem.
> If yes what I must change on seabios code for test it?

Yes, substantially.

I very much doubt it will make any difference to whatever issue you are
having and would be a waste of time.

I don't think your issue will be solved by trying random things like
this anyway. If you are interested in fixing this then you are going to
have to dive in and try to understand the code well enough to figure out
what is going wrong.

Ian.

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 1499 bytes --]

Il 04/01/2013 13:10, Ian Campbell ha scritto:
> On Fri, 2013-01-04 at 11:58 +0000, Fabio Fantoni wrote:
>> Can be enabled the reconstruction of the bios tables with seabios
>> instead of mantain hvmloader tables or is necessary hvmloader tables for
>> correct domU working?
> The hvmloader provided tables are the correct ones to use. This is the
> same as the coreboot model where coreboot provides the tables to
> SeaBIOS.
>
> AFAIK the SeaBIOS tables are a qemu/kvm-ism.
>
>> I want try if seabios tables solves the problem.
>> If yes what I must change on seabios code for test it?
> Yes, substantially.
>
> I very much doubt it will make any difference to whatever issue you are
> having and would be a waste of time.
>
> I don't think your issue will be solved by trying random things like
> this anyway. If you are interested in fixing this then you are going to
> have to dive in and try to understand the code well enough to figure out
> what is going wrong.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2805 / Database dei virus: 2637/6007 -  Data di rilascio: 03/01/2013
>
>
I see the "HVM firmware passthrough" patch, but I not found 
documentation about it.
Can I use it to do a rapid test adding qxl vgabios?
With xen seabios is built-in into hvmloader (instead of kvm and qemu).
I didn't see any fixed paths to link vgabioses so I think that seabios 
can't autoload it in xen now.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Ian Campbell]

On Fri, 2013-01-11 at 09:29 +0000, Fabio Fantoni wrote:

> I see the "HVM firmware passthrough" patch, but I not found 
> documentation about it.

Check the list for posts from Ross.

> Can I use it to do a rapid test adding qxl vgabios?

I don't think so, AFAIK, it is for passing through ACPI and SMBIOS
tables, not BIOSes them selves

> With xen seabios is built-in into hvmloader (instead of kvm and qemu).
> I didn't see any fixed paths to link vgabioses so I think that seabios 
> can't autoload it in xen now.

SeaBIOS on Xen loads the BIOS from the device's ROM BAR. IOW it is
supplied by qemu.

Ian.

Re: Update Seabios on xen-unstable

[Ross Philipson]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Friday, January 11, 2013 4:54 AM
> To: fantonifabio@tiscali.it
> Cc: Anthony Perard; xen-devel; Stefano Stabellini
> Subject: Re: [Xen-devel] Update Seabios on xen-unstable
> 
> On Fri, 2013-01-11 at 09:29 +0000, Fabio Fantoni wrote:
> 
> > I see the "HVM firmware passthrough" patch, but I not found
> > documentation about it.
> 
> Check the list for posts from Ross.

I am working on support in xl to introduce params for specifying
the firmware files to pass in. I will document what they are in
the xl.cfg docs. Also, the header file xen/public/hvm/hvm_xs_string.h
indicates what the input blobs should look like.

> 
> > Can I use it to do a rapid test adding qxl vgabios?
> 
> I don't think so, AFAIK, it is for passing through ACPI and SMBIOS
> tables, not BIOSes them selves

Yes it is for SMBIOS and ACPI right now. I could enhance it to
load other things but as noted below, I though SeaBIOS could
load OROMs specified by the devices.

> 
> > With xen seabios is built-in into hvmloader (instead of kvm and qemu).
> > I didn't see any fixed paths to link vgabioses so I think that seabios
> > can't autoload it in xen now.
> 
> SeaBIOS on Xen loads the BIOS from the device's ROM BAR. IOW it is
> supplied by qemu.
> 
> Ian.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Update Seabios on xen-unstable

[Ian Campbell]

On Fri, 2013-01-11 at 12:37 +0000, Ross Philipson wrote:
> Yes it is for SMBIOS and ACPI right now. I could enhance it to
> load other things but as noted below, I though SeaBIOS could
> load OROMs specified by the devices.

It can and does, we should not use the interface you have added for
loading BIOS ROMs IMHO.

Ian.

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 790 bytes --]

Il 11/01/2013 14:12, Ian Campbell ha scritto:
> On Fri, 2013-01-11 at 12:37 +0000, Ross Philipson wrote:
>> Yes it is for SMBIOS and ACPI right now. I could enhance it to
>> load other things but as noted below, I though SeaBIOS could
>> load OROMs specified by the devices.
> It can and does, we should not use the interface you have added for
> loading BIOS ROMs IMHO.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2890 / Database dei virus: 2637/6024 -  Data di rilascio: 10/01/2013
>
>
Thanks for the replies.
I know that isn't optimal use firmware passtrought for vgabioses but I'm 
not sure that seabios actually loads (automatically) the vgabioses.
Please point me in right direction if i'm wrong.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Ian Campbell]

On Fri, 2013-01-11 at 14:26 +0000, Fabio Fantoni wrote:
> I know that isn't optimal use firmware passtrought for vgabioses but I'm 
> not sure that seabios actually loads (automatically) the vgabioses.

SeaBIOS *does* load the VGA BIOS. You can see it if you use SDL (or are
quick enough with the VNC).

Ian.

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 1536 bytes --]

Il 11/01/2013 15:32, Ian Campbell ha scritto:
> On Fri, 2013-01-11 at 14:26 +0000, Fabio Fantoni wrote:
>> I know that isn't optimal use firmware passtrought for vgabioses but I'm
>> not sure that seabios actually loads (automatically) the vgabioses.
> SeaBIOS *does* load the VGA BIOS. You can see it if you use SDL (or are
> quick enough with the VNC).
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2890 / Database dei virus: 2637/6024 -  Data di rilascio: 10/01/2013
>
>
Vnc graphic performance of qemu-xen is bad, are not enough even to use 
it for maintenance only, I noted at the beginning of the test a year ago 
and already reported here.
With spice without qxl performance are enough to use it for maintenance 
but not for work on desktop.
The ideal solution for have Xengreat not only for servers but also for 
desktops would be Spice with qxl, audio, vdagent and usbredirection.
Audio vdagent and usbredirection are working, I'll try to do patches for 
libxl and post it.
About qxl months ago gave critical errors due to videoram resolved with 
patches someone made in xen.
Now qxl start but have low performance, also cirrus with videoram 
increased seem not increase performance on xen.
I tried for a long time to solve the problem but at the moment the only 
clues of difference from kvm and qemu (in which both work best) led me 
to hvmloader about seabios and vgabioses.
Sorry for the bad english and thanks for any reply.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1.1: Type: text/plain, Size: 1373 bytes --]

Il 11/01/2013 15:32, Ian Campbell ha scritto:
> On Fri, 2013-01-11 at 14:26 +0000, Fabio Fantoni wrote:
>> I know that isn't optimal use firmware passtrought for vgabioses but I'm
>> not sure that seabios actually loads (automatically) the vgabioses.
> SeaBIOS *does* load the VGA BIOS. You can see it if you use SDL (or are
> quick enough with the VNC).
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG -www.avg.com
> Versione: 2013.0.2890 / Database dei virus: 2637/6024 -  Data di rilascio: 10/01/2013
>
>
I done other test with all spice seabios and qemu updated.
Based on qxl patch v7 ( 
http://lists.xen.org/archives/html/xen-devel/2013-01/msg01405.html ) by 
default xen should assign 128 mb total of videoram and also set with 
-global to qemu the 2 qxl ram region correctly to 64 mb each.

I actived also qxl debug and on log show this:
/var/log/xen/qemu-dm-W7.log
qxl-0: ram/pri: 32 MB [region 0]
qxl-0: vram/32: 0 MB [region 1]
qxl-0: vram/64: 0 MB [unmapped]
...


Seem can use only 32 mb and only on one region instead of 64 mb on 
region 0 and 64 mb on region 1
Added as attachment also with log of xl -vvv create

Does anyone know what can cause this problem?
Can be somethink in hvmloader that fixed videoram to one region 32 mb 
always?

Thanks for any reply and sorry for my bad english.


[-- Attachment #1.1.2: xlcreatelog.txt --]
[-- Type: text/plain, Size: 10551 bytes --]

xl -vvv create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: debug: libxl_create.c:1212:do_domain_create: ao 0x218f360: create: how=(nil) callback=(nil) poller=0x218f5e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend tap
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hdb, using backend tap
libxl: debug: libxl_create.c:660:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader
libxl: debug: libxl_event.c:562:libxl__ev_xswatch_deregister: watch w=0x218f940: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=10, free_memkb=10064
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 10064 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9e9a8
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19e9a8
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019e9a8
  Modules:       0000000000000000->0000000000000000
  TOTAL:         0000000000000000->0000000078000000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003bf
  1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x0x7ff83f6fb000 -> 0x0x7ff83f790835
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=tap
libxl: debug: libxl_event.c:513:libxl__ev_xswatch_register: watch w=0x2190c38 wpath=/local/domain/0/backend/vbd/2/768/state token=3/0: register slotnum=3
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdb spec.backend=tap
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hdb spec.backend=tap
libxl: debug: libxl_event.c:513:libxl__ev_xswatch_register: watch w=0x2191ce8 wpath=/local/domain/0/backend/vbd/2/832/state token=2/1: register slotnum=2
libxl: debug: libxl_create.c:1225:do_domain_create: ao 0x218f360: inprogress: poller=0x218f5e0, flags=i
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x2190c38 wpath=/local/domain/0/backend/vbd/2/768/state token=3/0: event epath=/local/domain/0/backend/vbd/2/768/state
libxl: debug: libxl_event.c:597:devstate_watch_callback: backend /local/domain/0/backend/vbd/2/768/state wanted state 2 ok
libxl: debug: libxl_event.c:550:libxl__ev_xswatch_deregister: watch w=0x2190c38 wpath=/local/domain/0/backend/vbd/2/768/state token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:562:libxl__ev_xswatch_deregister: watch w=0x2190c38: deregister unregistered
libxl: debug: libxl_device.c:919:device_hotplug: calling hotplug script: /etc/xen/scripts/block add
libxl: debug: libxl_event.c:426:watchfd_callback: watch epath=/local/domain/0/backend/vbd/2/768/state token=3/0: empty slot
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x2191ce8 wpath=/local/domain/0/backend/vbd/2/832/state token=2/1: event epath=/local/domain/0/backend/vbd/2/832/state
libxl: debug: libxl_event.c:597:devstate_watch_callback: backend /local/domain/0/backend/vbd/2/832/state wanted state 2 ok
libxl: debug: libxl_event.c:550:libxl__ev_xswatch_deregister: watch w=0x2191ce8 wpath=/local/domain/0/backend/vbd/2/832/state token=2/1: deregister slotnum=2
libxl: debug: libxl_event.c:562:libxl__ev_xswatch_deregister: watch w=0x2191ce8: deregister unregistered
libxl: debug: libxl_device.c:919:device_hotplug: calling hotplug script: /etc/xen/scripts/block add
libxl: debug: libxl_event.c:426:watchfd_callback: watch epath=/local/domain/0/backend/vbd/2/832/state token=2/1: empty slot
libxl: debug: libxl_dm.c:1156:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   /usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -xen-domid
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   2
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -name
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   W7
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -k
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   it
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -spice
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   port=6002,tls-port=0,addr=0.0.0.0,password=prova,agent-mouse=on
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   qxl-vga
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -global
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   qxl-vga.vram_size=65536
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -global
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   qxl-vga.ram_size=65536
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   order=dc
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -smp
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   2,maxcpus=2
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   rtl8139,id=nic0,netdev=net0,mac=00:16:3e:49:bb:f1
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -netdev
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   type=tap,id=net0,ifname=vif2.0-emu,script=no,downscript=no
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   --global
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   qxl-vga.debug=1
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -global
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   qxl-vga.guestdebug=20
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -m
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   1920
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -drive
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   file=/mnt/vm/disks/prova/W7.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   -drive
libxl: debug: libxl_dm.c:1158:libxl__spawn_local_dm:   file=/mnt/vm/iso/XPSP3PRO.iso,if=ide,index=1,media=cdrom,format=raw,cache=writeback,id=ide-832
libxl: debug: libxl_event.c:513:libxl__ev_xswatch_register: watch w=0x218fb78 wpath=/local/domain/0/device-model/2/state token=2/2: register slotnum=2
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x218fb78 wpath=/local/domain/0/device-model/2/state token=2/2: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x218fb78 wpath=/local/domain/0/device-model/2/state token=2/2: event epath=/local/domain/0/device-model/2/state
libxl: debug: libxl_event.c:550:libxl__ev_xswatch_deregister: watch w=0x218fb78 wpath=/local/domain/0/device-model/2/state token=2/2: deregister slotnum=2
libxl: debug: libxl_event.c:562:libxl__ev_xswatch_deregister: watch w=0x218fb78: deregister unregistered
libxl: debug: libxl_qmp.c:695:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-2
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}'
libxl: debug: libxl_qmp.c:299:qmp_handle_response: message type: return
libxl: debug: libxl_event.c:513:libxl__ev_xswatch_register: watch w=0x2197348 wpath=/local/domain/0/backend/vif/2/0/state token=2/3: register slotnum=2
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x2197348 wpath=/local/domain/0/backend/vif/2/0/state token=2/3: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:601:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x2197348 wpath=/local/domain/0/backend/vif/2/0/state token=2/3: event epath=/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:597:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 ok
libxl: debug: libxl_event.c:550:libxl__ev_xswatch_deregister: watch w=0x2197348 wpath=/local/domain/0/backend/vif/2/0/state token=2/3: deregister slotnum=2
libxl: debug: libxl_event.c:562:libxl__ev_xswatch_deregister: watch w=0x2197348: deregister unregistered
libxl: debug: libxl_device.c:919:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_device.c:919:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge add
libxl: debug: libxl_event.c:1668:libxl__ao_progress_report: ao 0x218f360: progress report: ignored
libxl: debug: libxl_event.c:1500:libxl__ao_complete: ao 0x218f360: complete, rc=0
libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x218f360: destroy
Daemon running with PID 3932
xc: debug: hypercall buffer: total allocations:744 total releases:744
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:736 misses:4 toobig:4

[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 2626 bytes --]

Il 23/01/2013 16:23, Fabio Fantoni ha scritto:
> Il 11/01/2013 15:32, Ian Campbell ha scritto:
>> On Fri, 2013-01-11 at 14:26 +0000, Fabio Fantoni wrote:
>>> I know that isn't optimal use firmware passtrought for vgabioses but 
>>> I'm
>>> not sure that seabios actually loads (automatically) the vgabioses.
>> SeaBIOS *does* load the VGA BIOS. You can see it if you use SDL (or are
>> quick enough with the VNC).
>>
>> Ian.
>>
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG -www.avg.com
>> Versione: 2013.0.2890 / Database dei virus: 2637/6024 -  Data di 
>> rilascio: 10/01/2013
>>
>>
> I done other test with all spice seabios and qemu updated.
> Based on qxl patch v7 ( 
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg01405.html ) 
> by default xen should assign 128 mb total of videoram and also set 
> with -global to qemu the 2 qxl ram region correctly to 64 mb each.
>
> I actived also qxl debug and on log show this:
> /var/log/xen/qemu-dm-W7.log
> qxl-0: ram/pri: 32 MB [region 0]
> qxl-0: vram/32: 0 MB [region 1]
> qxl-0: vram/64: 0 MB [unmapped]
> ...
>
>
> Seem can use only 32 mb and only on one region instead of 64 mb on 
> region 0 and 64 mb on region 1
> Added as attachment also with log of xl -vvv create
>
> Does anyone know what can cause this problem?
> Can be somethink in hvmloader that fixed videoram to one region 32 mb 
> always?
>
> Thanks for any reply and sorry for my bad english.
>
Tried Wheezy hvm domU with xen, qemu crash and give this out of memory 
error on qemu log:
id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, 
delta 0
id 1, group 1, virt start 7f3034a29000, virt end 7f3035a27000, 
generation 0, delta 7f3034a29000
id 2, group 1, virt start 7f30337ff000, virt end 7f3033803000, 
generation 0, delta 7f30337ff000
(/usr/sbin/xl:19287): Spice-CRITICAL **: 
red_memslots.c:94:validate_virt: virtual address out of range
     virt=0x7f3035a29398+0xbf slot_id=1 group_id=1
     slot=0x7f3034a29000-0x7f3035a27000 delta=0x7f3034a29000

Same domU launching qemu only:
/usr/lib/xen/bin/qemu-system-i386 -name WHEEZY -k it -spice 
port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on 
-device qxl-vga -global qxl-vga.vram_size=16384 -global 
qxl-vga.ram_size=16384 -boot order=dc -smp 2,maxcpus=2 --global 
qxl-vga.debug=1 -global qxl-vga.guestdebug=20 -m 2016 -drive 
file=/mnt/vm/disks/WHEEZY.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback

No qemu crash and no memory error, this is probably the confirm some xen 
memory bug with hvm.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Update Seabios on xen-unstable

[Mats Petersson]

On 11/01/13 14:26, Fabio Fantoni wrote:
> Il 11/01/2013 14:12, Ian Campbell ha scritto:
>> On Fri, 2013-01-11 at 12:37 +0000, Ross Philipson wrote:
>>> Yes it is for SMBIOS and ACPI right now. I could enhance it to
>>> load other things but as noted below, I though SeaBIOS could
>>> load OROMs specified by the devices.
>> It can and does, we should not use the interface you have added for
>> loading BIOS ROMs IMHO.
>>
>> Ian.
>>
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - www.avg.com
>> Versione: 2013.0.2890 / Database dei virus: 2637/6024 -  Data di rilascio: 10/01/2013
>>
>>
> Thanks for the replies.
> I know that isn't optimal use firmware passtrought for vgabioses but I'm
> not sure that seabios actually loads (automatically) the vgabioses.
> Please point me in right direction if i'm wrong.
>
What OS are you actually trying to use, and on what hardware? Most 
drivers, for most hardware, these days are perfectly capable of running 
without the VGA BIOS. It's possible that some don't, but I'm not sure 
which that would be. Just asking, so that I understand, more than 
anything else.

--
Mats