* Qemu upstream bugs with xen
@ 2013-01-18 9:47 Fabio Fantoni
2013-01-18 13:00 ` Stefano Stabellini
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Fantoni @ 2013-01-18 9:47 UTC (permalink / raw)
To: xen-devel, Stefano Stabellini, Ian Campbell
1) Both linux and windows domU with qemu upstream have an additional
empty floppy and cdrom.
Is there a way to remove these additionals block devices?
2) xl cd-eject and cd-insert are not working:
xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
how=(nil) callback=(nil) poller=0x1b95930
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
vdev=hdb spec.backend=phy
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
backend phy unsuitable as phys path not a block device
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
suitable backend for disk hdb
libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
how=(nil) callback=(nil) poller=0x1d079f0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
vdev=hdb spec.backend=phy
libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
directory
libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
Seem there is parsing error about backend and device/iso path, for now I
not found solution for fix it on code.
3) There is still big problem of network not working after restore on
windows domU, but for now I not found exactly cause.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 9:47 Qemu upstream bugs with xen Fabio Fantoni
@ 2013-01-18 13:00 ` Stefano Stabellini
2013-01-18 14:44 ` Fabio Fantoni
0 siblings, 1 reply; 13+ messages in thread
From: Stefano Stabellini @ 2013-01-18 13:00 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> 1) Both linux and windows domU with qemu upstream have an additional
> empty floppy and cdrom.
> Is there a way to remove these additionals block devices?
the best way would be to pass a device or a global command line option
to QEMU to change the default for isa-fdc
> 2) xl cd-eject and cd-insert are not working:
>
> xl -vvv cd-eject W7 hdb
> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
> how=(nil) callback=(nil) poller=0x1b95930
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> vdev=hdb spec.backend=phy
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
> backend phy unsuitable as phys path not a block device
> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
> suitable backend for disk hdb
cd-eject should work by trying to insert an empty cdrom.
In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
think this is not the case here.
I guess it is a bug in parse_disk_config.
> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>
> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
> how=(nil) callback=(nil) poller=0x1d079f0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> vdev=hdb spec.backend=phy
> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
> directory
It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>
> Seem there is parsing error about backend and device/iso path, for now I
> not found solution for fix it on code.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 13:00 ` Stefano Stabellini
@ 2013-01-18 14:44 ` Fabio Fantoni
2013-01-18 15:51 ` Stefano Stabellini
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Fabio Fantoni @ 2013-01-18 14:44 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, Ian Jackson, Ian Campbell
Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>> 1) Both linux and windows domU with qemu upstream have an additional
>> empty floppy and cdrom.
>> Is there a way to remove these additionals block devices?
> the best way would be to pass a device or a global command line option
> to QEMU to change the default for isa-fdc
>
>
>> 2) xl cd-eject and cd-insert are not working:
>>
>> xl -vvv cd-eject W7 hdb
>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
>> how=(nil) callback=(nil) poller=0x1b95930
>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>> vdev=hdb spec.backend=phy
>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>> backend phy unsuitable as phys path not a block device
>> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
>> suitable backend for disk hdb
> cd-eject should work by trying to insert an empty cdrom.
> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
> think this is not the case here.
> I guess it is a bug in parse_disk_config.
>
>
>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>
>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
>> how=(nil) callback=(nil) poller=0x1d079f0
>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>> vdev=hdb spec.backend=phy
>> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>> directory
> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
> of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
>
>
>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>
>> Seem there is parsing error about backend and device/iso path, for now I
>> not found solution for fix it on code.
I've added -nodefaults option to qemu upstream to remove empty floppy
and cdrom with success. Please could this be added by default on libxl
on qemu upstream starting?
About cd-eject cd-insert parsing bug can you solve please?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 14:44 ` Fabio Fantoni
@ 2013-01-18 15:51 ` Stefano Stabellini
2013-02-04 13:14 ` Fabio Fantoni
2013-01-21 12:16 ` George Dunlap
2013-03-11 11:55 ` Frediano Ziglio
2 siblings, 1 reply; 13+ messages in thread
From: Stefano Stabellini @ 2013-01-18 15:51 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
> > On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> >> 1) Both linux and windows domU with qemu upstream have an additional
> >> empty floppy and cdrom.
> >> Is there a way to remove these additionals block devices?
> > the best way would be to pass a device or a global command line option
> > to QEMU to change the default for isa-fdc
> >
> >
> >> 2) xl cd-eject and cd-insert are not working:
> >>
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
> >> how=(nil) callback=(nil) poller=0x1b95930
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
> >> backend phy unsuitable as phys path not a block device
> >> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
> >> suitable backend for disk hdb
> > cd-eject should work by trying to insert an empty cdrom.
> > In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
> > think this is not the case here.
> > I guess it is a bug in parse_disk_config.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
> >> how=(nil) callback=(nil) poller=0x1d079f0
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
> >> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
> >> directory
> > It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
> > of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> Seem there is parsing error about backend and device/iso path, for now I
> >> not found solution for fix it on code.
> I've added -nodefaults option to qemu upstream to remove empty floppy
> and cdrom with success. Please could this be added by default on libxl
> on qemu upstream starting?
The problem with -nodefaults is that it changes a lot of other things
aside from the floppy drive:
default_serial = 0;
default_parallel = 0;
default_virtcon = 0;
default_monitor = 0;
default_vga = 0;
default_net = 0;
default_floppy = 0;
default_cdrom = 0;
default_sdcard = 0;
libxl should always set the right command line options for vga and
network, and most of the other settings don't matter for us.
However I am concerned about the monitor and the cdrom drive.
I thought that we always wanted to have a cdrom drive on HVM guests,
even if empty.
It would be better to find a way to change only the floppy default
setting.
> About cd-eject cd-insert parsing bug can you solve please?
Yes, however I am a bit busy at the moment so it might take some time.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 14:44 ` Fabio Fantoni
2013-01-18 15:51 ` Stefano Stabellini
@ 2013-01-21 12:16 ` George Dunlap
2013-01-30 11:28 ` Fabio Fantoni
2013-03-11 11:55 ` Frediano Ziglio
2 siblings, 1 reply; 13+ messages in thread
From: George Dunlap @ 2013-01-21 12:16 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
[-- Attachment #1.1: Type: text/plain, Size: 3130 bytes --]
On Fri, Jan 18, 2013 at 2:44 PM, Fabio Fantoni <fabio.fantoni@heliman.it>wrote:
> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
>
> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>>
>>> 1) Both linux and windows domU with qemu upstream have an additional
>>> empty floppy and cdrom.
>>> Is there a way to remove these additionals block devices?
>>>
>> the best way would be to pass a device or a global command line option
>> to QEMU to change the default for isa-fdc
>>
>>
>> 2) xl cd-eject and cd-insert are not working:
>>>
>>> xl -vvv cd-eject W7 hdb
>>> libxl: debug: libxl.c:2389:libxl_cdrom_**insert: ao 0x1b95990: create:
>>> how=(nil) callback=(nil) poller=0x1b95930
>>> libxl: debug: libxl_device.c:229:libxl__**device_disk_set_backend: Disk
>>> vdev=hdb spec.backend=phy
>>> libxl: debug: libxl_device.c:175:disk_try_**backend: Disk vdev=hdb,
>>> backend phy unsuitable as phys path not a block device
>>> libxl: error: libxl_device.c:269:libxl__**device_disk_set_backend: no
>>> suitable backend for disk hdb
>>>
>> cd-eject should work by trying to insert an empty cdrom.
>> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
>> think this is not the case here.
>> I guess it is a bug in parse_disk_config.
>>
>>
>> libxl: debug: libxl_event.c:1482:libxl__ao_**abort: ao 0x1b95990: abort
>>> libxl: debug: libxl_event.c:1472:libxl__ao__**destroy: ao 0x1b95990:
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>> xc: debug: hypercall buffer: cache current size:2
>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>
>>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>>> libxl: debug: libxl.c:2389:libxl_cdrom_**insert: ao 0x1d07990: create:
>>> how=(nil) callback=(nil) poller=0x1d079f0
>>> libxl: debug: libxl_device.c:229:libxl__**device_disk_set_backend: Disk
>>> vdev=hdb spec.backend=phy
>>> libxl: error: libxl_device.c:243:libxl__**device_disk_set_backend: Disk
>>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>>> directory
>>>
>> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
>> of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
>>
>>
>> libxl: debug: libxl_event.c:1482:libxl__ao_**abort: ao 0x1d07990: abort
>>> libxl: debug: libxl_event.c:1472:libxl__ao__**destroy: ao 0x1d07990:
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>> xc: debug: hypercall buffer: cache current size:2
>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>
>>> Seem there is parsing error about backend and device/iso path, for now I
>>> not found solution for fix it on code.
>>>
>> I've added -nodefaults option to qemu upstream to remove empty floppy and
> cdrom with success. Please could this be added by default on libxl on qemu
> upstream starting?
>
> About cd-eject cd-insert parsing bug can you solve please?
I'll put this on the release tracking list.
-George
[-- Attachment #1.2: Type: text/html, Size: 4233 bytes --]
[-- Attachment #2: 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] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-21 12:16 ` George Dunlap
@ 2013-01-30 11:28 ` Fabio Fantoni
2013-02-08 16:21 ` Stefano Stabellini
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Fantoni @ 2013-01-30 11:28 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
I done other test with qemu upstream, on restore of Windows 7 pro 64 bit
domU with latest gplpv give these lines on logs:
xen_ram_alloc: do not alloc 7f800000 bytes of ram at 0 when runstate is
INMIGRATE
xen_ram_alloc: do not alloc 800000 bytes of ram at 7f800000 when
runstate is INMIGRATE
xen_ram_alloc: do not alloc 10000 bytes of ram at 80000000 when runstate
is INMIGRATE
xen_ram_alloc: do not alloc 10000 bytes of ram at 80010000 when runstate
is INMIGRATE
All seem working except network (seem more gplpv problem already
reported on other post), about this ram logs (first is very strange).
Is it normal or maybe some bugs around?
Dom0 is Wheezy updated with xen-unstable from source (changeset:
26396:b6195e277da5) and qemu 1.3.0 from experimental debian git, rebuilt
for wheezy.
If you need more tests and details tell me and I'll post them.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 15:51 ` Stefano Stabellini
@ 2013-02-04 13:14 ` Fabio Fantoni
2013-02-04 13:20 ` Ian Campbell
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Fantoni @ 2013-02-04 13:14 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, Ian Jackson, Ian Campbell
Il 18/01/2013 16:51, Stefano Stabellini ha scritto:
> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
>>> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>>>> 1) Both linux and windows domU with qemu upstream have an additional
>>>> empty floppy and cdrom.
>>>> Is there a way to remove these additionals block devices?
>>> the best way would be to pass a device or a global command line option
>>> to QEMU to change the default for isa-fdc
>>>
>>>
>>>> 2) xl cd-eject and cd-insert are not working:
>>>>
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
>>>> how=(nil) callback=(nil) poller=0x1b95930
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
>>>> suitable backend for disk hdb
>>> cd-eject should work by trying to insert an empty cdrom.
>>> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
>>> think this is not the case here.
>>> I guess it is a bug in parse_disk_config.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
>>>> how=(nil) callback=(nil) poller=0x1d079f0
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>>>> directory
>>> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
>>> of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> Seem there is parsing error about backend and device/iso path, for now I
>>>> not found solution for fix it on code.
>> I've added -nodefaults option to qemu upstream to remove empty floppy
>> and cdrom with success. Please could this be added by default on libxl
>> on qemu upstream starting?
> The problem with -nodefaults is that it changes a lot of other things
> aside from the floppy drive:
>
> default_serial = 0;
> default_parallel = 0;
> default_virtcon = 0;
> default_monitor = 0;
> default_vga = 0;
> default_net = 0;
> default_floppy = 0;
> default_cdrom = 0;
> default_sdcard = 0;
>
> libxl should always set the right command line options for vga and
> network, and most of the other settings don't matter for us.
> However I am concerned about the monitor and the cdrom drive.
>
> I thought that we always wanted to have a cdrom drive on HVM guests,
> even if empty.
>
> It would be better to find a way to change only the floppy default
> setting.
>
It seems there is no other way to disable default floppy only, what can
we do about it?
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
>> About cd-eject cd-insert parsing bug can you solve please?
> Yes, however I am a bit busy at the moment so it might take some time.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-02-04 13:14 ` Fabio Fantoni
@ 2013-02-04 13:20 ` Ian Campbell
2013-02-04 13:48 ` Fabio Fantoni
0 siblings, 1 reply; 13+ messages in thread
From: Ian Campbell @ 2013-02-04 13:20 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Ian Jackson, Stefano Stabellini
On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> > It would be better to find a way to change only the floppy default
> > setting.
> >
>
> It seems there is no other way to disable default floppy only, what can
> we do about it?
Patch upstream qemu to add an option to do this.
> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
Ian.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-02-04 13:20 ` Ian Campbell
@ 2013-02-04 13:48 ` Fabio Fantoni
2013-02-04 13:56 ` Ian Campbell
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Fantoni @ 2013-02-04 13:48 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Ian Jackson, Stefano Stabellini
Il 04/02/2013 14:20, Ian Campbell ha scritto:
> On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
>>> It would be better to find a way to change only the floppy default
>>> setting.
>>>
>> It seems there is no other way to disable default floppy only, what can
>> we do about it?
> Patch upstream qemu to add an option to do this.
>
>> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> Ian.
Thanks for reply, I asked it on qemu-devel, if nobody will make a patch,
I'll try to do it.
About my latest patch submission here, was it correct?
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-02-04 13:48 ` Fabio Fantoni
@ 2013-02-04 13:56 ` Ian Campbell
0 siblings, 0 replies; 13+ messages in thread
From: Ian Campbell @ 2013-02-04 13:56 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Ian Jackson, Stefano Stabellini
On Mon, 2013-02-04 at 13:48 +0000, Fabio Fantoni wrote:
> Il 04/02/2013 14:20, Ian Campbell ha scritto:
> > On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> >>> It would be better to find a way to change only the floppy default
> >>> setting.
> >>>
> >> It seems there is no other way to disable default floppy only, what can
> >> we do about it?
> > Patch upstream qemu to add an option to do this.
> >
> >> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> > Ian.
> Thanks for reply, I asked it on qemu-devel, if nobody will make a patch,
> I'll try to do it.
Excellent.
> About my latest patch submission here, was it correct?
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html
These are in my queue but I haven't gotten to them yet.
I'm hoping we can get a test gate push soon (we've not had one for a
couple of weeks) and I am holding off committing too much stuff in the
meantime).
Ian.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-30 11:28 ` Fabio Fantoni
@ 2013-02-08 16:21 ` Stefano Stabellini
0 siblings, 0 replies; 13+ messages in thread
From: Stefano Stabellini @ 2013-02-08 16:21 UTC (permalink / raw)
To: Fabio Fantoni
Cc: George Dunlap, xen-devel, Ian Jackson, Ian Campbell,
Stefano Stabellini
On Wed, 30 Jan 2013, Fabio Fantoni wrote:
> I done other test with qemu upstream, on restore of Windows 7 pro 64 bit
> domU with latest gplpv give these lines on logs:
>
> xen_ram_alloc: do not alloc 7f800000 bytes of ram at 0 when runstate is
> INMIGRATE
> xen_ram_alloc: do not alloc 800000 bytes of ram at 7f800000 when
> runstate is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80000000 when runstate
> is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80010000 when runstate
> is INMIGRATE
>
> All seem working except network (seem more gplpv problem already
> reported on other post), about this ram logs (first is very strange).
> Is it normal or maybe some bugs around?
Those messages are normal: RAM is already allocated at restore time.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-01-18 14:44 ` Fabio Fantoni
2013-01-18 15:51 ` Stefano Stabellini
2013-01-21 12:16 ` George Dunlap
@ 2013-03-11 11:55 ` Frediano Ziglio
2013-03-11 13:32 ` Fabio Fantoni
2 siblings, 1 reply; 13+ messages in thread
From: Frediano Ziglio @ 2013-03-11 11:55 UTC (permalink / raw)
To: fabio.fantoni@heliman.it
Cc: xen-devel@lists.xensource.com, Ian Jackson, Ian Campbell,
Stefano Stabellini
On Fri, 2013-01-18 at 15:44 +0100, Fabio Fantoni wrote:
> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
> > On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> >> 1) Both linux and windows domU with qemu upstream have an additional
> >> empty floppy and cdrom.
> >> Is there a way to remove these additionals block devices?
> > the best way would be to pass a device or a global command line option
> > to QEMU to change the default for isa-fdc
> >
> >
> >> 2) xl cd-eject and cd-insert are not working:
> >>
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
> >> how=(nil) callback=(nil) poller=0x1b95930
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
> >> backend phy unsuitable as phys path not a block device
> >> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
> >> suitable backend for disk hdb
> > cd-eject should work by trying to insert an empty cdrom.
> > In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
> > think this is not the case here.
> > I guess it is a bug in parse_disk_config.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
> >> how=(nil) callback=(nil) poller=0x1d079f0
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
> >> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
> >> directory
> > It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
> > of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> Seem there is parsing error about backend and device/iso path, for now I
> >> not found solution for fix it on code.
> I've added -nodefaults option to qemu upstream to remove empty floppy
> and cdrom with success. Please could this be added by default on libxl
> on qemu upstream starting?
>
> About cd-eject cd-insert parsing bug can you solve please?
>
Just sent a patch upstream to fix the issue.
Frediano
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Qemu upstream bugs with xen
2013-03-11 11:55 ` Frediano Ziglio
@ 2013-03-11 13:32 ` Fabio Fantoni
0 siblings, 0 replies; 13+ messages in thread
From: Fabio Fantoni @ 2013-03-11 13:32 UTC (permalink / raw)
To: Frediano Ziglio
Cc: xen-devel@lists.xensource.com, Ian Jackson, Ian Campbell,
fantonifabio@tiscali.it, Stefano Stabellini
Il 11/03/2013 12:55, Frediano Ziglio ha scritto:
> On Fri, 2013-01-18 at 15:44 +0100, Fabio Fantoni wrote:
>> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
>>> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>>>> 1) Both linux and windows domU with qemu upstream have an additional
>>>> empty floppy and cdrom.
>>>> Is there a way to remove these additionals block devices?
>>> the best way would be to pass a device or a global command line option
>>> to QEMU to change the default for isa-fdc
>>>
>>>
>>>> 2) xl cd-eject and cd-insert are not working:
>>>>
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
>>>> how=(nil) callback=(nil) poller=0x1b95930
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
>>>> suitable backend for disk hdb
>>> cd-eject should work by trying to insert an empty cdrom.
>>> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
>>> think this is not the case here.
>>> I guess it is a bug in parse_disk_config.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
>>>> how=(nil) callback=(nil) poller=0x1d079f0
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>>>> directory
>>> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
>>> of "/mnt/vm/iso/QUANTAL.iso". The format parsing must be wrong.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> Seem there is parsing error about backend and device/iso path, for now I
>>>> not found solution for fix it on code.
>> I've added -nodefaults option to qemu upstream to remove empty floppy
>> and cdrom with success. Please could this be added by default on libxl
>> on qemu upstream starting?
>>
>> About cd-eject cd-insert parsing bug can you solve please?
>>
> Just sent a patch upstream to fix the issue.
>
> Frediano
>
Thanks, is that one?
http://lists.xen.org/archives/html/xen-devel/2013-03/msg00806.html
Tried but not solve the problem :(
xl cd-eject W7 hdb
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
suitable backend for disk hdb
xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/XPSP3PRO.iso
libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x22709a0: create:
how=(nil) callback=(nil) poller=0x2270a00
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
vdev=hdb spec.backend=phy
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
backend phy unsuitable as phys path not a block device
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
suitable backend for disk hdb
libxl: debug: libxl_event.c:1551:libxl__ao_abort: ao 0x22709a0: abort
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x22709a0: destroy
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
Is there a way to reply on posts where I'm not in cc?
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-03-11 13:32 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-18 9:47 Qemu upstream bugs with xen Fabio Fantoni
2013-01-18 13:00 ` Stefano Stabellini
2013-01-18 14:44 ` Fabio Fantoni
2013-01-18 15:51 ` Stefano Stabellini
2013-02-04 13:14 ` Fabio Fantoni
2013-02-04 13:20 ` Ian Campbell
2013-02-04 13:48 ` Fabio Fantoni
2013-02-04 13:56 ` Ian Campbell
2013-01-21 12:16 ` George Dunlap
2013-01-30 11:28 ` Fabio Fantoni
2013-02-08 16:21 ` Stefano Stabellini
2013-03-11 11:55 ` Frediano Ziglio
2013-03-11 13:32 ` Fabio Fantoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).