[Qemu-devel] Add lz4 support in qemu parameters

[Fabio Fantoni]

Hi, lz4 support in qemu parameters is still missed.
I'm actually using the patch posted long time ago by Javier Celaya with
only the small version check fix (spice>=0.12.6 instead of >=0.12.7):
https://github.com/Fantu/qemu/commit/e66e58053cea9f0aff71c9d9b8b822e40f5ba266
Tested and working.
Original was here: https://patchwork.freedesktop.org/patch/41072/
Now that spice 0.12.6 with lz4 support has been released can be this
patch (plus the version fix) upstreamed for have lz4 support
"out-of-the-box" or improvements is needed before accepting it?

Thanks for any reply and sorry for my bad english.



smime.p7s
Description: Firma crittografica S/MIME

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

2015-10-19 18:57 GMT+02:00 Stefano Stabellini <
stefano.stabell...@eu.citrix.com>:

> On Mon, 19 Oct 2015, John Snow wrote:
> > On 10/19/2015 07:44 AM, Stefano Stabellini wrote:
> > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote:
> > >>   Hi,
> > >>
> >  I'm trying to follow this discussion as best as I am able, but my
> lack
> >  of experience with Xen prevents me from really participating in a
> >  meaningful way.
> > 
> >  (I see that Laszlo is still discussing some CD-ROM issues with Fabio
> >  which may be of interest to me...)
> > 
> >  At any rate, I won't be authoring any Xen-specific hacks to the AHCI
> >  device, but I do have plans to implement hot-plugging emulation as
> per
> >  the AHCI spec. Perhaps this is sufficient for the Xen layer, but
> someone
> >  else will need to author the appropriate glue code.
> > 
> >  If "real" hot-plugging is not sufficient, we'll need to discuss
> further,
> >  preferably over some RFC patches.
> > >>>
> > >>> That's fine. AHCI hot-plugging would go a long way and once we have
> > >>> that, the rest is easy.
> > >>
> > >> Can we get some more background on this?
> > >>
> > >> IIRC the IDE bits are needed to boot hvm guests, which goes like this:
> > >>
> > >>   (1) boot disk is hooked up using both xenbus and ide.
> > >>   (2) seabios boots using ide.
> > >>   (3) linux kernel activates xenbus, at which point qemu zaps the ide
> > >>   disks to avoid the disk being present twice in the system.
> > >>
> > >> Correct?
> > >>
> > >> Do we really want repeat this exercise for AHCI?  Alot has changed
> since
> > >> this boot hack for ide was added ...
> > >>
> > >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen
> > >> guests just fine without this, correct?
> > >
> > > I agree with you that the current unplug in nasty. Also I don't care
> > > much about AHCI, in fact I don't think we should be spending efforts
> > > into making that scenario work better. I think we should be working on
> > > OVMF instead and fix the bug about empty cdrom drives reported by
> Fabio.
> > >
> >
> > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug
> > any OVMF+SATA/AHCI problems that are reported.
> >
> > Last I saw, Laszlo asked Fabio for some more information on this
> > problem, so I am waiting for that information to start work on that
> issue.
>
> Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has
> already support for the Xen PV disk protocol, see
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c.
>

I not tried with ahci in ovmf in latest because as you told that is a
missing unplug case in qemu.

I tried with xendisk and ide, the empty cdrom problem is with both, from xl
domU cfg:

',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide.

Using seabios instead boot correctly, with ovmf not:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html

If I remember good also in latest test persist also the problem that
ovmf not respect the boot order parameter.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 19/10/2015 12:18, Stefano Stabellini ha scritto:

On Fri, 16 Oct 2015, John Snow wrote:

On 10/13/2015 01:10 PM, Stefano Stabellini wrote:

On Tue, 13 Oct 2015, John Snow wrote:

On 10/13/2015 11:55 AM, Fabio Fantoni wrote:

I added ahci disk support in libxl and using it for week seems that was
ok, after a reply of Stefano Stabellini seems that xen disk unplug
support only ide disks:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8

Today Paul Durrant told me that even if pv disk is ok also with ahci and
the emulated one is offline can be a risk:
http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html


I tried to take a fast look in qemu code but I not understand the needed
thing for add the xen disk unplug support also for ahci, can someone do
it or tell me useful information for do it please?

Thanks for any reply and sorry for my bad english.


I'm not entirely sure what features you need AHCI to support in order
for Xen to be happy.

I'd guess hotplugging, but where I get confused is that IDE disks don't
support hotplugging either, so I guess I'm not sure sure what you need.

Stefano, can you help bridge my Xen knowledge gap?
  
Hi John,


we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
can unplug AHCI disk. And by unplug, I mean "make disappear" like
pci_piix3_xen_ide_unplug does for ide.


I'm trying to follow this discussion as best as I am able, but my lack
of experience with Xen prevents me from really participating in a
meaningful way.

(I see that Laszlo is still discussing some CD-ROM issues with Fabio
which may be of interest to me...)

At any rate, I won't be authoring any Xen-specific hacks to the AHCI
device, but I do have plans to implement hot-plugging emulation as per
the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone
else will need to author the appropriate glue code.

If "real" hot-plugging is not sufficient, we'll need to discuss further,
preferably over some RFC patches.

That's fine. AHCI hot-plugging would go a long way and once we have
that, the rest is easy.

Thanks,

Stefano


Thanks for any improvement you will do.
About AHCI hotplugging will remove bad thing of actual "xen unplug" in 
seabios/ovmf but not the hybrid pv solution right?
Doing without hybrid like what I tried you told me with ovmf probably is 
better solution after solving other bugs but probably someone don't want 
plain remove it.


About empty cdrom not working in ovmf but needed by xl 
cd-insert/cd-eject I suppose that is easly reproducible, I had it in any 
case I tested.
If not and more details are needed tell me and I'll rebuild and test 
following Lazslo instructions.


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 16/10/2015 18:53, Paul Durrant ha scritto:

-Original Message-
From: Kevin Wolf [mailto:kw...@redhat.com]
Sent: 16 October 2015 17:43
To: Paul Durrant
Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu-
de...@nongnu.org; xen-de...@lists.xen.org; qemu-bl...@nongnu.org
Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci
missed in qemu

Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben:

-Original Message-
From: Kevin Wolf [mailto:kw...@redhat.com]
Sent: 16 October 2015 17:12
To: Paul Durrant
Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu-
de...@nongnu.org; xen-de...@lists.xen.org; qemu-bl...@nongnu.org
Subject: Re: [Qemu-devel] Question about xen disk unplug support for

ahci

missed in qemu

Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben:

-Original Message-
From: Kevin Wolf [mailto:kw...@redhat.com]
Sent: 16 October 2015 16:02
To: Paul Durrant
Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard;

qemu-

de...@nongnu.org; xen-de...@lists.xen.org; qemu-

bl...@nongnu.org

Subject: Re: [Qemu-devel] Question about xen disk unplug support

for

ahci

missed in qemu

Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben:

-Original Message-
From: Kevin Wolf [mailto:kw...@redhat.com]
Sent: 16 October 2015 15:04
To: Paul Durrant
Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard;

qemu-

de...@nongnu.org; xen-de...@lists.xen.org; qemu-

bl...@nongnu.org

Subject: Re: [Qemu-devel] Question about xen disk unplug

support

for

ahci

missed in qemu

Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben:

-Original Message-
From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
Sent: 14 October 2015 12:12
To: Kevin Wolf; Stefano Stabellini
Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org;

xen-

de...@lists.xen.org; qemu-bl...@nongnu.org; Paul Durrant
Subject: Re: [Qemu-devel] Question about xen disk unplug

support

for

ahci

missed in qemu



Il 14/10/2015 11:47, Kevin Wolf ha scritto:

[ CC qemu-block ]

Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:

On Tue, 13 Oct 2015, John Snow wrote:

On 10/13/2015 11:55 AM, Fabio Fantoni wrote:

I added ahci disk support in libxl and using it for week

seems

that

was

ok, after a reply of Stefano Stabellini seems that xen disk

unplug

support only ide disks:


http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39

c905374ee8663d5d8

Today Paul Durrant told me that even if pv disk is ok also

with

ahci

and

the emulated one is offline can be a risk:
http://lists.xenproject.org/archives/html/win-pv-

devel/2015-

10/msg00021.html


I tried to take a fast look in qemu code but I not

understand

the

needed

thing for add the xen disk unplug support also for ahci,

can

someone do

it or tell me useful information for do it please?

Thanks for any reply and sorry for my bad english.


I'm not entirely sure what features you need AHCI to

support

in

order

for Xen to be happy.

I'd guess hotplugging, but where I get confused is that IDE

disks

don't

support hotplugging either, so I guess I'm not sure sure

what

you

need.

Stefano, can you help bridge my Xen knowledge gap?

Hi John,

we need something like

hw/i386/xen/xen_platform.c:unplug_disks

but

that

can unplug AHCI disk. And by unplug, I mean "make

disappear"

like

pci_piix3_xen_ide_unplug does for ide.

Maybe this would be the right time to stop the craziness

with

your

hybrid IDE/xendisk setup. It's a horrible thing that would

never

happen

on real hardware.

Unfortunately, it's going to be difficult to remove such 'craziness'

when

you

don't know a priori whether the VM has PV drivers or not.

Why wouldn't you know that beforehand? I mean, even on real

hardware

you
can have different disk interfaces (IDE, AHCI, SCSI) and you install
the exact driver that your hardware needs. You just do the same

thing on

VM: If your hardware is PV, you install a PV driver. If your

hardware is

IDE, you install an IDE driver. Whether it's PV or IDE is something

that

you, the user, decided when configuring the VM, so you definitely

know.

That's not necessarily true. The host admin that provisions the VM

does

not

necessarily know what OS the user of that VM will install. The admin

may

just

be providing a generic VM with an emulated CD drive that the user

can

point

at any ISO they want.

So, as a host admin, if you provide a VM with only PV backends and

your

user is trying to boot an OS with no PV drivers they are not going to be
happy, so you provide emulated devices. Then, at some point later,

when

the user installs PV drivers, there really should be some way for those

drivers

to start up without any need to contact the host admin and have the

VM

reconfigured.

Why only IDE and xendisk then? Maybe I have an OS that works great

with

AHCI, or virtio-blk, 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 16/10/2015 12:47, Stefano Stabellini ha scritto:

On Fri, 16 Oct 2015, Fabio Fantoni wrote:

Il 16/10/2015 12:13, Anthony PERARD ha scritto:

On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:

Il 15/10/2015 20:02, Anthony PERARD ha scritto:

On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:

Il 14/10/2015 13:06, Stefano Stabellini ha scritto:

I would suggest Fabio to avoid AHCI disks altogether and just use
OVMF
with PV disks only and Anthony's patch to libxl to avoid creating
any
IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.

Would that work for you?

Thanks for the advice, I tried it:
https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6

I installed W10 pro 64 bit with ide disk, installed the win pv drivers
and
after changed to xvdX instead hdX, is the only change needed, right?
Initial boot is ok (ovmf part about pv disks seems ok) but windows
boot
fails with problem with pv drivers.
In attachment full qemu log with xen_platform trace and domU's xl cfg.

Someone have windows domUs with ovmf and pv disks only working? If yes
can
tell me the difference to understand what can be the problem please?

When I worked on the PV disk implementation in OVMF, I was able to boot
a Windows 8 with pv disk only.

I don't have access to the guest configuration I was using, but I think
one
difference would be the viridian setting, I'm pretty sure I did not set
it.


I tried with viridian disabled but did the same thing, looking cdrom as
latest thing before xenbug trace in qemu log I tried also to remove it but
also in this case don't boot correctly, full qemu log in attachment.
I don't know if is a ovmf thing to improve (like what seems in Laszlo and
Kevin mails) or xen winpv drivers unexpected case, have you tried also
with
latest winpv builds? (for exclude regression)

No, I did not tried the latest winpv drivers.

Sorry I can help much more that that. When I install this win8 guest tried
to boot it with pv drivers only, that was more than a year ago. I have not
check if it's still working. (Also I can not try anything more recent,
right now.)


I did many other tests, retrying with ide first boot working but show pv
devices not working, I did another reboot (with ide) and pv devices was
working, after I retried with pv (xvdX) and boot correctly.
After other tests I found that with empty cdrom device (required for xl
cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide
instead.
 From xl cfg:
disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']
With seabios domU boot also with empty cdrom.
In qemu log I found only these that can be related:

xen be: qdisk-51728: error: Could not open image: No such file or directory
xen be: qdisk-51728: initialise() failed

And latest xl dmesg line is:

(d1) Invoking OVMF ...

If you need more informations/test tell me and I'll post them.

Are you saying that without any cdrom drives, it works correctly?
Yes, I did also another test to be sure, starting with ide, installing 
windows, the pv drivers, rebooting 2 times (with one at boot of time 
boot with ide only and without net and disks pv drivers working) and 
after rebooting with pv disks (xvdX) works.
With cdrom not empty (with iso) works, with empty not, tried with both 
ide (hdX) and pv (xvdX).

Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case.
About major of winpv drivers problem at boot I suppose can be solved 
improving ovmf and winpv driver removing bad hybrid thing actually, but 
I have too low knowledge to be sure.
About the problem of pv start after install that requiring at least 2 
reboot can be also a windows 10 problem (only a suppose).


About empty cdrom with ovmf can be solved please?

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 16/10/2015 12:13, Anthony PERARD ha scritto:

On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:

Il 15/10/2015 20:02, Anthony PERARD ha scritto:

On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:

Il 14/10/2015 13:06, Stefano Stabellini ha scritto:

I would suggest Fabio to avoid AHCI disks altogether and just use OVMF
with PV disks only and Anthony's patch to libxl to avoid creating any
IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.

Would that work for you?

Thanks for the advice, I tried it:
https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6

I installed W10 pro 64 bit with ide disk, installed the win pv drivers and
after changed to xvdX instead hdX, is the only change needed, right?
Initial boot is ok (ovmf part about pv disks seems ok) but windows boot
fails with problem with pv drivers.
In attachment full qemu log with xen_platform trace and domU's xl cfg.

Someone have windows domUs with ovmf and pv disks only working? If yes can
tell me the difference to understand what can be the problem please?

When I worked on the PV disk implementation in OVMF, I was able to boot
a Windows 8 with pv disk only.

I don't have access to the guest configuration I was using, but I think one
difference would be the viridian setting, I'm pretty sure I did not set it.


I tried with viridian disabled but did the same thing, looking cdrom as
latest thing before xenbug trace in qemu log I tried also to remove it but
also in this case don't boot correctly, full qemu log in attachment.
I don't know if is a ovmf thing to improve (like what seems in Laszlo and
Kevin mails) or xen winpv drivers unexpected case, have you tried also with
latest winpv builds? (for exclude regression)

No, I did not tried the latest winpv drivers.

Sorry I can help much more that that. When I install this win8 guest tried
to boot it with pv drivers only, that was more than a year ago. I have not
check if it's still working. (Also I can not try anything more recent,
right now.)



I did many other tests, retrying with ide first boot working but show pv 
devices not working, I did another reboot (with ide) and pv devices was 
working, after I retried with pv (xvdX) and boot correctly.
After other tests I found that with empty cdrom device (required for xl 
cd-insert/cd-eject) boot stop at start (tianocore image), same result 
with ide instead.
From xl cfg: 
disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']

With seabios domU boot also with empty cdrom.
In qemu log I found only these that can be related:
xen be: qdisk-51728: error: Could not open image: No such file or 
directory

xen be: qdisk-51728: initialise() failed

And latest xl dmesg line is:

(d1) Invoking OVMF ...


If you need more informations/test tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 15/10/2015 20:02, Anthony PERARD ha scritto:

On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:

Il 14/10/2015 13:06, Stefano Stabellini ha scritto:

I would suggest Fabio to avoid AHCI disks altogether and just use OVMF
with PV disks only and Anthony's patch to libxl to avoid creating any
IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.

Would that work for you?

Thanks for the advice, I tried it:
https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6

I installed W10 pro 64 bit with ide disk, installed the win pv drivers and
after changed to xvdX instead hdX, is the only change needed, right?
Initial boot is ok (ovmf part about pv disks seems ok) but windows boot
fails with problem with pv drivers.
In attachment full qemu log with xen_platform trace and domU's xl cfg.

Someone have windows domUs with ovmf and pv disks only working? If yes can
tell me the difference to understand what can be the problem please?

When I worked on the PV disk implementation in OVMF, I was able to boot
a Windows 8 with pv disk only.

I don't have access to the guest configuration I was using, but I think one
difference would be the viridian setting, I'm pretty sure I did not set it.

I tried with viridian disabled but did the same thing, looking cdrom as 
latest thing before xenbug trace in qemu log I tried also to remove it 
but also in this case don't boot correctly, full qemu log in attachment.
I don't know if is a ovmf thing to improve (like what seems in Laszlo 
and Kevin mails) or xen winpv drivers unexpected case, have you tried 
also with latest winpv builds? (for exclude regression)


Thanks for any reply and sorry for my bad english.
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 17.727000 ms, bitrate 578858111 
bps (552.042113 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer: 
xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015)
xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x000EA020
xen_platform_log xen platform: XEN|SystemGetStartOptions:  TESTSIGNING  
NOEXECUTE=OPTIN  NOVGA
xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 
(BUILD 10240) PLATFORM WIN32_NT (x64)
xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES:
xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL
xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS
xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: 
WORKSTATION
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 
.1000 - .0009efff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 
.0010 - .eed94fff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 
.eee12000 - .efe91fff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 
.efef6000 - .effc
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 
.efff - .efff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 
0001. - 0001.07eaafff
xen_platform_log xen platform: XEN|AcpiGetXsdt: 0xFC012BA0
xen_platform_log xen platform: XEN|SystemProcessorInformation: > (0:0)
xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: 
GenuineIntel
xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 00
xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 00
xen_platform_log xen platform: XEN|SystemProcessorInformation: < (0:0)
xen_platform_log xen platform: XEN|SystemProcessorInformation: > (0:1)
xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: 
GenuineIntel
xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 02
xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 01
xen_platform_log xen platform: XEN|SystemProcessorInformation: < (0:1)
xen_platform_log xen platform: XEN: HYPERCALL PAGE 0 @ 0001.03dd4000
xen_platform_log xen platform: XENFILT|DriverEntry: 8.2.0 (80) (17.09.2015)
xen_platform_log xen platform: XEN: 4.6.0 (__XEN_INTERFACE_VERSION__ = 00040600)
xen_platform_log xen platform: XENFILT|FdoCreate: E0006B7A7C60 
(ACPI\PNP0A03\0)
xen_platform_log xen platform: XENFILT|PdoCreate: E0006B786A60 
(PCI\VEN_8086&DEV_1237&SUBSYS_11001AF4&REV_02\00)
xen_platform_log xen platform: XENFILT|PdoCreate: E0006B7DBC60 
(PCI\VEN_8086&DEV_7000&SUBSYS_11001AF4&REV_00\08)
xen_platform_log xen platform: XENFILT|PdoCreate: E0006B7DB880 
(PCI\VEN_8086&DEV_7010&SUBSYS_11001AF4&REV_00\09)
xen_platform_log xen platform: XENFILT|PdoCreate: E0006B7DCC60 
(PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10)
xen_platform_log xe

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 14/10/2015 13:06, Stefano Stabellini ha scritto:

On Wed, 14 Oct 2015, Kevin Wolf wrote:

[ CC qemu-block ]

Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:

On Tue, 13 Oct 2015, John Snow wrote:

On 10/13/2015 11:55 AM, Fabio Fantoni wrote:

I added ahci disk support in libxl and using it for week seems that was
ok, after a reply of Stefano Stabellini seems that xen disk unplug
support only ide disks:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8

Today Paul Durrant told me that even if pv disk is ok also with ahci and
the emulated one is offline can be a risk:
http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html


I tried to take a fast look in qemu code but I not understand the needed
thing for add the xen disk unplug support also for ahci, can someone do
it or tell me useful information for do it please?

Thanks for any reply and sorry for my bad english.


I'm not entirely sure what features you need AHCI to support in order
for Xen to be happy.

I'd guess hotplugging, but where I get confused is that IDE disks don't
support hotplugging either, so I guess I'm not sure sure what you need.

Stefano, can you help bridge my Xen knowledge gap?
  
Hi John,


we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
can unplug AHCI disk. And by unplug, I mean "make disappear" like
pci_piix3_xen_ide_unplug does for ide.

Maybe this would be the right time to stop the craziness with your
hybrid IDE/xendisk setup. It's a horrible thing that would never happen
on real hardware.

I would be quite happy to stop (or even get rid of) the craziness.



Can't you just teach SeaBIOS how to deal with your PV disks and then
only add that to your VM and forget about IDE/AHCI? I mean, that's how
it's done for virtio-blk, and it doesn't involve any insanities like
ripping out non-hotpluggable devices.

Teaching SeaBIOS to deal with PV disks can be done, in fact we already
support PV disks in OVMF. It is possible to boot Windows with OVMF
without any IDE disks (patch pending for libxl to create a VM without
emulated IDE disks).

However we have to be honest that implementing PV disk support in
SeaBIOS is a different magnitude of effort compared to implementing AHCI
"unplug".

I would suggest Fabio to avoid AHCI disks altogether and just use OVMF
with PV disks only and Anthony's patch to libxl to avoid creating any
IDE disks: http://marc.info/?l=xen-devel&m=144482080812353.

Would that work for you?


Thanks for the advice, I tried it:
https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6

I installed W10 pro 64 bit with ide disk, installed the win pv drivers 
and after changed to xvdX instead hdX, is the only change needed, right?
Initial boot is ok (ovmf part about pv disks seems ok) but windows boot 
fails with problem with pv drivers.

In attachment full qemu log with xen_platform trace and domU's xl cfg.

Someone have windows domUs with ovmf and pv disks only working? If yes 
can tell me the difference to understand what can be the problem please?






Hm... How does a reboot of a machine that had its IDE already removed
actually work? Do you restart the qemu process on reboot?

Restart QEMU, yes.


main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 8.258000 ms, bitrate 727789623 
bps (694.074271 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer: 
xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015)
xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x000EA020
xen_platform_log xen platform: XEN|SystemGetStartOptions:  TESTSIGNING  
NOEXECUTE=OPTIN  NOVGA
xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 
(BUILD 10240) PLATFORM WIN32_NT (x64)
xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES:
xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL
xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS
xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: 
WORKSTATION
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 
.1000 - .0009efff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 
.0010 - .eed94fff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 
.eee12000 - .efe91fff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 
.efef6000 - .effc
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 
.efff - .efff
xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 
0001. - 0001.07eaafff
xen_platform_log xen platform: XEN|AcpiGetXsdt: 0xFC012BA0
xen_platform_log xen platform: XEN|SystemProcessorInforma

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

Il 14/10/2015 11:47, Kevin Wolf ha scritto:

[ CC qemu-block ]

Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:

On Tue, 13 Oct 2015, John Snow wrote:

On 10/13/2015 11:55 AM, Fabio Fantoni wrote:

I added ahci disk support in libxl and using it for week seems that was
ok, after a reply of Stefano Stabellini seems that xen disk unplug
support only ide disks:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8

Today Paul Durrant told me that even if pv disk is ok also with ahci and
the emulated one is offline can be a risk:
http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html


I tried to take a fast look in qemu code but I not understand the needed
thing for add the xen disk unplug support also for ahci, can someone do
it or tell me useful information for do it please?

Thanks for any reply and sorry for my bad english.


I'm not entirely sure what features you need AHCI to support in order
for Xen to be happy.

I'd guess hotplugging, but where I get confused is that IDE disks don't
support hotplugging either, so I guess I'm not sure sure what you need.

Stefano, can you help bridge my Xen knowledge gap?
  
Hi John,


we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
can unplug AHCI disk. And by unplug, I mean "make disappear" like
pci_piix3_xen_ide_unplug does for ide.

Maybe this would be the right time to stop the craziness with your
hybrid IDE/xendisk setup. It's a horrible thing that would never happen
on real hardware.

Can't you just teach SeaBIOS how to deal with your PV disks and then
only add that to your VM and forget about IDE/AHCI? I mean, that's how
it's done for virtio-blk, and it doesn't involve any insanities like
ripping out non-hotpluggable devices.

Hm... How does a reboot of a machine that had its IDE already removed
actually work? Do you restart the qemu process on reboot?

Kevin
I thinkthat would be a good idea, unfortunately I'm not able to do that 
and I do not know if the developers of xen would agree to such modification.


If will be done, for example having new disk type "xenpv" require the pv 
drivers installed, with linux having drivers included should not be a 
problem but on windows yes FWIK.
Like virtio driver should be installed before (or adding them in windows 
install), I don't know if will be ok specifying them in install for with 
xen driver, another possibility can be start domU with ide disk type, 
install the xen pv drivers and reboot selecting xenpv disk type instead.
Doing it FWIK require not only xen and qemu changes but also pv drivers 
change, I added on cc also Paul Durrant for see what think about.
With actual unplug based on my tests in some years I had many problem 
with windows domUs (with both old and new pv drivers) resulting in 
"windows boot blue screen error", I suppose that changing/improving 
unplug method can decrease them, is it correct?


About reboot xen do different from kvm recreating full domU each time 
(and new qemu process), I don't know if is possible and good change the 
method.


Thanks for any reply and sorry for my bad english.

[Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

I added ahci disk support in libxl and using it for week seems that was 
ok, after a reply of Stefano Stabellini seems that xen disk unplug 
support only ide disks:

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
Today Paul Durrant told me that even if pv disk is ok also with ahci and 
the emulated one is offline can be a risk:

http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html

I tried to take a fast look in qemu code but I not understand the needed 
thing for add the xen disk unplug support also for ahci, can someone do 
it or tell me useful information for do it please?


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Spice-devel] [PATCH] [RFC] LZ4 compression option for SPICE

[Fabio Fantoni]

Il 27/01/2015 09:26, Markus Armbruster ha scritto:
> Eric Blake  writes:
>
>> On 01/26/2015 01:48 AM, Javier Celaya wrote:
>>> Sorry, I forgot to patch the command-line help. Hope it helps.
>>>
> Recently, SPICE included the lz4 compression algorithm. This patch adds
> a command line option to select it.
 How is libvirt going to introspect whether the command line supports
 this option?  Is there some QMP command that lists the set of valid
 compression formats understood by a given qemu binary?
>> No, patching the command line --help does NOT help libvirt.  It needs to
>> be discoverable via QMP to be introspectible, as scraping --help output
>> is not machine-friendly.  (That said, you DO want to expose it in --help
>> output; I'm just complaining that --help output alone is not enough).
> We should really, really, really provide access to (the relevant subset
> of) the QAPI schema over QMP!  Until we get that, useful progress is
> delayed by problems like this one, and we keep growing special-purpose
> solutions to problems like this one.
> ___
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>

Hi, spice 0.12.6 with lz4 support has been released, is there any
possibility to add it also in qemu upstream to make possible selecting
it "Out of the box" please?



smime.p7s
Description: Firma crittografica S/MIME

Re: [Qemu-devel] [Spice-devel] [PATCH] [RFC] LZ4 compression option for SPICE

[Fabio Fantoni]

Il 27/01/2015 09:26, Markus Armbruster ha scritto:
> Eric Blake  writes:
>
>> On 01/26/2015 01:48 AM, Javier Celaya wrote:
>>> Sorry, I forgot to patch the command-line help. Hope it helps.
>>>
> Recently, SPICE included the lz4 compression algorithm. This patch adds
> a command line option to select it.
 How is libvirt going to introspect whether the command line supports
 this option?  Is there some QMP command that lists the set of valid
 compression formats understood by a given qemu binary?
>> No, patching the command line --help does NOT help libvirt.  It needs to
>> be discoverable via QMP to be introspectible, as scraping --help output
>> is not machine-friendly.  (That said, you DO want to expose it in --help
>> output; I'm just complaining that --help output alone is not enough).
> We should really, really, really provide access to (the relevant subset
> of) the QAPI schema over QMP!  Until we get that, useful progress is
> delayed by problems like this one, and we keep growing special-purpose
> solutions to problems like this one.
> ___
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>

Hi, any news about spice lz4 support still missed in qemu upstream?

Thanks for any reply.



smime.p7s
Description: Firma crittografica S/MIME

Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen/HVM: atomically access pointers in bufioreq handling

[Fabio Fantoni]

Il 23/07/2015 08:59, Jan Beulich ha scritto:

The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. The hypervisor side gets I/O req server creation
extended so we can indicate that we're using suitable atomic accesses
where needed, allowing it to atomically canonicalize both pointers when
both have gone through at least one cycle.

The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) went in already (commit b7007bc6f9).


If I understand good a xen 4.6 is needed to build qemu with this patch, 
if yes probably is good add also a change to configure of require xen 
>=4.6, instead qemu will fail to build if xen version if lower.




Signed-off-by: Jan Beulich 
---
v2: Adjust description.

--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -957,19 +957,30 @@ static void handle_ioreq(XenIOState *sta
  
  static int handle_buffered_iopage(XenIOState *state)

  {
+buffered_iopage_t *buf_page = state->buffered_io_page;
  buf_ioreq_t *buf_req = NULL;
  ioreq_t req;
  int qw;
  
-if (!state->buffered_io_page) {

+if (!buf_page) {
  return 0;
  }
  
  memset(&req, 0x00, sizeof(req));
  
-while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {

-buf_req = &state->buffered_io_page->buf_ioreq[
-state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
+for (;;) {
+uint32_t rdptr = buf_page->read_pointer, wrptr;
+
+xen_rmb();
+wrptr = buf_page->write_pointer;
+xen_rmb();
+if (rdptr != buf_page->read_pointer) {
+continue;
+}
+if (rdptr == wrptr) {
+break;
+}
+buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
  req.size = 1UL << buf_req->size;
  req.count = 1;
  req.addr = buf_req->addr;
@@ -981,15 +992,14 @@ static int handle_buffered_iopage(XenIOS
  req.data_is_ptr = 0;
  qw = (req.size == 8);
  if (qw) {
-buf_req = &state->buffered_io_page->buf_ioreq[
-(state->buffered_io_page->read_pointer + 1) % 
IOREQ_BUFFER_SLOT_NUM];
+buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
+   IOREQ_BUFFER_SLOT_NUM];
  req.data |= ((uint64_t)buf_req->data) << 32;
  }
  
  handle_ioreq(state, &req);
  
-xen_mb();

-state->buffered_io_page->read_pointer += qw ? 2 : 1;
+atomic_add(&buf_page->read_pointer, qw + 1);
  }
  
  return req.count;

--- unstable.orig/qemu/upstream/include/hw/xen/xen_common.h 2015-03-31 
15:58:04.0 +0200
+++ unstable/qemu/upstream/include/hw/xen/xen_common.h  2015-06-15 
08:24:28.0 +0200
@@ -370,7 +370,8 @@ static inline void xen_unmap_pcidev(XenX
  static inline int xen_create_ioreq_server(XenXC xc, domid_t dom,
ioservid_t *ioservid)
  {
-int rc = xc_hvm_create_ioreq_server(xc, dom, 1, ioservid);
+int rc = xc_hvm_create_ioreq_server(xc, dom, HVM_IOREQSRV_BUFIOREQ_ATOMIC,
+ioservid);
  
  if (rc == 0) {

  trace_xen_ioreq_server_create(*ioservid);

Re: [Qemu-devel] [Xen-devel] qemu mainline regression with xen-unstable: unable to start QMP

[Fabio Fantoni]

Il 05/06/2015 00:20, Don Slutz ha scritto:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/15 18:10, Eric Blake wrote:

[adding Markus, as author of the regression]

On 06/04/2015 03:59 PM, Don Slutz wrote:

On 06/04/15 11:04, Fabio Fantoni wrote:

Today after trying xen-unstable build (tested many hours) of
some days ago I tried update qemu to latest development version
(from git master commit
6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there
is a regression:

xl create /etc/xen/W7.cfg Parsing config from
/etc/xen/W7.cfg libxl: error:
libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: QMP input object member 'id' is
unexpected libxl: error:
libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect to
QMP

This is caused by:

commit 65207c59d99f2260c5f1d3b9c491146616a522aa Author: Markus
Armbruster  Date:   Thu Mar 5 14:35:26 2015
+0100

monitor: Drop broken, unused asynchronous command interface

The patch:


 From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17
00:00:00 2001

From: Don Slutz  Date: Thu, 4 Jun 2015
17:04:42 -0400 Subject: [PATCH 01/14] monitor: Allow Xen's
(broken) usage of asynchronous command interface.


Thanks, patch tested, solves the regression, I did successfull many xl 
command that use QMP.




commit 65207c59d99f2260c5f1d3b9c491146616a522aa Author: Markus
Armbruster  Date:   Thu Mar 5 14:35:26 2015
+0100

monitor: Drop broken, unused asynchronous command interface

Breaks Xen.  Add a hack un unbreak it.

s/un /to /

Sigh, will fix.


Xen is only doing synchronous commands, but is including an id.

QMP also uses id, but apparently removes it up front before calling
into this function; so another fix would be having xen remove it up
front.


Hopefully I will get to a change to Xen.  However getting the Xen
change back-ported to enough version(s) will not be quick...



Signed-off-by: Don Slutz  --- monitor.c | 9
+ 1 file changed, 9 insertions(+)

diff --git a/monitor.c b/monitor.c index c7baa91..e9a0747 100644
--- a/monitor.c +++ b/monitor.c @@ -4955,6 +4955,15 @@ static
QDict *qmp_check_input_obj(QObject *input_obj, Error **errp)
"arguments", "object"); return NULL; } +} else if
(!strcmp(arg_name, "id")) { +/* + * Fixup
Xen's usage. Just ignore the "id". See point #5 + *
above.  This was an attempt at an asynchronous + *
command interface.  However commit + *
65207c59d99f2260c5f1d3b9c491146616a522aa is + *
wrong. Xen does not expect an error when it passes in +
* "id":1, so just continue to ignore it. + */

The comment is a bit verbose, particularly since 'id' is a
well-established usage pattern in QMP.  Also, we don't need to call
out why it changed in the comment here, the commit message is
sufficient for that.


Ok, will also see if Markus has anything to say.

-Don Slutz


} else { error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name); return
NULL;


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJVcM85AAoJEMH0lYjxq9Kcvd0QAK5H6/2NUvqKCO/zje/8cXsT
ueLOYG4keNWJ3x7XGpOAWqIuYc673uYjApEquSpR2TRyhHwB2ZuShEjtCA5bakOH
VJJ03uLq+vrQo0Hxm8oR5/7C2w0L2GkpzGnqUlmZ6/9RNbDHGmGS6PSUC5xbwICM
6v31k0b89HG4AmAxg3/O5qeBe9m/pL+OeDjKXc6zbr7xhUIq4lxtx0VEy4HAGReS
V8+MLDJ73T6o6FUD6U/EcCmK/6GuMMG0jwZsVgbBvbeGmT1tP8Z9YMjpf3X393ZG
Il9LaUNCzhJRcWVOc4UBM8du3FLcHX4fviYyW5uEXt4aJdSoijd4BAv2znyyndmu
oep7vEc5w/VkXKuXxg1hTokCqvkLEK6WYD4M+i1huiBuNs3qQop6euqYV97tEsl3
h3fjhibkZRbIVsm6vrm41Jr75ZDnbftPMAINc9aYvvstNrxBrR7u7sw6gwAY1n6+
e5gyy5l5P6/R3LS4s41oXSOiCk7pndPp3AilOZ863MS5TJFXLfo1z0wEQ471A2hT
NHvi+o4G2iKZ33MAB9Jq6hmWveJbs8sY+Fm/IWeZn/dDt7ohn8V+rFIX3LEYfDMN
cknhMSRpKD9eRSo4LM4xU9kq1J5spaewDbkGkl7e6pHVTWphLlkk/cT2W9crW3ji
PybnLaIJP2/aljcLfdYK
=lEbh
-END PGP SIGNATURE-

[Qemu-devel] qemu mainline regression with xen-unstable: unable to start QMP

[Fabio Fantoni]

Today after trying xen-unstable build (tested many hours) of some days 
ago I tried update qemu to latest development version (from git master 
commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is 
a regression:

xl create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an 
error message from QMP server: QMP input object member 'id' is unexpected
libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect 
to QMP


DomU is working but operations that require QMP not (for example 
save/restore).


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH][RFC] libxl: use new qemu parameters for emulated qemuu disks

[Fabio Fantoni]

Il 18/05/2015 17:43, Wei Liu ha scritto:

On Fri, May 15, 2015 at 01:54:32PM +0200, Fabio Fantoni wrote:

NOTES:
This patch is a only a fast draft for testing.

Some tests result:
At xl create cdrom empty or not  are both working, xl cd-insert is
working, xl cd-eject seems working but on xl command in linux hvm domU
return qmp error of "Device 'ide-N' is locked", in windows 7 instead
don't show the errror.
xl block-attach seems working correctly and xl block-detach works
correctly with linux hvm but not with windows 7 (seems block the disk
remove, I don't know if do the same without this patch)
Scsi disk case not tested for now.

Any comment is appreciated.


I presume you're trying to use AHCI?

Already used many times with many domUs.

  Do you notice improvement using
AHCI when booting a guest?


The more significant is with lubuntu 15.04 hvm where time boot time to 
login is only about a fifth!!! in comparison to without.
With windows 7 pro 64 bit is different in many case, in better case the 
boot time is about a third, in the worst it seems to gain only 10-20% of 
the time.
With windows 8.1 the gain is only 5-10% but with win8 the boot time is 
very long in any case, I don't know if caused by unexpected case in xen 
or windows 8 is simply bad or weighty.


The ahci support patch is here:
http://lists.xen.org/archives/html/xen-devel/2015-05/msg01804.html

This is about changes qemu parameters for other disk cases.




Signed-off-by: Fabio Fantoni 
---
  tools/libxl/libxl_dm.c | 35 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4bec5ba..6d00e38 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -811,7 +811,6 @@ static char ** libxl__build_device_model_args_new(libxl__gc 
*gc,
  int dev_number =
  libxl__device_disk_dev_number(disks[i].vdev, &disk, &part);
  const char *format = qemu_disk_format_string(disks[i].format);
-char *drive;
  const char *pdev_path;
  
  if (dev_number == -1) {

@@ -822,13 +821,14 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
  
  if (disks[i].is_cdrom) {

  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
-drive = libxl__sprintf
-(gc, 
"if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
- disk, dev_number);
+flexarray_vappend(dm_args, "-drive",
+GCSPRINTF("if=none,id=ide-%i,cache=writeback", dev_number), 
"-device",
+GCSPRINTF("ide-cd,drive=ide-%i", dev_number), NULL);
  else
-drive = libxl__sprintf
-(gc, 
"file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
- disks[i].pdev_path, disk, format, dev_number);
+flexarray_vappend(dm_args, "-drive",
+
GCSPRINTF("file=%s,if=none,id=ide-%i,format=%s,cache=writeback",
+disks[i].pdev_path, dev_number, format), "-device",
+GCSPRINTF("ide-cd,drive=ide-%i", dev_number), NULL);
  } else {
  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
  LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
@@ -857,25 +857,26 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
   * hd[a-d] and ignore the rest.
   */
  if (strncmp(disks[i].vdev, "sd", 2) == 0)
-drive = libxl__sprintf
-(gc, 
"file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
- pdev_path, disk, format);
+flexarray_vappend(dm_args, "-drive",
+
GCSPRINTF("file=%s,if=none,id=scsidisk-%d,format=%s,cache=writeback",
+pdev_path, disk, format), "-device",
+GCSPRINTF("scsi-hd,drive=scsidisk-%d,scsi-id=%d",
+disk, disk), NULL);
  else if (disk < 6 && libxl_defbool_val(b_info->u.hvm.ahci)){

I don't see a "ahci" field in libxl idl. Did you forget to commit that
part?

Another question is that do we always want to enable AHCI? Do we want to
make it user tunable? This affects if you actually need a new field in
idl.

Wei.


  flexarray_vappend(dm_args, "-drive",
  
GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback",
-pdev_path, disk, f

Re: [Qemu-devel] [Xen-devel] [PATCH][RFC] libxl: use new qemu parameters for emulated qemuu disks

[Fabio Fantoni]

Il 18/05/2015 13:24, George Dunlap ha scritto:

On Fri, May 15, 2015 at 12:54 PM, Fabio Fantoni  wrote:

NOTES:
This patch is a only a fast draft for testing.

Some tests result:
At xl create cdrom empty or not  are both working, xl cd-insert is
working, xl cd-eject seems working but on xl command in linux hvm domU
return qmp error of "Device 'ide-N' is locked", in windows 7 instead
don't show the errror.
xl block-attach seems working correctly and xl block-detach works
correctly with linux hvm but not with windows 7 (seems block the disk
remove, I don't know if do the same without this patch)
Scsi disk case not tested for now.

Any comment is appreciated.

I think what's missing in this changelog is why we want this patch --
what's the advantage?  Was some of the functionality above not working
before, for example?

  -George


Add of ahci support require new -device parameters, I tried the change 
also all other cases to have the same.
Is there also rare case of possible problem using old parameters on part 
of things (disks, network, audio and older usb if I remember good) but I 
not remember the example case, was found by another user.
With this patch I'm trying to maintan full compatibility but probably 
there is something that I don't know that must be changed or may changes 
with this.

[Qemu-devel] [PATCH][RFC] libxl: use new qemu parameters for emulated qemuu disks

[Fabio Fantoni]

NOTES:
This patch is a only a fast draft for testing.

Some tests result:
At xl create cdrom empty or not  are both working, xl cd-insert is
working, xl cd-eject seems working but on xl command in linux hvm domU
return qmp error of "Device 'ide-N' is locked", in windows 7 instead
don't show the errror.
xl block-attach seems working correctly and xl block-detach works
correctly with linux hvm but not with windows 7 (seems block the disk
remove, I don't know if do the same without this patch)
Scsi disk case not tested for now.

Any comment is appreciated.

Signed-off-by: Fabio Fantoni 
---
 tools/libxl/libxl_dm.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4bec5ba..6d00e38 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -811,7 +811,6 @@ static char ** libxl__build_device_model_args_new(libxl__gc 
*gc,
 int dev_number =
 libxl__device_disk_dev_number(disks[i].vdev, &disk, &part);
 const char *format = qemu_disk_format_string(disks[i].format);
-char *drive;
 const char *pdev_path;
 
 if (dev_number == -1) {
@@ -822,13 +821,14 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
 
 if (disks[i].is_cdrom) {
 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
-drive = libxl__sprintf
-(gc, 
"if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
- disk, dev_number);
+flexarray_vappend(dm_args, "-drive",
+GCSPRINTF("if=none,id=ide-%i,cache=writeback", 
dev_number), "-device",
+GCSPRINTF("ide-cd,drive=ide-%i", dev_number), NULL);
 else
-drive = libxl__sprintf
-(gc, 
"file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
- disks[i].pdev_path, disk, format, dev_number);
+flexarray_vappend(dm_args, "-drive",
+
GCSPRINTF("file=%s,if=none,id=ide-%i,format=%s,cache=writeback",
+disks[i].pdev_path, dev_number, format), "-device",
+GCSPRINTF("ide-cd,drive=ide-%i", dev_number), NULL);
 } else {
 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
 LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
@@ -857,25 +857,26 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
  * hd[a-d] and ignore the rest.
  */
 if (strncmp(disks[i].vdev, "sd", 2) == 0)
-drive = libxl__sprintf
-(gc, 
"file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
- pdev_path, disk, format);
+flexarray_vappend(dm_args, "-drive",
+
GCSPRINTF("file=%s,if=none,id=scsidisk-%d,format=%s,cache=writeback",
+pdev_path, disk, format), "-device",
+GCSPRINTF("scsi-hd,drive=scsidisk-%d,scsi-id=%d",
+disk, disk), NULL);
 else if (disk < 6 && libxl_defbool_val(b_info->u.hvm.ahci)){
 flexarray_vappend(dm_args, "-drive",
 
GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback",
-pdev_path, disk, format), "-device", 
GCSPRINTF("ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d",
+pdev_path, disk, format), "-device",
+
GCSPRINTF("ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d",
 disk, disk), NULL);
-continue;
 }else if (disk < 4)
-drive = libxl__sprintf
-(gc, 
"file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
- pdev_path, disk, format);
+flexarray_vappend(dm_args, "-drive",
+
GCSPRINTF("file=%s,if=none,id=idedisk-%d,format=%s,cache=writeback",
+pdev_path, disk, format), "-device", 
GCSPRINTF("ide-hd,drive=idedisk-%d",
+disk), NULL);
 else
 continue; /* Do not emulate this disk */
 }
 
-flexarray_append(dm_args, "-drive");
-flexarray_append(dm_args, drive);
 }
 
 switch (b_info->u.hvm.vendor_device) {
-- 
1.9.1

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 12/05/2015 16:44, Stefano Stabellini ha scritto:

On Tue, 12 May 2015, Stefano Stabellini wrote:

On Tue, 12 May 2015, Fabio Fantoni wrote:

Il 12/05/2015 12:26, Fabio Fantoni ha scritto:

Il 12/05/2015 11:23, Fabio Fantoni ha scritto:

Il 11/05/2015 17:04, Fabio Fantoni ha scritto:

Il 21/04/2015 14:53, Stefano Stabellini ha scritto:

On Tue, 21 Apr 2015, Fabio Fantoni wrote:

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:

I updated xen and qemu from xen 4.5.0 with its upstream qemu
included to
xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk
to use
revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash,
tried 2 times
with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion
`(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned
long)
(old_size) >= (unsigned long)__builtin_offsetof (struct
malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 *
(sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
pagemask)
==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable
cause of
regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa
spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

Maybe you could try to revert the offending commit
(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect
the
crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm busy
trying to
found another problem that cause very bad performance without errors
or
nothing in logs :( I don't know if if xen related, kernel related or
other for
now.

About this regression with spice I'll do further tests in next days
(probably
starting reverting the spice patch in qemu) but any help is
appreciated.
Based on data I have for now is possible that the problem is that
qemu try to
allocate other ram or videoram after domU create but with xen is not
possible?
In the spice related patch I saw something about dynamic allocation
for
example.

It is probably caused by a commit in the range:

1ebb75b1fee779621b63e84fefa7b07354c43a99..0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4

there are only 10 commits in that range. By using git bisect you
should
be able to narrow it down in just 3 tests.

Sorry for delay, I was busy with many things, today I retried with
updated stable-4.5 and also reverting "spice: make sure we don't
overflow ssd->buf" (in a second test) but in both case regression remain
:(
Tomorrow probably I'll do other tests.

I did another test, reverting this instead:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commit;h=c9ac5f816bf3a8b56f836b078711dcef6e5c90b8
And now seems I'm unable to reproduce the regression, before happen after
few seconds up to 1-2 minutes, now I use the same domU 15-20 minutes
without problem.
Probably is the cause of regression even if seems strange that on unstable
with same patch on tests of some days ago didn't happen.

Any ideas?

Thanks for any reply and sorry for my bad english.

Bad news, qemu crash still happen even if this time in qemu log there is
another output, see attachment.
After take a look on the other patches I saw:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commitdiff;h=7154fba0e51ec985ef621965d1b7120ad424fcbf
With "Conflicts: hw/display/vga.c" in description I'll try to revert it
instead.

Or someone can tell me another probable test I can try?

Tried also to revet the patch above with same result, so I retried with qemu
from 4.5.0 and seems the crash happen also in this case...I'm going crazy :(

Sorry, I missed this bit before. The only thing I could suggest at this
point, would be to make sure that you have a clean test environment.
Usually this happens when you have some "leftovers" from previous broken
tests.


I use make debball to be sure to track and remove all files on package 
update.
Now I retried with latest xen-unstable and the qemu crash didn't happen, 
more exactly I used this:

https://github.com/Fantu/Xen/commits/rebase/m2r-staging
Latest test with regression based on latest stable-4.5, more exactly:
https://github.com/Fantu/Xen/commits/rebase/m2r-testing
Some days ago on same dom0 and domU I tried with latest stable version 
(that I use on only 2 production servers for now but I not saw the 
regression), more exactly:

https://github.com/Fantu/Xen/commits/rebase/m2r-s

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 12/05/2015 12:26, Fabio Fantoni ha scritto:

Il 12/05/2015 11:23, Fabio Fantoni ha scritto:

Il 11/05/2015 17:04, Fabio Fantoni ha scritto:

Il 21/04/2015 14:53, Stefano Stabellini ha scritto:

On Tue, 21 Apr 2015, Fabio Fantoni wrote:

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:
I updated xen and qemu from xen 4.5.0 with its upstream qemu 
included to

xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk 
to use

revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, 
tried 2 times

with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned long)
(old_size) >= (unsigned long)__builtin_offsetof (struct
malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * 
(sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & 
pagemask)

==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable 
cause of

regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa 


spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

   Maybe you could try to revert the offending commit
(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect 
the

crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm 
busy trying to
found another problem that cause very bad performance without 
errors or
nothing in logs :( I don't know if if xen related, kernel related 
or other for

now.

About this regression with spice I'll do further tests in next 
days (probably
starting reverting the spice patch in qemu) but any help is 
appreciated.
Based on data I have for now is possible that the problem is that 
qemu try to
allocate other ram or videoram after domU create but with xen is 
not possible?
In the spice related patch I saw something about dynamic 
allocation for

example.

It is probably caused by a commit in the range:

1ebb75b1fee779621b63e84fefa7b07354c43a99..0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4 



there are only 10 commits in that range. By using git bisect you 
should

be able to narrow it down in just 3 tests.


Sorry for delay, I was busy with many things, today I retried with 
updated stable-4.5 and also reverting "spice: make sure we don't 
overflow ssd->buf" (in a second test) but in both case regression 
remain :(

Tomorrow probably I'll do other tests.


I did another test, reverting this instead:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commit;h=c9ac5f816bf3a8b56f836b078711dcef6e5c90b8 

And now seems I'm unable to reproduce the regression, before happen 
after few seconds up to 1-2 minutes, now I use the same domU 15-20 
minutes without problem.
Probably is the cause of regression even if seems strange that on 
unstable with same patch on tests of some days ago didn't happen.


Any ideas?

Thanks for any reply and sorry for my bad english.


Bad news, qemu crash still happen even if this time in qemu log there 
is another output, see attachment.

After take a look on the other patches I saw:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commitdiff;h=7154fba0e51ec985ef621965d1b7120ad424fcbf 

With "Conflicts: hw/display/vga.c" in description I'll try to revert 
it instead.


Or someone can tell me another probable test I can try?


Tried also to revet the patch above with same result, so I retried with 
qemu from 4.5.0 and seems the crash happen also in this case...I'm going 
crazy :(


In attachment full gdb log.

Any ideas on how to found the problem please?

Thanks for any reply and sorry for my bad english.
Full backtrace:
#0  0x736e8165 in *__GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
pid = 
selftid = 
#1  0x736eb3e0 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0x58ddeba0, sa_sigaction 
= 0x58ddeba0}, sa_mask = {__val = {140737278660816, 140737014337136, 4, 
140737014337376, 140737277706678, 206158430256, 140737014337416, 
140737014337168, 87, 226653584, 140737351936019, 140737488348083, 
140737278647399, 140737278651152, 3096, 140737277299604}}, sa_flags = 
-474017696, sa_restorer = 0x736b9c60}
sigs = {__val = {32, 0 }}
#2  0x7372bdea in __malloc_assert (assertion=, 
file=, line=, function=) at 
malloc.c:351
No locals.
#3  0x7372ed13 in sYSMALLOc

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 12/05/2015 11:23, Fabio Fantoni ha scritto:

Il 11/05/2015 17:04, Fabio Fantoni ha scritto:

Il 21/04/2015 14:53, Stefano Stabellini ha scritto:

On Tue, 21 Apr 2015, Fabio Fantoni wrote:

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:
I updated xen and qemu from xen 4.5.0 with its upstream qemu 
included to

xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk 
to use

revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, 
tried 2 times

with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned long)
(old_size) >= (unsigned long)__builtin_offsetof (struct
malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * 
(sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & 
pagemask)

==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable 
cause of

regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa 


spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

   Maybe you could try to revert the offending commit
(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect the
crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm busy 
trying to
found another problem that cause very bad performance without 
errors or
nothing in logs :( I don't know if if xen related, kernel related 
or other for

now.

About this regression with spice I'll do further tests in next days 
(probably
starting reverting the spice patch in qemu) but any help is 
appreciated.
Based on data I have for now is possible that the problem is that 
qemu try to
allocate other ram or videoram after domU create but with xen is 
not possible?
In the spice related patch I saw something about dynamic allocation 
for

example.

It is probably caused by a commit in the range:

1ebb75b1fee779621b63e84fefa7b07354c43a99..0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4 



there are only 10 commits in that range. By using git bisect you should
be able to narrow it down in just 3 tests.


Sorry for delay, I was busy with many things, today I retried with 
updated stable-4.5 and also reverting "spice: make sure we don't 
overflow ssd->buf" (in a second test) but in both case regression 
remain :(

Tomorrow probably I'll do other tests.


I did another test, reverting this instead:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commit;h=c9ac5f816bf3a8b56f836b078711dcef6e5c90b8 

And now seems I'm unable to reproduce the regression, before happen 
after few seconds up to 1-2 minutes, now I use the same domU 15-20 
minutes without problem.
Probably is the cause of regression even if seems strange that on 
unstable with same patch on tests of some days ago didn't happen.


Any ideas?

Thanks for any reply and sorry for my bad english.


Bad news, qemu crash still happen even if this time in qemu log there is 
another output, see attachment.

After take a look on the other patches I saw:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commitdiff;h=7154fba0e51ec985ef621965d1b7120ad424fcbf
With "Conflicts: hw/display/vga.c" in description I'll try to revert it 
instead.


Or someone can tell me another probable test I can try?
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 7.814000 ms, bitrate 5417989417 
bps (5166.997354 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer: 
main_channel_handle_parsed: agent start
main_channel_handle_parsed: agent start
red_channel_client_disconnect: rcc=0x7fa861b2eb60 (channel=0x7fa861b07e80 
type=3 id=0)
red_channel_client_disconnect: rcc=0x7fa862349720 (channel=0x7fa861bc8b80 
type=2 id=0)
red_channel_client_disconnect: rcc=0x7fa861ca6580 (channel=0x7fa861bb3990 
type=4 id=0)
red_channel_client_disconnect_dummy: rcc=0x7fa861ecae20 (channel=0x7fa861c22c40 
type=6 id=0)
snd_channel_put: SndChannel=0x7fa861e6f620 freed
red_channel_client_disconnect_dummy: rcc=0x7fa861ec6be0 (channel=0x7fa861b8c890 
type=5 id=0)
snd_channel_put: SndChannel=0x7fa861d97ab0 freed
red_channel_client_disconnect: rcc=0x7fa861fbf120 (channel=0x7fa861bd57b0 
type=9 id=0)
red_channel_client_disconnect: rcc=0x7fa861fbaee0 (channel=0x7fa861baff50 
type=9 id=1)
red_channel_client_disconnect: rcc=0x7fa861eff170 (channel=0x7fa861c79f90 
type=9 id=2)
red_channel_clien

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 11/05/2015 17:04, Fabio Fantoni ha scritto:

Il 21/04/2015 14:53, Stefano Stabellini ha scritto:

On Tue, 21 Apr 2015, Fabio Fantoni wrote:

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:
I updated xen and qemu from xen 4.5.0 with its upstream qemu 
included to

xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk to 
use

revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, tried 
2 times

with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned long)
(old_size) >= (unsigned long)__builtin_offsetof (struct
malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * 
(sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & 
pagemask)

==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable 
cause of

regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa 


spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

   Maybe you could try to revert the offending commit
(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect the
crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm busy 
trying to

found another problem that cause very bad performance without errors or
nothing in logs :( I don't know if if xen related, kernel related or 
other for

now.

About this regression with spice I'll do further tests in next days 
(probably
starting reverting the spice patch in qemu) but any help is 
appreciated.
Based on data I have for now is possible that the problem is that 
qemu try to
allocate other ram or videoram after domU create but with xen is not 
possible?

In the spice related patch I saw something about dynamic allocation for
example.

It is probably caused by a commit in the range:

1ebb75b1fee779621b63e84fefa7b07354c43a99..0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4 



there are only 10 commits in that range. By using git bisect you should
be able to narrow it down in just 3 tests.


Sorry for delay, I was busy with many things, today I retried with 
updated stable-4.5 and also reverting "spice: make sure we don't 
overflow ssd->buf" (in a second test) but in both case regression 
remain :(

Tomorrow probably I'll do other tests.


I did another test, reverting this instead:
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.5-testing.git;a=commit;h=c9ac5f816bf3a8b56f836b078711dcef6e5c90b8
And now seems I'm unable to reproduce the regression, before happen 
after few seconds up to 1-2 minutes, now I use the same domU 15-20 
minutes without problem.
Probably is the cause of regression even if seems strange that on 
unstable with same patch on tests of some days ago didn't happen.


Any ideas?

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 21/04/2015 14:53, Stefano Stabellini ha scritto:

On Tue, 21 Apr 2015, Fabio Fantoni wrote:

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:

I updated xen and qemu from xen 4.5.0 with its upstream qemu included to
xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk to use
revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, tried 2 times
with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned long)
(old_size) >= (unsigned long)__builtin_offsetof (struct
malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask)
==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable cause of
regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa
spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

   Maybe you could try to revert the offending commit
(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect the
crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm busy trying to
found another problem that cause very bad performance without errors or
nothing in logs :( I don't know if if xen related, kernel related or other for
now.

About this regression with spice I'll do further tests in next days (probably
starting reverting the spice patch in qemu) but any help is appreciated.
Based on data I have for now is possible that the problem is that qemu try to
allocate other ram or videoram after domU create but with xen is not possible?
In the spice related patch I saw something about dynamic allocation for
example.

It is probably caused by a commit in the range:

1ebb75b1fee779621b63e84fefa7b07354c43a99..0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4

there are only 10 commits in that range. By using git bisect you should
be able to narrow it down in just 3 tests.


Sorry for delay, I was busy with many things, today I retried with 
updated stable-4.5 and also reverting "spice: make sure we don't 
overflow ssd->buf" (in a second test) but in both case regression remain :(

Tomorrow probably I'll do other tests.

Re: [Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

Il 21/04/2015 12:49, Stefano Stabellini ha scritto:

On Mon, 20 Apr 2015, Fabio Fantoni wrote:

I updated xen and qemu from xen 4.5.0 with its upstream qemu included to xen
4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk to use
revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, tried 2 times
with same result.

In the domU's qemu log:

qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof
(struct malloc_chunk, fd && old_size == 0) || ((unsigned long)
(old_size) >= (unsigned long)__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) ==
0)' failed.
Killing all inferiors

In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable cause of
regression (I'm not sure):
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa
spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.
  
Maybe you could try to revert the offending commit

(5c3402816aaddb15156c69df73c54abe4e1c76aa)? Or even better bisect the
crash?

Thanks for your reply.

I reverted to 4.5.0 on dom0 for now on that system because I'm busy 
trying to found another problem that cause very bad performance without 
errors or nothing in logs :( I don't know if if xen related, kernel 
related or other for now.


About this regression with spice I'll do further tests in next days 
(probably starting reverting the spice patch in qemu) but any help is 
appreciated.
Based on data I have for now is possible that the problem is that qemu 
try to allocate other ram or videoram after domU create but with xen is 
not possible?
In the spice related patch I saw something about dynamic allocation for 
example.

[Qemu-devel] Regression: qemu crash of hvm domUs with spice (backtrace included)

[Fabio Fantoni]

I updated xen and qemu from xen 4.5.0 with its upstream qemu included to 
xen 4.5.1-pre with qemu upstream from stable-4.5 (changed Config.mk to 
use revision "master").
After few minutes I booted windows 7 64 bit domU qemu crash, tried 2 
times with same result.


In the domU's qemu log:
qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top == 
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - 
__builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || 
((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof 
(struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & 
~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && 
((unsigned long)old_end & pagemask) == 0)' failed.

Killing all inferiors


In attachment the full backtrace of qemu crash.

With a fast search after I saw the backtrace I found a probable cause of 
regression (I'm not sure):

http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.5-testing.git;a=commit;h=5c3402816aaddb15156c69df73c54abe4e1c76aa
spice: make sure we don't overflow ssd->buf

Added also qemu-devel and spice-devel as cc.

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.


Program received signal SIGABRT, Aborted.
[Switching to Thread 5234]
0x73905165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0  0x73905165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x739083e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x73948dea in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x7394bd13 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x7394da70 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x74d38550 in spice_malloc (n_bytes=1184900) at mem.c:93
mem = 
__FUNCTION__ = "spice_malloc"
#6  0x74d389be in spice_chunks_linearize (chunks=0x7fffdc1fb6b0)
at mem.c:226
data = 
p = 
i = 
#7  0x74d16b56 in canvas_bitmap_to_surface (
canvas=canvas@entry=0x56719de0, bitmap=bitmap@entry=0x7fffdc1a2c08, 
palette=0x0, want_original=1) at ../spice-common/common/canvas_base.c:635
src = 
image = 
format = 
__FUNCTION__ = "canvas_bitmap_to_surface"
---Type  to continue, or q  to quit---
#8  0x74d16ce2 in canvas_get_bits (want_original=, 
bitmap=0x7fffdc1a2c08, canvas=0x56719de0)
at ../spice-common/common/canvas_base.c:964
palette = 
#9  canvas_get_image_internal (canvas=canvas@entry=0x56719de0, 
image=0x7fffdc1a2bf0, want_original=, 
want_original@entry=0, real_get=real_get@entry=1)
at ../spice-common/common/canvas_base.c:1141
descriptor = 0x7fffdc1a2bf0
surface = 
converted = 
wanted_format = 1
surface_format = 
saved_want_original = 
__FUNCTION__ = "canvas_get_image_internal"
#10 0x74d173ba in canvas_get_image (
canvas=canvas@entry=0x56719de0, image=, 
want_original=want_original@entry=0)
at ../spice-common/common/canvas_base.c:1285
No locals.
#11 0x74d1970e in canvas_draw_copy (spice_canvas=0x56719de0, 
bbox=0x7fffdc207a50, clip=, copy=0x7fffe4dfc320)
at ../spice-common/common/canvas_base.c:2258
canvas = 0x56719de0
dest_region = {extents = {x1 = 0, y1 = 708, x2 = 425, y2 = 728}, 
---Type  to continue, or q  to quit---
  data = 0x0}
surface_canvas = 
src_image = 
rop = SPICE_ROP_COPY
__FUNCTION__ = "canvas_draw_copy"
#12 0x74cecffc in red_draw_qxl_drawable (
worker=worker@entry=0x7fffe4423010, 
drawable=drawable@entry=0x7fffe45d6a88) at red_worker.c:4394
copy = {src_bitmap = 0x7fffdc1a2bf0, src_area = {left = 0, top = 677, 
right = 425, bottom = 697}, rop_descriptor = 8, 
  scale_mode = 1 '\001', mask = {flags = 245 '\365', pos = {
  x = -173079809, y = -173079809}, bitmap = 0x0}}
img1 = {descriptor = {id = 93825007287960, type = 48 '0', 
flags = 193 '\301', width = 21845, height = 4210421981}, u = {
bitmap = {format = 55 '7', flags = 10 '\n', x = 0, 
  y = 3867565524, stride = 32767, palette = 0x7fffe805fffc, 
  palette_id = 606579, data = 0x7fffdc78}, quic = {
  data_size = 2615, data = 0x7fffe6865dd4}, surface = {
  surface_id = 2615}, lz_rgb = {data_size = 2615, 
  data = 0x7fffe6865dd4}, lz_plt = {flags = 55 '7', 
  data_size = 0, palette = 0x7fffe6865dd4, 
  palette_id = 140737086095356, data = 0x94173}, jpeg = {
  data_size = 2615, data = 0x7fffe6865dd4}, zlib_glz = {
  glz_data_size = 2615, data_size = 0, data = 0x7fffe

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 21/11/2014 15:43, Fabio Fantoni ha scritto:

Il 21/11/2014 12:05, Fabio Fantoni ha scritto:

Il 20/11/2014 12:21, Fabio Fantoni ha scritto:

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with
spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
as kvm
except for one problem after xl save/restore, when after 
restore on
spice client connect  the domU's screen freezed for 2-3 
minutes (and
seems also windows), after this time seems that all return 
to works

correctly.
This problem happen also if spice client connect long time 
after restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable 
set

 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after 
restore:


(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:127

Re: [Qemu-devel] Question and probable bug in qemu spice's parameters

[Fabio Fantoni]

Il 09/01/2015 12:23, Gerd Hoffmann ha scritto:

On Fr, 2015-01-09 at 11:30 +0100, Fabio Fantoni wrote:

In qemu docs seems that spice streaming video is default to "filter" but
after this patch seems default to "off" without updating qemu-options.hx
file:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f1d3e586f069e17f83b669842bc02d60d509daca
What is the correct default actually?

It should be filter, but the filter heuristics actually has trouble
distinguishing real videos from gnome desktop, resulting in bad display
quality.  Switching to "off" was meant to be a temporary stopgap for
that.

Anyone can comment what is the state here?  Became the heuristic better
meanwhile, so we can flip it back to filter?  Otherwise we should
probably fixup the docs to match reality ...


If I specify spice image compression, qemu doesn't start and gives me
this error:
spice: invalid stream video control: (null)

Hmm, can't reproduce.
What is the exact command line leading to this error?


Sorry, I saw only now that this is caused by my mistake in one libxl 
patch to implement it.




cheers,
   Gerd

[Qemu-devel] Question and probable bug in qemu spice's parameters

[Fabio Fantoni]

In qemu docs seems that spice streaming video is default to "filter" but 
after this patch seems default to "off" without updating qemu-options.hx 
file: 
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f1d3e586f069e17f83b669842bc02d60d509daca

What is the correct default actually?

If I specify spice image compression, qemu doesn't start and gives me 
this error:

spice: invalid stream video control: (null)

To solve I have to set also qemu spice's streaming video parameters.

Why qemu doesn't take automatically the default of spice image 
compression in this case?


Thanks for any reply.

Re: [Qemu-devel] [Spice-devel] [PATCH] [RFC] LZ4 compression option for SPICE

[Fabio Fantoni]

Il 08/01/2015 11:50, Javier Celaya ha scritto:
> Hello
>
> Recently, SPICE included the lz4 compression algorithm. This patch adds
> a command line option to select it. However, SPICE_IMAGE_COMPRESS_LZ4 did not 
> exist before the commit that added this compression algorithm, so it should 
> be 
> guarded with conditional compilation. How do you think this should be done? 
> Wait for the next stable version of spice-server and check for 
> SPICE_SERVER_VERSION? Or add a specific flag?
>
> Thank you
> ---
>  ui/spice-core.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ui/spice-core.c b/ui/spice-core.c
> index 6467fa4..fb6534e 100644
> --- a/ui/spice-core.c
> +++ b/ui/spice-core.c
> @@ -359,6 +359,7 @@ static const char *compression_names[] = {
>  [ SPICE_IMAGE_COMPRESS_QUIC ] = "quic",
>  [ SPICE_IMAGE_COMPRESS_GLZ ]  = "glz",
>  [ SPICE_IMAGE_COMPRESS_LZ ]   = "lz",
> +[ SPICE_IMAGE_COMPRESS_LZ4 ]  = "lz4",
>  };
>  #define parse_compression(_name)\
>  parse_name(_name, "image compression",  \
> --
> 1.9.3

I did a small search now and seems that also other small change to
qemu-options.hx file should be done, search this line:
@item image-compression=[auto_glz|auto_lz|quic|glz|lz|off]

>
> ___
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>




smime.p7s
Description: Firma crittografica S/MIME

Re: [Qemu-devel] [Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-win7-amd64

[Fabio Fantoni]

Il 30/12/2014 08:52, xen.org ha scritto:

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-win7-amd64
test windows-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

   Bug is in tree:  qemuu git://git.qemu.org/qemu.git
   Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
   Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


   commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
   Author: Marcel Apfelbaum 
   Date:   Tue Dec 16 16:58:05 2014 +
   
   machine: remove qemu_machine_opts global list
   
   QEMU has support for options per machine, keeping

   a global list of options is no longer necessary.
   
   Signed-off-by: Marcel Apfelbaum 

   Reviewed-by: Alexander Graf 
   Reviewed-by: Greg Bellows 
   Message-id: 1418217570-15517-2-git-send-email-marce...@redhat.com
   Signed-off-by: Peter Maydell 


In the automatic test the qemu log contain:

qemu-system-i386: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc 
&& opt->desc->type == QEMU_OPT_BOOL' failed.
Is there unexpected case in the qemu patch spotted by bisection or qemu 
parameters in libxl need improvements (probably machinearg cases in 
libxl_dm.c)?


Thanks for any reply and sorry for my bad english.




For bisection revision-tuple graph see:

http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Searching for failure / basis pass:
  32689 fail [host=rice-weevil] / 32598 ok.
Failure / basis pass flights: 32689 / 32598
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
7e58e2ac7778cca3234c33387e49577bb7732714 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
 
git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809
 
git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
  32585 pass irrelevant
  32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
7e58e2ac7778cca3234c33387e49577bb7732714 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
  32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
  32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
  32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
  32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
  32855 fail 83a926f7a4e39fb6be0576

[Qemu-devel] xorg crash on Fedora 21 xen hvm domUs with qxl (log with backtrace included)

[Fabio Fantoni]

On my latest test with xen 4.5 and qemu 2.2 (from git) linux hvm domU 
(Fedora 21) has no more crashed without any useful information in log 
but was crashed only xorg on start:



[20.653] (EE)
[20.653] (EE) Backtrace:
[20.668] (EE) 0: /usr/libexec/Xorg.bin (OsLookupColor+0x119) 
[0x59bf79]

[20.669] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7fbba151a94f]
[20.669] (EE) 2: /lib64/libpixman-1.so.0 
(_pixman_internal_only_get_implementation+0x2ce2b) [0x7fbba26d249b]
[20.670] (EE) 3: /lib64/libpixman-1.so.0 
(_pixman_internal_only_get_implementation+0x2cf79) [0x7fbba26d2899]
[20.670] (EE) 4: /lib64/libpixman-1.so.0 
(pixman_image_composite32+0x451) [0x7fbba261d711]
[20.670] (EE) 5: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(_init+0x47d0) [0x7fbb9c687d20]
[20.670] (EE) 6: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(_init+0x48df) [0x7fbb9c687e9f]
[20.671] (EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(_init+0xfa3a) [0x7fbb9c69e1aa]
[20.671] (EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(_init+0x1937d) [0x7fbb9c6b142d]
[20.671] (EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(_init+0x12c47) [0x7fbb9c6a4587]
[20.671] (EE) 10: /usr/libexec/Xorg.bin 
(DamageRegionAppend+0x18b5) [0x5212e5]
[20.671] (EE) 11: /usr/libexec/Xorg.bin (miPaintWindow+0x1f6) 
[0x579c16]
[20.671] (EE) 12: /usr/libexec/Xorg.bin (miWindowExposures+0x18f) 
[0x57a4ef]
[20.672] (EE) 13: /usr/libexec/Xorg.bin 
(miHandleValidateExposures+0x68) [0x590108]

[20.672] (EE) 14: /usr/libexec/Xorg.bin (MapWindow+0x18a) [0x4656fa]
[20.672] (EE) 15: /usr/libexec/Xorg.bin (ProcBadRequest+0x5f5) 
[0x433d85]
[20.672] (EE) 16: /usr/libexec/Xorg.bin (SendErrorToClient+0x2f7) 
[0x439027]
[20.672] (EE) 17: /usr/libexec/Xorg.bin (remove_fs_handlers+0x416) 
[0x43d186]
[20.673] (EE) 18: /lib64/libc.so.6 (__libc_start_main+0xf0) 
[0x7fbba1505fe0]

[20.673] (EE) 19: /usr/libexec/Xorg.bin (_start+0x29) [0x42761e]
[20.673] (EE) 20: ? (?+0x29) [0x29]
[20.673] (EE)
[20.673] (EE) Segmentation fault at address 0x7fbb9c67a000
[20.673] (EE)
Fatal server error:
[20.673] (EE) Caught signal 11 (Segmentation fault). Server aborting
[20.673] (EE)
[20.673] (EE)


Full xorg log in attachment.
Can someone help me to solve this problem please?

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [PATCH 0/4] virtio-net: do not leak cpu mappings

[Fabio Fantoni]

Il 25/11/2014 15:42, Stefano Stabellini ha scritto:

Hi all,
this patch series fixes a cpu mapping leak in virtio-net.

The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov.

This causes a crash when running on Xen, but the behaviour is obviously
incorrect without Xen too.

The patch series fixes the issue by allowing virtio_net_handle_ctrl to
unmap the original out_sg iov but still call virtqueue_fill and
virtqueue_flush on the modified iov.

The first three patches do not introduce any functional changes.


Thanks for these pathes, 1-2 years ago I tried to use virtio net and 
disks on xen unsuccessful and I was unable to solve it.

When I'll have time I'll retry.
About virtio disks can have problem similar to this or should be ok?
About the other patches posted in link below are all not applied and 
should be only rebased or they must be fully revisioned/modified?

http://wiki.xen.org/wiki/Virtio_On_Xen

Thanks for any reply and sorry for my bad english.




Stefano Stabellini (4):
   introduce virtqueue_unmap_sg
   use virtqueue_unmap_sg in virtqueue_fill
   move virtqueue_unmap_sg calls from virtqueue_fill to virtqueue_push
   virtio-net: do not leak cpu mappings

  hw/net/virtio-net.c|9 -
  hw/virtio/virtio.c |   43 ---
  include/hw/virtio/virtio.h |2 ++
  3 files changed, 34 insertions(+), 20 deletions(-)

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

Re: [Qemu-devel] [BUGFIX][PATCH for 2.2 v6 1/1] -machine vmport=auto: Fix handling of VMWare ioport emulation for xen

[Fabio Fantoni]

On Fri, Nov 21, 2014 at 11:18:52AM -0500, Don Slutz wrote:
>/  c/s 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4/
>/  /
>/  or/
>/  /
>/  c/s b154537ad07598377ebf98252fb7d2aff127983b/
>/  /
>/  moved the testing of xen_enabled() from pc_init1() to/
>/  pc_machine_initfn()./
>/  /
>/  xen_enabled() does not return the correct value in/
>/  pc_machine_initfn()./
>/  /
>/  Changed vmport from a bool to an enum.  Added the value "auto" to do/
>/  the old way.  Move check of xen_enabled() back to pc_init1()./
>/  /
>/  Signed-off-by: Don Slutz /
>/  Acked-by: Eric Blake /

Reviewed-by: Eduardo Habkost 

Thanks for your patience with the many requests for changes.

--
Eduardo


This patch need more testing before applying it?
If yes I'll do a fast test ASAP.

Thanks for any reply.

[Qemu-devel] qemu crash with virtio on Xen domUs (backtrace included)

[Fabio Fantoni]

Il 24/11/2014 02:58, Wen Congyang ha scritto:

When I try to use virtio on xen(HVM guest), qemu crashed. Here is the backtrace:
(gdb) bt
#0  0x7f49581f0b55 in raise () from /lib64/libc.so.6
#1  0x7f49581f2131 in abort () from /lib64/libc.so.6
#2  0x7f495af2af32 in xen_ram_addr_from_mapcache (ptr=0x7f4951858ac8) at 
/root/work/xen/tools/qemu-xen-dir/xen-mapcache.c:316
#3  0x7f495ae30fb3 in qemu_ram_addr_from_host (ptr=0x7f4951858ac8, 
ram_addr=0x7fff564dc9b0) at /root/work/xen/tools/qemu-xen-dir/exec.c:1508
#4  0x7f495ae33424 in address_space_unmap (as=0x7f495b7c3520, 
buffer=0x7f4951858ac8, len=6, is_write=0, access_len=6) at 
/root/work/xen/tools/qemu-xen-dir/exec.c:2315
#5  0x7f495ae335b3 in cpu_physical_memory_unmap (buffer=0x7f4951858ac8, 
len=6, is_write=0, access_len=6) at 
/root/work/xen/tools/qemu-xen-dir/exec.c:2353
#6  0x7f495ae9058d in virtqueue_fill (vq=0x7f495b931250, 
elem=0x7fff564dcb00, len=1, idx=0) at 
/root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:258
#7  0x7f495ae90a0d in virtqueue_push (vq=0x7f495b931250, 
elem=0x7fff564dcb00, len=1) at 
/root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:286
#8  0x7f495ae82cf3 in virtio_net_handle_ctrl (vdev=0x7f495b92a5d0, 
vq=0x7f495b931250) at /root/work/xen/tools/qemu-xen-dir/hw/net/virtio-net.c:806
#9  0x7f495ae925e5 in virtio_queue_notify_vq (vq=0x7f495b931250) at 
/root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:729
#10 0x7f495ae926c3 in virtio_queue_notify (vdev=0x7f495b92a5d0, n=2) at 
/root/work/xen/tools/qemu-xen-dir/hw/virtio/virtio.c:735
#11 0x7f495ad743c2 in virtio_ioport_write (opaque=0x7f495b929cd0, addr=16, 
val=2) at hw/virtio/virtio-pci.c:301
#12 0x7f495ad74923 in virtio_pci_config_write (opaque=0x7f495b929cd0, 
addr=16, val=2, size=2) at hw/virtio/virtio-pci.c:433
#13 0x7f495ae9f071 in memory_region_write_accessor (mr=0x7f495b92a468, 
addr=16, value=0x7fff564e8d08, size=2, shift=0, mask=65535) at 
/root/work/xen/tools/qemu-xen-dir/memory.c:441
#14 0x7f495ae9f1ad in access_with_adjusted_size (addr=16, value=0x7fff564e8d08, 
size=2, access_size_min=1, access_size_max=4, access=0x7f495ae9efe8 
, mr=0x7f495b92a468)
 at /root/work/xen/tools/qemu-xen-dir/memory.c:478
#15 0x7f495aea200e in memory_region_dispatch_write (mr=0x7f495b92a468, 
addr=16, data=2, size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:985
#16 0x7f495aea5824 in io_mem_write (mr=0x7f495b92a468, addr=16, val=2, 
size=2) at /root/work/xen/tools/qemu-xen-dir/memory.c:1744
#17 0x7f495ae328d3 in address_space_rw (as=0x7f495b7c3600, addr=49200, 
buf=0x7fff564e8e60 "\002", len=2, is_write=true) at 
/root/work/xen/tools/qemu-xen-dir/exec.c:2029
#18 0x7f495ae32c85 in address_space_write (as=0x7f495b7c3600, addr=49200, 
buf=0x7fff564e8e60 "\002", len=2) at 
/root/work/xen/tools/qemu-xen-dir/exec.c:2091
#19 0x7f495ae9c130 in cpu_outw (addr=49200, val=2) at 
/root/work/xen/tools/qemu-xen-dir/ioport.c:77
#20 0x7f495af289d0 in do_outp (addr=49200, size=2, val=2) at 
/root/work/xen/tools/qemu-xen-dir/xen-hvm.c:668
#21 0x7f495af28b94 in cpu_ioreq_pio (req=0x7f495ab25000) at 
/root/work/xen/tools/qemu-xen-dir/xen-hvm.c:729
#22 0x7f495af28ee5 in handle_ioreq (req=0x7f495ab25000) at 
/root/work/xen/tools/qemu-xen-dir/xen-hvm.c:781
#23 0x7f495af29237 in cpu_handle_ioreq (opaque=0x7f495b884ad0) at 
/root/work/xen/tools/qemu-xen-dir/xen-hvm.c:856
#24 0x7f495ad7d2c2 in qemu_iohandler_poll (pollfds=0x7f495b823820, ret=1) 
at iohandler.c:143
#25 0x7f495ad7e2fd in main_loop_wait (nonblocking=0) at main-loop.c:485
#26 0x7f495ae1386f in main_loop () at vl.c:2056
#27 0x7f495ae1af17 in main (argc=35, argv=0x7fff564e94c8, 
envp=0x7fff564e95e8) at vl.c:4535
(gdb) q



Added qemu-devel and qemu maintainer in xen to cc.

@Wen Congyang: when you report a bug is useful add more details and 
logs, domU's xl cfg, domU's qemu log, xen and qemu version used ecc...

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 21/11/2014 12:05, Fabio Fantoni ha scritto:

Il 20/11/2014 12:21, Fabio Fantoni ha scritto:

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with
spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
as kvm
except for one problem after xl save/restore, when after 
restore on
spice client connect  the domU's screen freezed for 2-3 
minutes (and
seems also windows), after this time seems that all return to 
works

correctly.
This problem happen also if spice client connect long time 
after restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after 
restore:


(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
(4) to

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 20/11/2014 12:21, Fabio Fantoni ha scritto:

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with
spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good 
as kvm
except for one problem after xl save/restore, when after 
restore on
spice client connect  the domU's screen freezed for 2-3 
minutes (and
seems also windows), after this time seems that all return to 
works

correctly.
This problem happen also if spice client connect long time 
after restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
(4) to (32) frames.

(XEN) irq.c:380: Dom2 callback vi

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 13/11/2014 13:22, Fabio Fantoni ha scritto:

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with
spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as 
kvm
except for one problem after xl save/restore, when after 
restore on
spice client connect  the domU's screen freezed for 2-3 minutes 
(and
seems also windows), after this time seems that all return to 
works

correctly.
This problem happen also if spice client connect long time 
after restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from 
(4) to (32) frames.

(XEN) irq.c:380: Dom2 callback via changed to GSI 24

Tested on latest staging (com

Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)

[Fabio Fantoni]

Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here.  But you are pointing at the 
wrong change.


commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4

Is what I am guessing at this time is the issue.  I think that 
xen_enabled() is
returning false in pc_machine_initfn.  Where as in pc_init1 is is 
returning true.


I am thinking that:


diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
 .desc = "Xen Fully-virtualized PC",
 .init = pc_xen_hvm_init,
 .max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = "accel=xen",
+.default_machine_opts = "accel=xen,vmport=off",
 .hot_add_cpu = pc_hot_add_cpu,
 };
 #endif

Will fix your issue. I have not tested this yet.


Tested now and it solves regression of linux hvm domUs with qemu 2.2, 
thanks.
I think that I'm not the only with this regression and that this patch 
(or a fix to the cause in vmport) should be applied before qemu 2.2 final.




    -Don Slutz


On 11/19/14 09:04, Fabio Fantoni wrote:

Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" 
patches, and qemu 2.2 from spice git (spice/next commit 
e779fa0a715530311e6f59fc8adb0f6eca914a89):

https://github.com/Fantu/Xen/commits/rebase/m2r-staging


I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the 
full backtrace of latest test:

Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0, 
addr=0,

size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73  eax = env->regs[R_EAX];
(gdb) bt full
#0  0x55689b07 in vmport_ioport_read (opaque=0x564443a0, 
addr=0,

size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = "vmport_ioport_read"
env = 0x8250
command = 0 '\000'
eax = 0
#1  0x55655fc4 in memory_region_read_accessor 
(mr=0x5628,

addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2  0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 , 
mr=0x5628)

at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3  0x556590e9 in memory_region_dispatch_read1 
(mr=0x5628,

addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4  0x556591b1 in memory_region_dispatch_read 
(mr=0x5628,

addr=0, pval=0x7fffd9a8, size=4)
---Type  to continue, or q  to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5  0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6  0x5560a1ca in address_space_rw (as=0x55eaf920, 
addr=22104,

buf=0x7fffda50 "\377\377\377\377", len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 "%s/%d:\n"
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7  0x5560a38f in address_space_read (as=0x55eaf920, 
addr=22104,

buf=0x7fffda50 "\377\377\377\377", len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
#8  0x5564fd4b in cpu_inl (addr=22104)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = "\377\377\377\377"
val = 21845
#9  0x55670c73 in do_inp (addr=22104, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
---Type  to continue, or q  to quit---
No locals.
#10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 1
#11 0x556714b3 in handle_ioreq (state=0x563c2510,
req=0x77ff3020) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853

No locals.
#12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
state = 0x563c2510
req = 0x77ff3020
#13 0x5596e240 in qemu_iohandler_poll 
(pollfds=0x56389a30, ret=1)

at iohandler.c:143
revents = 1
pioh = 0x563f7610
ioh = 0x56450a40
#14 0x5596de1c in main_loop_wait (nonblocking=0) at 
main-loop.c:495

ret = 1
timeout = 4294967295
timeou

Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)

[Fabio Fantoni]

Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid 
leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, 
and qemu 2.2 from spice git (spice/next commit 
e779fa0a715530311e6f59fc8adb0f6eca914a89):

https://github.com/Fantu/Xen/commits/rebase/m2r-staging


I tried with qemu  tag v2.2.0-rc2 and crash still happen, here the full 
backtrace of latest test:

Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73  eax = env->regs[R_EAX];
(gdb) bt full
#0  0x55689b07 in vmport_ioport_read (opaque=0x564443a0, 
addr=0,

size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = "vmport_ioport_read"
env = 0x8250
command = 0 '\000'
eax = 0
#1  0x55655fc4 in memory_region_read_accessor (mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2  0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 , 
mr=0x5628)

at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3  0x556590e9 in memory_region_dispatch_read1 
(mr=0x5628,

addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4  0x556591b1 in memory_region_dispatch_read (mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type  to continue, or q  to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5  0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6  0x5560a1ca in address_space_rw (as=0x55eaf920, 
addr=22104,

buf=0x7fffda50 "\377\377\377\377", len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 "%s/%d:\n"
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7  0x5560a38f in address_space_read (as=0x55eaf920, 
addr=22104,

buf=0x7fffda50 "\377\377\377\377", len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
#8  0x5564fd4b in cpu_inl (addr=22104)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = "\377\377\377\377"
val = 21845
#9  0x55670c73 in do_inp (addr=22104, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
---Type  to continue, or q  to quit---
No locals.
#10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 1
#11 0x556714b3 in handle_ioreq (state=0x563c2510,
req=0x77ff3020) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853

No locals.
#12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
state = 0x563c2510
req = 0x77ff3020
#13 0x5596e240 in qemu_iohandler_poll (pollfds=0x56389a30, 
ret=1)

at iohandler.c:143
revents = 1
pioh = 0x563f7610
ioh = 0x56450a40
#14 0x5596de1c in main_loop_wait (nonblocking=0) at 
main-loop.c:495

ret = 1
timeout = 4294967295
timeout_ns = 3965432
#15 0x55756d3f in main_loop () at vl.c:1882
nonblocking = false
last_io = 0
#16 0x5575ea49 in main (argc=62, argv=0x7fffe048,
envp=0x7fffe240) at vl.c:4400
---Type  to continue, or q  to quit---
i = 128
snapshot = 0
linux_boot = 0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a48f86 ""
boot_order = 0x56387460 "dc"
ds = 0x564b2040
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x563873b0
machine_opts = 0x56389010
icount_opts = 0x0
olist = 0x55e57e80
optind = 62
optarg = 0x7fffe914 
"file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"

loadvm = 0x0
machine_class = 0x5637d5c0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
---Type  to continue, or q  to quit---
qtest_log = 0x0
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = true
   

[Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)

[Fabio Fantoni]

dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid leaf 
with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches, and 
qemu 2.2 from spice git (spice/next commit 
e779fa0a715530311e6f59fc8adb0f6eca914a89):

https://github.com/Fantu/Xen/commits/rebase/m2r-staging

Qemu crash on fedora 20 lxde (with software updates of some days ago) 
boot with this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x55689607 in vmport_ioport_read (opaque=0x56440a20, 
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73

73  eax = env->regs[R_EAX];
(gdb) bt full
#0  0x55689607 in vmport_ioport_read (opaque=0x56440a20, 
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73

s = 0x56440a20
cs = 0x0
cpu = 0x0
__func__ = "vmport_ioport_read"
env = 0x8250
command = 0 '\000'
eax = 0
#1  0x55655b9c in memory_region_read_accessor 
(mr=0x56440aa8, addr=0, value=0x7fffd8c0, size=4, shift=0, 
mask=4294967295)

at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2  0x55655e8f in access_with_adjusted_size (addr=0, 
value=0x7fffd8c0, size=4, access_size_min=4, access_size_max=4,
access=0x55655b3a , 
mr=0x56440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480

access_mask = 4294967295
access_size = 4
i = 0
#3  0x55658cc1 in memory_region_dispatch_read1 
(mr=0x56440aa8, addr=0, size=4) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077

data = 0
#4  0x55658d89 in memory_region_dispatch_read 
(mr=0x56440aa8, addr=0, pval=0x7fffd998, size=4) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099

No locals.
#5  0x5565c794 in io_mem_read (mr=0x56440aa8, addr=0, 
pval=0x7fffd998, size=4) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962

No locals.
#6  0x55609fae in address_space_rw (as=0x55eae840, 
addr=22104, buf=0x7fffda40 "\377\377\377\377", len=4, is_write=false)

at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
l = 4
ptr = 0x0
val = 7964229952888770560
addr1 = 0
mr = 0x56440aa8
error = false
#7  0x5560a173 in address_space_read (as=0x55eae840, 
addr=22104, buf=0x7fffda40 "\377\377\377\377", len=4) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207

No locals.
#8  0x5564fac7 in cpu_inl (addr=22104) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117

buf = "\377\377\377\377"
val = 21845
#9  0x5567084b in do_inp (addr=22104, size=4) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684

No locals.
#10 0x55670ab8 in cpu_ioreq_pio (req=0x77ff3000) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747

i = 0
#11 0x5567108b in handle_ioreq (state=0x563c1590, 
req=0x77ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853

---Type  to continue, or q  to quit---
No locals.
#12 0x556713fe in cpu_handle_ioreq (opaque=0x563c1590) at 
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931

state = 0x563c1590
req = 0x77ff3000
#13 0x5596d874 in qemu_iohandler_poll (pollfds=0x56388a30, 
ret=1) at iohandler.c:143

revents = 1
pioh = 0x563f3c90
ioh = 0x56515f80
#14 0x5596d450 in main_loop_wait (nonblocking=0) at 
main-loop.c:495

ret = 1
timeout = 4294967295
timeout_ns = 3418165
#15 0x557567b7 in main_loop () at vl.c:1882
nonblocking = false
last_io = 1
#16 0x5575e4c1 in main (argc=62, argv=0x7fffe038, 
envp=0x7fffe230) at vl.c:4400

i = 128
snapshot = 0
linux_boot = 0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a485c6 ""
boot_order = 0x563864e0 "dc"
ds = 0x564c71b0
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x56386430
machine_opts = 0x56388090
icount_opts = 0x0
olist = 0x55e56da0
optind = 62
optarg = 0x7fffe914 
"file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback"

loadvm = 0x0
machine_class = 0x5637c5c0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
---Type  to continue, or q  to quit---
qtest_log = 0x0
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = true
userconfig = true
log_mask = 0x0
log_file = 0x0
mem_trace = {malloc = 0x55759e7a , 
realloc = 0x55759ed2 , free = 0x55759f39 
, calloc = 0,

  try_malloc = 0, try_realloc = 0}
trace_events = 0x0
trace_file = 0x0
default_ram_size = 134217728
maxram_size

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 13/11/2014 11:14, Fabio Fantoni ha scritto:

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with

spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
except for one problem after xl save/restore, when after restore on
spice client connect  the domU's screen freezed for 2-3 minutes 
(and

seems also windows), after this time seems that all return to works
correctly.
This problem happen also if spice client connect long time after 
restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
to (32) frames.

(XEN) irq.c:380: Dom2 callback via changed to GSI 24

Tested on latest staging (commit 
7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 19/09/2014 15:18, Fabio Fantoni ha scritto:

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and 
client with

spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
except for one problem after xl save/restore, when after restore on
spice client connect  the domU's screen freezed for 2-3 minutes (and
seems also windows), after this time seems that all return to works
correctly.
This problem happen also if spice client connect long time after 
restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
 http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl 
save: spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
to (32) frames.

(XEN) irq.c:380: Dom2 callback via changed to GSI 24

Tested on latest staging (commit 
7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:

https://github.com/Fant

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 12/09/2014 16:46, Fabio Fantoni ha scritto:

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and client 
with

spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
except for one problem after xl save/restore, when after restore on
spice client connect  the domU's screen freezed for 2-3 minutes (and
seems also windows), after this time seems that all return to works
correctly.
This problem happen also if spice client connect long time after 
restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
 http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl save: 
spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) 
to (32) frames.

(XEN) irq.c:380: Dom2 callback via changed to GSI 24

Tested on latest staging (commit 
7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:

https://github.com/Fantu/Xen/commits/rebase/m2r-staging

If you need mor

Re: [Qemu-devel] [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

Il 08/07/2014 12:34, Fabio Fantoni ha scritto:

Il 08/07/2014 12:06, Fabio Fantoni ha scritto:

Il 08/07/2014 10:53, David Jaša ha scritto:

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and client 
with

spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm
except for one problem after xl save/restore, when after restore on
spice client connect  the domU's screen freezed for 2-3 minutes (and
seems also windows), after this time seems that all return to works
correctly.
This problem happen also if spice client connect long time after 
restore.
With stdvga not have this problem but stdvga has many missed 
resolutions

and bad refresh performance.

If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
   * virt-viewer with --spice-debug option
   * spice-server with SPICE_DEBUG_LEVEL environment variable set
 to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
 http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David


Thanks for your reply, in attachments:
- domU's xl cfg: W7.cfg
- xl -vvv create/save/restore: xen logs.txt
- remote-viewer with --spice-debug after domU's start until xl save: 
spicelog-1.txt (zipped)
- remote-viewer with --spice-debug after domU's xl restore: 
spicelog-2.txt


Sorry for my forgetfulness, here also qemu's log:
- after domU's start until xl save: qemu-dm-W7.log.1
- after domU's xl restore: qemu-dm-W7.log



If you need more tests/informations tell me and I'll post them.



Thanks for any reply and sorry for my bad english.

___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel




The problem persist, this time I saw these in xl dmesg after restore:

(XEN) HVM2 restore: CPU 0
(XEN) HVM2 restore: CPU 1
(XEN) HVM2 restore: PIC 0
(XEN) HVM2 restore: PIC 1
(XEN) HVM2 restore: IOAPIC 0
(XEN) HVM2 restore: LAPIC 0
(XEN) HVM2 restore: LAPIC 1
(XEN) HVM2 restore: LAPIC_REGS 0
(XEN) HVM2 restore: LAPIC_REGS 1
(XEN) HVM2 restore: PCI_IRQ 0
(XEN) HVM2 restore: ISA_IRQ 0
(XEN) HVM2 restore: PCI_LINK 0
(XEN) HVM2 restore: PIT 0
(XEN) HVM2 restore: RTC 0
(XEN) HVM2 restore: HPET 0
(XEN) HVM2 restore: PMTIMER 0
(XEN) HVM2 restore: MTRR 0
(XEN) HVM2 restore: MTRR 1
(XEN) HVM2 restore: VIRIDIAN_DOMAIN 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 0
(XEN) HVM2 restore: VIRIDIAN_VCPU 1
(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) memory.c:216:d2v0 Domain 2 page number 77579 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7757f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77580 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77581 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77582 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77583 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77584 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77585 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77586 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77587 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77588 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77589 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758a invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758b invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758c invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758d invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758e invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 7758f invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77590 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77591 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77592 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77593 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77594 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77595 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77596 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77597 invalid
(XEN) memory.c:216:d2v0 Domain 2 page number 77598 invalid
(XEN) grant_table.c:1272:d2v0 Expanding dom (2) grant table from (4) to 
(32) frames.

(XEN) irq.c:380: Dom2 callback via changed to GSI 24

Tested on latest staging (commit 
7d203b337fb2dcd148d2df850e25b67c792d4d0b) plus the spice patches:

https://github.com/Fantu/Xen/commits/rebase/m2r-staging

If you need more informations or tests tell me and I'll po

Re: [Qemu-devel] [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 12/05/2014 16:32, Ross Philipson ha scritto:

On 05/12/2014 05:05 AM, Ian Campbell wrote:

On Fri, 2014-05-09 at 13:32 -0400, Ross Philipson wrote:

On 05/09/2014 12:34 PM, Paul Durrant wrote:

-Original Message-
From: Ian Campbell
Sent: 09 May 2014 17:12
To: Konrad Rzeszutek Wilk
Cc: Ross Philipson; ke...@koconnor.net; Huangweidong (C); Hanweidong
(Randy); m...@redhat.com; qemu-devel@nongnu.org; xen-
de...@lists.xen.org; fabio.fant...@m2r.biz;
johannes.kra...@googlemail.com; Gonglei (Arei); Stefano Stabellini;
Gaowei (UVP); Jan Beulich; Anthony Perard; Paul Durrant
Subject: Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only 
supply

_EJ0 methods for PCIslots that support hotplug by runtime patching


Ping...
Are there any news about this patch?

Thanks for any reply.



On Fri, 2014-05-09 at 12:00 -0400, Konrad Rzeszutek Wilk wrote:

So we could just then gat the _EJ0 functionality based on values 
that

are present (or not) in the SSDT ?


AIUI the very presence of _EJ0 is what marks the device as being
ejectable (e.g. in the Windows device manager).

It would be possible to make _EJ0 conditionally turn itself into a 
NOP

without resorting to an SSDT, but I don't think that solves the issue
they are trying to solve, which is that the user can even try to 
eject

an non-hotplug device. (grep for UAR1 in our dsdt.asl and
acpi_info->com1_present in hvmloader/acpi/build.c for an example 
of this

sort of conditional thing)



Going back to the SSDT idea. A little poking around and what not and I
came up with something like this that I build into an SSDT:

DefinitionBlock ("SSDTX.aml", "SSDT", 2, "Xen", "HVM", 0)
{
  /* S00 device is defined in DSDT, this allows me to
   * refrence it in this SSDT
   */
  External (\_SB.PCI0.S00, DeviceObj)

  ...

  /* Extend the functionality of S00 */
  Scope ( \_SB.PCI0.S00 ) {
  Method(_EJ0, 1, NotSerialized)
  {
  /* Do stuffs here */
  }
  }
}


Thanks, this looks like the sort of thing I was naively imagining would
be possible.


So I did find some examples of this after all in my pile of ACPI
firmware snapshots from all our supported platforms.


Thanks (none of the machines I looked at had PCI hotplug apparently). I
was curious to know how Real Firmware Engineers(tm) dealt with this sort
of issue.

I was worried how real life OSPMs might interpret this method being in
an SSDT instead of the DSDT. In theory it shouldn't matter, and the fact
that real firmware does this seem to suggest that at least Windows
treats it that way (which is a relief).


I did actually find SSDTs that were specifically adding an _EJ0 to a 
device scope for a device defined externally. I attached an example 
from a Fujitsu system I have. The PRT1 device on SAT0 is external:


External (\_SB_.PCI0.SAT0.PRT1, DeviceObj)

And _EJ0 is added to the scope.




  I think this would
work allowing you to just add or not add _EJ0 methods to the PCI 
devices

you want by either using different SSDTs or doing something to generate
or munge the SSDT at runtime (which would be simpler than messing with
the DSDT I think.


Without filling out the body of _EJ0 (which I tried but failed to do)
your stub compiles to 60 bytes of AML, I suppose that even having filled
in _EJ0 in the result would be less than, say, 128 bytes.

Given that there are 32 PCI slots we would be talking about a total of
4k of space in hvmloader to provide a precompiled SSDT for each slot,
which can be inserted at runtime depending on each slots configuration.

I wouldn't be especially surprised if the code to generate a suitable
SSDT dynamically was a reasonable proportion of that size, so unless
there is the possibility of needing other variants it seems like just
generating each of them would be the say to go.


  I did not try it (actually I did but ran into other
problems on our platform :).


;-)

Ian.

[Qemu-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[Fabio Fantoni]

On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and client with 
spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm 
except for one problem after xl save/restore, when after restore on 
spice client connect  the domU's screen freezed for 2-3 minutes (and 
seems also windows), after this time seems that all return to works 
correctly.

This problem happen also if spice client connect long time after restore.
With stdvga not have this problem but stdvga has many missed resolutions 
and bad refresh performance.


If you need more tests/informations tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [PATCH v2] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

2014-06-12 16:33 GMT+02:00 Stefano Stabellini <
stefano.stabell...@eu.citrix.com>:

> Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we know for
> sure what is the machine that we are emulating.
>
> Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
> xen-platform device if requested.  Move the machine options earlier,
> before any emulated devices options so that QEMU will assign slot 2 to
> the xen-platform device, maintaining compatibility with current
> installations.
>
> In case of Intel graphic passthrough, slot 2 might be needed by the
> grafics card. However it is easy to change the position of the
> xen-platform device on the PCI bus if graphic passthrough is enabled, by
> passing "addr=desired_slot_number".
>
> Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
> differently from xenfv, the other QEMU machines do not have that option
> off by default.
>
> This patch does not change the emulated environment in the guest, unless
> soundhw='hda' is specified, in that case the xen-platform device is
> moved to slot 3 (used to be always slot 2). This change might cause
> problems to guests with soundhw='hda', migrating from 4.4 to 4.5.
>

Without fixed xen-platform slot I think will be ok also in migrate.
For test the case it is sufficient save on unstable without the patch and
restore with this patch? If yes I'll thest this on my next build test.


>
> Signed-off-by: Stefano Stabellini 
>
>
> ---
>
> Changes in v2:
> - note the dependency on QEMU >= 1.6.1 in the README;
> - move the -machine options even earlier and drop the explicit
>   ",slot=0x2".
>
>
> diff --git a/README b/README
> index 9bbe734..cb66893 100644
> --- a/README
> +++ b/README
> @@ -73,6 +73,10 @@ disabled at compile time:
>  * markdown
>  * figlet (for generating the traditional Xen start of day banner)
>
> +As a runtime requirement, you need a QEMU binary newer than v1.6.1,
>

Probably my english is very bad but this seems to me >1.6.1 but should be
>=1.6.1 (for example: at least version 1.6.1 of QEMU binary)


> +compiled with Xen support. By default the Xen build system will clone
> +and build one for you.
>


> +
>  Second, you need to acquire a suitable kernel for use in domain 0. If
>  possible you should use a kernel provided by your OS distributor. If
>  no suitable kernel is available from your OS distributor then refer to
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51ab2bf..b5a0beb 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -403,6 +403,27 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
>"-xen-domid",
>libxl__sprintf(gc, "%d", guest_domid), NULL);
>
> +switch (b_info->type) {
> +case LIBXL_DOMAIN_TYPE_PV:
> +flexarray_append_pair(dm_args, "-machine", "xenpv");
> +for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
> +flexarray_append(dm_args, b_info->extra_pv[i]);
> +break;
> +case LIBXL_DOMAIN_TYPE_HVM:
> +flexarray_append_pair(dm_args, "-machine",
> "pc-i440fx-1.6,accel=xen");
> +flexarray_append_pair(dm_args, "-global",
> +"PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
> +if (libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> +flexarray_append(dm_args, "-device");
> +flexarray_append(dm_args, "xen-platform");
> +}
> +for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL;
> i++)
> +flexarray_append(dm_args, b_info->extra_hvm[i]);
> +break;
> +default:
> +abort();
> +}
> +
>  flexarray_append(dm_args, "-chardev");
>  flexarray_append(dm_args,
>   libxl__sprintf(gc, "socket,id=libxl-cmd,"
> @@ -646,29 +667,6 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
>  for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
>  flexarray_append(dm_args, b_info->extra[i]);
>
> -flexarray_append(dm_args, "-machine");
> -switch (b_info->type) {
> -case LIBXL_DOMAIN_TYPE_PV:
> -flexarray_append(dm_args, "xenpv");
> -for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
> -flexarray_append(dm_args, b_info->extra_pv[i]);
> -break;
> -case LIBXL_DOMAIN_TYPE_HVM:
> -if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> -/* Switching here to the machine "pc" which does not add
> - * the xen-platform device instead of the default "xenfv"
> machine.
> - */
> -flexarray_append(dm_args, "pc,accel=xen");
> -} else {
> -flexarray_append(dm_args, "xenfv");
> -}
> -for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL;
> i++)
> -flexarray_append(dm_args, b_info->extra_hvm[i]);
> -break;
> -default:
> -abort();
> -  

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

2014-06-11 12:44 GMT+02:00 Ian Campbell :

> On Wed, 2014-06-11 at 11:35 +0100, Stefano Stabellini wrote:
> > On Tue, 10 Jun 2014, Ian Campbell wrote:
> > > On Fri, 2014-05-23 at 17:07 +0100, Stefano Stabellini wrote:
> > I think that the dependency on QEMU >= 1.6 is OK. The Xen PV Device went
> > in v1.6.0 and we certainy cannot go back to versions older than v1.5 due
> > to missing mapcache fixes. Fabio reported multiple times that QEMU 1.6
> > is the first stable version he tested.
>
> OK, then please can we update the README (and any other relevant docs)
> as part of this change.
>

I tested upstream qemu from 1.2 and based on my test at least qemu 1.6.1 is
needed to be fairly complete and stable on xen (no major or critical bugs), I
started using it in production for a few month, in the next few days I will
start to put also qemu 2.0 on a production system.
I want to be remembered to specify >=1.6.1 because 1.6.0 have critical bug
that that prevents all hvm domUs start.


>
> > > > Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
> > > > xen-platform device if requested. Choose slot 2 for the xen-platform
> > > > device for compatibility with current installations. In case of Intel
> > > > graphic passthrough, slot 2 might be needed by the grafic card.
> However
> > >
> > > "graphics"
> > >
> > > > now that we can specify the slot explicitly, it is easy to change the
> > > > position of the xen-platform device on the PCI bus if graphic
> > > > passthrough is enabled.
> > > >
> > > > Move the machine options earlier, before any other emulated devices
> > > > options. Otherwise the selected PCI slot for the xen-platform device
> is
> > > > not available in QEMU.
> > > >
> > > > Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
> > > > differently from xenfv, the other QEMU machines do not have that
> option
> > > > off by default.
> > > >
> > > > This patch does not change the emulated environment in the guest.
> > > >
> > > > Refer to this thread:
> http://marc.info/?l=xen-devel&m=140023775929625&w=2
> > >
> > > This takes me to "[Xen-devel] [v2][PATCH 4/8] xen, gfx passthrough:
> > > reserve 00:02.0 for INTEL IGD" which I can't see the link to (including
> > > via the 2 replies). Wrong link perhaps?
> > >
> > > A Message-Id is generally a better identifier since I can feed it to
> the
> > > archive of my choice and they aren't subject to e.g. future
> accidentally
> > > renumberings etc.
> >
> > 1400237624-8505-5-git-send-email-tiejun.c...@intel.com
>
> (pedantic: the <>s are formally part of the message ID...)
>
> OK, so I'm still not sure why this message is relevant to the sentence
> which precedes the link.
>
>
> > > > Signed-off-by: Stefano Stabellini 
> > > >
> > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > index 8abed7b..fef684f 100644
> > > > --- a/tools/libxl/libxl_dm.c
> > > > +++ b/tools/libxl/libxl_dm.c
> > > > @@ -476,6 +476,29 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
> > > >  flexarray_vappend(dm_args, "-k", keymap, NULL);
> > > >  }
> > > >
> > > > +flexarray_append(dm_args, "-machine");
> > > > +switch (b_info->type) {
> > > > +case LIBXL_DOMAIN_TYPE_PV:
> > > > +flexarray_append(dm_args, "xenpv");
> > > > +for (i = 0; b_info->extra_pv && b_info->extra_pv[i] !=
> NULL; i++)
> > > > +flexarray_append(dm_args, b_info->extra_pv[i]);
> > > > +break;
> > > > +case LIBXL_DOMAIN_TYPE_HVM:
> > > > +flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");
> > > > +flexarray_append(dm_args, "-global");
> > > > +flexarray_append(dm_args,
> "PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
> > >
> > > FWIW you can use flexarray_append_pair which more naturally gathers an
> > > option and its argument together (improving readability).
> > >
> > > (personally I think the -machine should be pulled into both cases using
> > > this method, but that's not a prereq for accepting the patch IMHO)
> > >
> > > Other than that the patch itself seems sound (although I dislike code
> > > motion mixed with real changes, I suppose this one is small enough that
> > > I can cope).
> >
> > Should I go ahead with these minor changes
>
> Please.
>
> >  and leave the soundhw problem
> > unsolved? I am not keen on fixing that.
> >
> > 1401803223.1582.5.ca...@kazak.uk.xensource.com
>
> I came into this at the point where we were discussing how to support
> using -device for soundhw, but I missed the bit where it was explained
> why it was necessary to switch to that scheme.
>
> If this change leads to regressions where existing cfg files no longer
> work then we need to decide if that would be blocker for 4.5. I can't
> see why it wouldn't be, but it's up to you and Konrad to agree I
> suppose.
>

I think add new option with audio device select and check similar to vga
would be good but I'm afraid I do not have time to do it recently.
May st

Re: [Qemu-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

Il 03/06/2014 15:38, Stefano Stabellini ha scritto:

On Wed, 28 May 2014, Paolo Bonzini wrote:

Il 28/05/2014 18:41, Stefano Stabellini ha scritto:

However it would still place xen-platform at slot 3 instead of slot 2 if
soundhw is specified. It seems to me that there is not a perfect
solution to this problem.  We can either:

- Switch to -machine pc-i440fx-1.6 by default and use consistently the
same -machine option no matter the value of xen_platform_pci. Nice, but
we break compatibility with existing guests if soundhw is specified.

- Switch to -machine pc-i440fx-1.6 only when xen_platform_pci=0 is
specified and keep xenfv if xen_platform_pci=1. We still break
compatibility when soundhw is specified together with xen_platform_pci=0.

- change the implementation of the soundhw option to use -device instead.

Thanks, this sounds like the best option by far.

I noticed that "-soundhw hda" becomes "-device intel-hda".

Given that the VM config file exports a soundhw paramter, we would need
a programmatic way to get the -device command line option from the
soundhw paramter. Is there a way to do that?
Not only -device intel-hda, if I remember good there is also -device 
hda-duplex
soundhw now in libxl is only a string passed to qemu without check, 
probably is good add another parameter with a selectable options 
supported, similar to vga, for example audio=ac97|intelhda and libxl 
will check if exist and give to qemu the correct -device parameters.
The only problem is that audio device as many and not all qemu build 
support all (howevercurrently libxl does not care and isthe user having 
to make sure of the features support in qemu and view the log if qemu 
fails).

In addition there are also the disks to convert in -device.
I tried last year but with -device the automatic selection of bus and 
slot (unit now used in xen is not supported in -device if I remember 
good) was not working properly and the manual I did not know if I could 
do it working with cd/disk hot-plug working.


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

Il 28/05/2014 18:53, Fabio Fantoni ha scritto:
2014-05-28 18:41 GMT+02:00 Stefano Stabellini 
<mailto:stefano.stabell...@eu.citrix.com>>:


On Wed, 28 May 2014, Stefano Stabellini wrote:
> On Wed, 28 May 2014, Fabio Fantoni wrote:
> > Il 26/05/2014 10:00, Fabio Fantoni ha scritto:
> > > Il 25/05/2014 16:14, Stefano Stabellini ha scritto:
> > > > On Fri, 23 May 2014, Fabio Fantoni wrote:
> > > > > Il 23/05/2014 18:07, Stefano Stabellini ha scritto:
> > > > > > Choose pc-i440fx-1.6 instead of pc for HVM guests, so
that we know for
> > > > > > sure what is the machine that we are emulating.
> > > > > >
> > > > > > Use pc-i440fx-1.6 regardless of the xen_platform_pci
option. Add the
> > > > > > xen-platform device if requested. Choose slot 2 for
the xen-platform
> > > > > > device for compatibility with current installations.
In case of Intel
> > > > > > graphic passthrough, slot 2 might be needed by the
grafic card.
> > > > > > However
> > > > > > now that we can specify the slot explicitly, it is
easy to change the
> > > > > > position of the xen-platform device on the PCI bus if
graphic
> > > > > > passthrough is enabled.
> > > > > >
> > > > > > Move the machine options earlier, before any other
emulated devices
> > > > > > options. Otherwise the selected PCI slot for the
xen-platform device
> > > > > > is
> > > > > > not available in QEMU.
> > > > > >
> > > > > > Specify
PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
> > > > > > differently from xenfv, the other QEMU machines do not
have that
> > > > > > option
> > > > > > off by default.
> > > > > >
> > > > > > This patch does not change the emulated environment in
the guest.
> > > > > >
> > > > > > Refer to this thread:
> > > > > > http://marc.info/?l=xen-devel&m=140023775929625&w=2
> > > > > >
> > > > > > Signed-off-by: Stefano Stabellini
mailto:stefano.stabell...@eu.citrix.com>>
> > > > > >
> > > > > > diff --git a/tools/libxl/libxl_dm.c
b/tools/libxl/libxl_dm.c
> > > > > > index 8abed7b..fef684f 100644
> > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > @@ -476,6 +476,29 @@ static char **
> > > > > > libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > >  flexarray_vappend(dm_args, "-k", keymap, NULL);
> > > > > >}
> > > > > >+  flexarray_append(dm_args, "-machine");
> > > > > > +switch (b_info->type) {
> > > > > > +case LIBXL_DOMAIN_TYPE_PV:
> > > > > > +  flexarray_append(dm_args, "xenpv");
> > > > > > +for (i = 0; b_info->extra_pv &&
b_info->extra_pv[i] != NULL;
> > > > > > i++)
> > > > > > +  flexarray_append(dm_args, b_info->extra_pv[i]);
> > > > > > +break;
> > > > > > +case LIBXL_DOMAIN_TYPE_HVM:
> > > > > > +  flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");
> > >
> > > I think that a note in README should be added: qemu >=1.6.1
is required for
> > > hvm domUs.
> > >
> > > About the other xl parameter to be added I think that should be:
> > > qemu_machine_type="i440fx"|"q35" (when also q35 will be
supported on xen)
> > > qemu_machine_version="x.y" to specify the machine version,
useful for
> > > debug/testing and other some cases.
> > >
> > > > > > +  flexarray_append(dm_args, "-global");
> > > > > > +  flexarray_append(dm_args,
> > > > > > "PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
> > > > > I think is good add a comment for remember to remove
this workaround
> > > > > when pc
> > > > > > =2.1 will

Re: [Qemu-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

2014-05-28 18:50 GMT+02:00 Paolo Bonzini :

> Il 28/05/2014 18:41, Stefano Stabellini ha scritto:
>
>  However it would still place xen-platform at slot 3 instead of slot 2 if
>> soundhw is specified. It seems to me that there is not a perfect
>> solution to this problem.  We can either:
>>
>> - Switch to -machine pc-i440fx-1.6 by default and use consistently the
>> same -machine option no matter the value of xen_platform_pci. Nice, but
>> we break compatibility with existing guests if soundhw is specified.
>>
>> - Switch to -machine pc-i440fx-1.6 only when xen_platform_pci=0 is
>> specified and keep xenfv if xen_platform_pci=1. We still break
>> compatibility when soundhw is specified together with xen_platform_pci=0.
>>
>
> - change the implementation of the soundhw option to use -device instead.
>
> Paolo
>

I already did the new features with -device and switched vga to -device but
when I tried to convert the disks to -device (also required for
compatibility q35) had a problem that I was not able to solve (and also
reported to qemu-devel time ago), and then I had postponed the complete
conversion to -device.

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

2014-05-28 18:41 GMT+02:00 Stefano Stabellini <
stefano.stabell...@eu.citrix.com>:

> On Wed, 28 May 2014, Stefano Stabellini wrote:
> > On Wed, 28 May 2014, Fabio Fantoni wrote:
> > > Il 26/05/2014 10:00, Fabio Fantoni ha scritto:
> > > > Il 25/05/2014 16:14, Stefano Stabellini ha scritto:
> > > > > On Fri, 23 May 2014, Fabio Fantoni wrote:
> > > > > > Il 23/05/2014 18:07, Stefano Stabellini ha scritto:
> > > > > > > Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we
> know for
> > > > > > > sure what is the machine that we are emulating.
> > > > > > >
> > > > > > > Use pc-i440fx-1.6 regardless of the xen_platform_pci option.
> Add the
> > > > > > > xen-platform device if requested. Choose slot 2 for the
> xen-platform
> > > > > > > device for compatibility with current installations. In case
> of Intel
> > > > > > > graphic passthrough, slot 2 might be needed by the grafic card.
> > > > > > > However
> > > > > > > now that we can specify the slot explicitly, it is easy to
> change the
> > > > > > > position of the xen-platform device on the PCI bus if graphic
> > > > > > > passthrough is enabled.
> > > > > > >
> > > > > > > Move the machine options earlier, before any other emulated
> devices
> > > > > > > options. Otherwise the selected PCI slot for the xen-platform
> device
> > > > > > > is
> > > > > > > not available in QEMU.
> > > > > > >
> > > > > > > Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off,
> because
> > > > > > > differently from xenfv, the other QEMU machines do not have
> that
> > > > > > > option
> > > > > > > off by default.
> > > > > > >
> > > > > > > This patch does not change the emulated environment in the
> guest.
> > > > > > >
> > > > > > > Refer to this thread:
> > > > > > > http://marc.info/?l=xen-devel&m=140023775929625&w=2
> > > > > > >
> > > > > > > Signed-off-by: Stefano Stabellini <
> stefano.stabell...@eu.citrix.com>
> > > > > > >
> > > > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > > > > index 8abed7b..fef684f 100644
> > > > > > > --- a/tools/libxl/libxl_dm.c
> > > > > > > +++ b/tools/libxl/libxl_dm.c
> > > > > > > @@ -476,6 +476,29 @@ static char **
> > > > > > > libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > > >flexarray_vappend(dm_args, "-k", keymap, NULL);
> > > > > > >}
> > > > > > >+flexarray_append(dm_args, "-machine");
> > > > > > > +switch (b_info->type) {
> > > > > > > +case LIBXL_DOMAIN_TYPE_PV:
> > > > > > > +flexarray_append(dm_args, "xenpv");
> > > > > > > +for (i = 0; b_info->extra_pv && b_info->extra_pv[i]
> != NULL;
> > > > > > > i++)
> > > > > > > +flexarray_append(dm_args, b_info->extra_pv[i]);
> > > > > > > +break;
> > > > > > > +case LIBXL_DOMAIN_TYPE_HVM:
> > > > > > > +flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");
> > > >
> > > > I think that a note in README should be added: qemu >=1.6.1 is
> required for
> > > > hvm domUs.
> > > >
> > > > About the other xl parameter to be added I think that should be:
> > > > qemu_machine_type="i440fx"|"q35" (when also q35 will be supported on
> xen)
> > > > qemu_machine_version="x.y" to specify the machine version, useful for
> > > > debug/testing and other some cases.
> > > >
> > > > > > > +flexarray_append(dm_args, "-global");
> > > > > > > +flexarray_append(dm_args,
> > > > > > > "PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
> > > > > > I think is good add a comment for remember to remove this
> workaround
> > > > > > wh

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

Il 26/05/2014 10:00, Fabio Fantoni ha scritto:

Il 25/05/2014 16:14, Stefano Stabellini ha scritto:

On Fri, 23 May 2014, Fabio Fantoni wrote:

Il 23/05/2014 18:07, Stefano Stabellini ha scritto:

Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we know for
sure what is the machine that we are emulating.

Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
xen-platform device if requested. Choose slot 2 for the xen-platform
device for compatibility with current installations. In case of Intel
graphic passthrough, slot 2 might be needed by the grafic card. 
However

now that we can specify the slot explicitly, it is easy to change the
position of the xen-platform device on the PCI bus if graphic
passthrough is enabled.

Move the machine options earlier, before any other emulated devices
options. Otherwise the selected PCI slot for the xen-platform 
device is

not available in QEMU.

Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
differently from xenfv, the other QEMU machines do not have that 
option

off by default.

This patch does not change the emulated environment in the guest.

Refer to this thread: 
http://marc.info/?l=xen-devel&m=140023775929625&w=2


Signed-off-by: Stefano Stabellini 

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8abed7b..fef684f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -476,6 +476,29 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
   flexarray_vappend(dm_args, "-k", keymap, NULL);
   }
   +flexarray_append(dm_args, "-machine");
+switch (b_info->type) {
+case LIBXL_DOMAIN_TYPE_PV:
+flexarray_append(dm_args, "xenpv");
+for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != 
NULL; i++)

+flexarray_append(dm_args, b_info->extra_pv[i]);
+break;
+case LIBXL_DOMAIN_TYPE_HVM:
+flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");


I think that a note in README should be added: qemu >=1.6.1 is 
required for hvm domUs.


About the other xl parameter to be added I think that should be:
qemu_machine_type="i440fx"|"q35" (when also q35 will be supported on xen)
qemu_machine_version="x.y" to specify the machine version, useful for 
debug/testing and other some cases.



+flexarray_append(dm_args, "-global");
+flexarray_append(dm_args,
"PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
I think is good add a comment for remember to remove this workaround 
when pc

=2.1 will be the default since qemu 2.1 will fix it.

https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg04789.html

The workaround is not actually harmful, it doesn't need to be removed
when pc >= 2.1 in QEMU.



+if (libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+flexarray_append(dm_args, "-device");
+flexarray_append(dm_args, "xen-platform,addr=0x2");
The fixed pci address to 0x2 probably is a problem with intel gpu 
passthrough:

http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03726.html

Right, however we cannot really change the default position of the
xen-platform device on the PCI bus, otherwise we'll end up changing the
emulated environment for all the VMs out there.

I'll leave it to Tiejun to move xen-platform to another slot when
graphic passthrough is enabled.




I found another case of problem with xen-platform's fixed pci slot.
I tested this patch and I saw that qemu not start also in other cases, 
for example the domU of my test:
qemu-system-i386: -device xen-platform,addr=0x2: PCI: slot 2 function 
0 not available for xen-platform, in use by intel-hda
qemu-system-i386: -device xen-platform,addr=0x2: Device initialization 
failed.
qemu-system-i386: -device xen-platform,addr=0x2: Device 'xen-platform' 
could not be initialized


The domU's xl cfg:

name='W7'
builder="hvm"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/bin/qemu-system-x86_64"
#bios="ovmf"
memory=2048
vcpus=2
#nestedhvm=1
#vif=['model=e1000,bridge=xenbr0']
vif=['bridge=xenbr0,mac=00:16:3e:42:ae:8f']
disk=['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
viridian=1
vnc=0
keymap="it"
on_crash="destroy"
vga="qxl"
#videoram=64
spice=1
spicehost='0.0.0.0'
spiceport=6002
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=0
spice_image_compression="off"
spice_streaming_video="filter"
spiceusbredirection=4
soundhw="hda"
localtime=1
usbversion=2


Probably there are also other cases that can create a problem with 
xen-platform fixed address, FWIK now new usb controller (with 
usbversion) is the only other with fixed pci address in libxl, all other 
emulated qemu components not.
And call it before in qemu binary starts notaffect the pci slot order 
because the xen-platform is already before audio.


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

Il 25/05/2014 16:14, Stefano Stabellini ha scritto:

On Fri, 23 May 2014, Fabio Fantoni wrote:

Il 23/05/2014 18:07, Stefano Stabellini ha scritto:

Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we know for
sure what is the machine that we are emulating.

Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
xen-platform device if requested. Choose slot 2 for the xen-platform
device for compatibility with current installations. In case of Intel
graphic passthrough, slot 2 might be needed by the grafic card. However
now that we can specify the slot explicitly, it is easy to change the
position of the xen-platform device on the PCI bus if graphic
passthrough is enabled.

Move the machine options earlier, before any other emulated devices
options. Otherwise the selected PCI slot for the xen-platform device is
not available in QEMU.

Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
differently from xenfv, the other QEMU machines do not have that option
off by default.

This patch does not change the emulated environment in the guest.

Refer to this thread: http://marc.info/?l=xen-devel&m=140023775929625&w=2

Signed-off-by: Stefano Stabellini 

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8abed7b..fef684f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -476,6 +476,29 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
   flexarray_vappend(dm_args, "-k", keymap, NULL);
   }
   +flexarray_append(dm_args, "-machine");
+switch (b_info->type) {
+case LIBXL_DOMAIN_TYPE_PV:
+flexarray_append(dm_args, "xenpv");
+for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+flexarray_append(dm_args, b_info->extra_pv[i]);
+break;
+case LIBXL_DOMAIN_TYPE_HVM:
+flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");


I think that a note in README should be added: qemu >=1.6.1 is required 
for hvm domUs.


About the other xl parameter to be added I think that should be:
qemu_machine_type="i440fx"|"q35" (when also q35 will be supported on xen)
qemu_machine_version="x.y" to specify the machine version, useful for 
debug/testing and other some cases.



+flexarray_append(dm_args, "-global");
+flexarray_append(dm_args,
"PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");

I think is good add a comment for remember to remove this workaround when pc

=2.1 will be the default since qemu 2.1 will fix it.

https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg04789.html

The workaround is not actually harmful, it doesn't need to be removed
when pc >= 2.1 in QEMU.



+if (libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+flexarray_append(dm_args, "-device");
+flexarray_append(dm_args, "xen-platform,addr=0x2");

The fixed pci address to 0x2 probably is a problem with intel gpu passthrough:
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03726.html

Right, however we cannot really change the default position of the
xen-platform device on the PCI bus, otherwise we'll end up changing the
emulated environment for all the VMs out there.

I'll leave it to Tiejun to move xen-platform to another slot when
graphic passthrough is enabled.

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Fabio Fantoni]

Il 23/05/2014 18:07, Stefano Stabellini ha scritto:

Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we know for
sure what is the machine that we are emulating.

Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
xen-platform device if requested. Choose slot 2 for the xen-platform
device for compatibility with current installations. In case of Intel
graphic passthrough, slot 2 might be needed by the grafic card. However
now that we can specify the slot explicitly, it is easy to change the
position of the xen-platform device on the PCI bus if graphic
passthrough is enabled.

Move the machine options earlier, before any other emulated devices
options. Otherwise the selected PCI slot for the xen-platform device is
not available in QEMU.

Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
differently from xenfv, the other QEMU machines do not have that option
off by default.

This patch does not change the emulated environment in the guest.

Refer to this thread: http://marc.info/?l=xen-devel&m=140023775929625&w=2

Signed-off-by: Stefano Stabellini 

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8abed7b..fef684f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -476,6 +476,29 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
  flexarray_vappend(dm_args, "-k", keymap, NULL);
  }
  
+flexarray_append(dm_args, "-machine");

+switch (b_info->type) {
+case LIBXL_DOMAIN_TYPE_PV:
+flexarray_append(dm_args, "xenpv");
+for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+flexarray_append(dm_args, b_info->extra_pv[i]);
+break;
+case LIBXL_DOMAIN_TYPE_HVM:
+flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");
+flexarray_append(dm_args, "-global");
+flexarray_append(dm_args, 
"PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");


I think is good add a comment for remember to remove this workaround 
when pc >=2.1 will be the default since qemu 2.1 will fix it.

https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg04789.html


+if (libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+flexarray_append(dm_args, "-device");
+flexarray_append(dm_args, "xen-platform,addr=0x2");


The fixed pci address to 0x2 probably is a problem with intel gpu 
passthrough:

http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03726.html


+}
+for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+flexarray_append(dm_args, b_info->extra_hvm[i]);
+break;
+default:
+abort();
+}
+
+
  if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
  int ioemu_nics = 0;
  
@@ -645,29 +668,6 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,

  for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
  flexarray_append(dm_args, b_info->extra[i]);
  
-flexarray_append(dm_args, "-machine");

-switch (b_info->type) {
-case LIBXL_DOMAIN_TYPE_PV:
-flexarray_append(dm_args, "xenpv");
-for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
-flexarray_append(dm_args, b_info->extra_pv[i]);
-break;
-case LIBXL_DOMAIN_TYPE_HVM:
-if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
-/* Switching here to the machine "pc" which does not add
- * the xen-platform device instead of the default "xenfv" machine.
- */
-flexarray_append(dm_args, "pc,accel=xen");
-} else {
-flexarray_append(dm_args, "xenfv");
-}
-for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
-flexarray_append(dm_args, b_info->extra_hvm[i]);
-break;
-default:
-abort();
-}
-
  ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
  flexarray_append(dm_args, "-m");
  flexarray_append(dm_args, libxl__sprintf(gc, "%"PRId64, ram_size));

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

Re: [Qemu-devel] [PATCH] xen: make xen-platform a default device

[Fabio Fantoni]

Il 23/05/2014 16:30, Stefano Stabellini ha scritto:

On Fri, 23 May 2014, Fabio Fantoni wrote:

One issue is that -M pc didn't always work with Xen. Now it does and we
are already relying on it in libxl since
2bc047635b51abd41c917aa2b813211ee0de2c38. It is safe because all QEMU
releases from 1.6 onward work well with Xen and -M pc. Older QEMU
releases are considered ancient and unmaintained. This is what I was
referring to in my last reply. I really meant "we should move away from
xenfv and use a pc.* machine that does not create xen-platform by
default".

As you say the other issue is the version of the pc machine, especially
in relation to save/restore. However since:

commit 2bc047635b51abd41c917aa2b813211ee0de2c38
Author: Anthony PERARD 
Date:   Wed Nov 27 18:21:34 2013 +

  libxl: Handle xen_platform_pci=0 case with qemu-xen.

we are simply calling QEMU with -M pc if xen_platform_pci=0. I think we
should change that too and backport the patch to 4.4. pc-i440fx-1.6
seems like a good choice to me.

Use "-M pc" as default seems a good idea.
Use specific version maybe too.
This way the base hardware should stay the same even if updating qemu, is
right?

Yep



If yes, this should also solve possible problem like windows
reactivation request for different hardware, right?

Right



How about create also xl parameter to select the "pc" model?

Having a VM config parameter for it is OK. In the past I argued against
relying on such a parameter to solve all compatibility issues with QEMU
because I would like libxl to be able to select the right QEMU machine
automatically, without user intervention.  But the option could still be
useful for debugging.



Excellent

Re: [Qemu-devel] [PATCH] xen: make xen-platform a default device

[Fabio Fantoni]

One issue is that -M pc didn't always work with Xen. Now it does and we
are already relying on it in libxl since
2bc047635b51abd41c917aa2b813211ee0de2c38. It is safe because all QEMU
releases from 1.6 onward work well with Xen and -M pc. Older QEMU
releases are considered ancient and unmaintained. This is what I was
referring to in my last reply. I really meant "we should move away from
xenfv and use a pc.* machine that does not create xen-platform by
default".

As you say the other issue is the version of the pc machine, especially
in relation to save/restore. However since:

commit 2bc047635b51abd41c917aa2b813211ee0de2c38
Author: Anthony PERARD 
Date:   Wed Nov 27 18:21:34 2013 +

 libxl: Handle xen_platform_pci=0 case with qemu-xen.

we are simply calling QEMU with -M pc if xen_platform_pci=0. I think we
should change that too and backport the patch to 4.4. pc-i440fx-1.6
seems like a good choice to me.


Use "-M pc" as default seems a good idea.
Use specific version maybe too.
This way the base hardware should stay the same even if updating qemu, 
is right? If yes, this should also solve possible problem like windows 
reactivation request for different hardware, right?

How about create also xl parameter to select the "pc" model?

Thanks for any reply and sorry for my bad english.

[Qemu-devel] usb3 regression with qemu 2.0

[Fabio Fantoni]

Il 22/05/2014 13:50, Fabio Fantoni ha scritto:

Il 22/05/2014 13:04, George Dunlap ha scritto:

On 05/22/2014 11:44 AM, Fabio Fantoni wrote:

Il 22/05/2014 12:38, George Dunlap ha scritto:

On 05/20/2014 04:20 PM, Fabio Fantoni wrote:

Il 20/05/2014 17:03, George Dunlap ha scritto:

Fabio,

If I recall correctly, at some point you had ported my USB 
hotplug series posted back in 2013 and had it as a patch against 
the version of Xen you were personally using.  Did that series, 
as it was, work with the usbversion functionality that you 
added?  That is, if you set usbversion=3, did the qmp-add 
functionality in that patch series automatically put the device 
on the right hub?  Or did it do something mad like add another 
usb 1.0 hub?


 -George


Yes last year I updated (refresh and one small fix) and tested 
your patch.
Was working with my usbversion and usbredirection patches and 
passthrough with your new function use new controller of 
usbversion parameters (code changes to "auto-add" usbversion must 
be added, I manually added it in xl on my tests if I remember good 
and auto-add it only with spice usbredir now).


I'm sorry, I'm having a bit of trouble understanding what you mean. 
If you set "usbversion=3", were you actually able to successfully 
hot-plug a device with "xl usb-attach"?


 -George


I seem to have it tested it also with usb3 but can not remember for 
sure, I remember with certainty to have it tested with usb2.
I have to redo the test all cases with xen 4.5 (unstable updated) 
when I'll have time and let you know?


Actually, the reason I was asking is that I've been testing it myself 
and have been unable to get it to work.  So I was wondering if you 
had done something specific to get it to work, over and above just 
porting the patches.


I've just been playing around with it, and it turns out the 
usb-attach commands *do* work with usbversion=2, but I haven't been 
able to get them to work with usbversion=3.  The same is actually 
true for qmp -- even connecting directly to qmp and typing in 
commands manually, the device add / remove commands don't work.


So no need to do any more testing at this point -- it's almost 
certainly a qemu-side thing, which means we should probably post the 
patches first, and then look at how we can get them working with 
usbversion=3.


Thanks for your help.  I'll cc you when I send the updated patches.

 -George




Recently I not tested usb3, only usb2 with spice usbredirection, maybe 
there are regressions with usb3on updated qemu, I'll try as soon as I 
can.

What version of upstream qemu are you using?


I did a fast test now with usb3 with spice usbredirection and seems 
there is a regression :(
I tried it on windows 7 domU 64 bit, after installed the usb3 drivers 
qemu crashed with this error:
qemu-system-i386: /mnt/vm/qemu/qemu-2.0.0+dfsg/hw/usb/hcd-xhci.c:882: 
xhci_events_update: Assertion `intr->er_full' failed.
I rebooted the domU and tried to redirect two usb devices but nothing 
happen.
Seems that also xen usb passthrough with usb3 is no more working (see 
George Dunlap post above).
When I tried it last year it worked, I do not remember the exact 
versions of all software of old tests.

Using usb2 (default in libxl) is still working.

Now I used wheezy dom0 with xen 4.4.0 from custom packages, seabios 
1.7.4-4~bpo70+1 and qemu 2.0.0+dfsg-4~bpo70+1:

http://lists.xen.org/archives/html/xen-users/2014-05/msg00187.html

Added qemu-devel on cc and changed the mail title.

Thanks for any reply and sorry for my bad english.

[Qemu-devel] Xentop's vbd_rd and vbd_wr missed with upstream qemu qdisk

[Fabio Fantoni]

vbd_rd and vbd_wr fileds are always 0 in xentop using upstream qemu and 
domUs with qdisk disks.
If I remember good time ago I have read that this part should be 
implemented in qemu.

Are there some news about it?

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 16:28, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 16:20 +0200, Fabio Fantoni wrote:

Il 16/05/2014 15:56, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:

Il 16/05/2014 14:47, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:

This patch adds basic spice support for pv domUs.
The qemu parameters are the same as the hvm ones and they works.
Therefore xl cfg parameters are the same as the hvm ones except that
features not supported yet by pv domUs (vdagent and usbredirection)
are kept disabled by default.
It also enables vfb and vkb required to have basic spice working.

Based on your response in<53722538.80...@m2r.biz>  I'm not sure if this
an accurate description of what you are doing here. AFAICT what you are
actually doing is enabling SPICE as a backend for the PVFB device, as an
alternative to VNC and SDL. Is that correct or not?

Yes,

In that case then these spice settings should be part of
libxl_device_vfb, like the vnc ones are and they should configurable in
xl configuration files as:

vfb = [ 'spice=1,spiceport=NNN' ]

There should be no need to move the HVM spice parameters to the top
level of the domain configuration. I'm afraid my previous advice was
based on an incorrect understanding of what you were implementing
(derived from the commit message not being clear about what was actually
going on).


The only 2 main problem reimained with spice I think that are qxl not
working on linux domUs(xen related)

Given the lack of clarity shown so far about what this existing patch is
actually doing doing I'm a little concerned about how QXL is going to
fit into the model in the future.

Ian.


About libxl patch for QXL support is still the same except the refresh
with new xen-unstable.
My latest test is based on this source that include all my latest patches:
https://github.com/Fantu/Xen/commits/rebase/m2r-next
I'll repost it with updated and full noted in description.
Regarging qxl problem on xen linux domUs I didn't found other useful
details to solve the problem and I not have sufficient time now for
advanced debug.

I wasn't talking talking about the problems with it, I was talking about
how enabling QXL in the future will fit in with the data model being
introduced here. I don't want to take spice support on the assumption
that it is just a backend for PVFB and then find out that this is a
wrong model when QXL comes to get added.

My main concern is that you don't appear to understand how the model
fits together either, and yet you keep posting patches to turn things
on. This makes me very nervous.

Ian.

I seriously doubt that such things (needed for the qxl) will be ever 
done for PV guests.


If this will happen, this would be probably done in pvh instead which I 
think is simplier and quicker.


In the meantime we cannot use spice on PV guests. I believe that I'm not 
the only one to really desire this kind of support. (Spice form both hvm 
and PV guests).


Unfortunately from 2012 I saw no one with better knowledge was on the 
thread to continue and improve the spice support in xen.


So I'm doing my best despite my lack of knowledge and time.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD

[Fabio Fantoni]

Il 19/05/2014 08:44, Gerd Hoffmann ha scritto:

   Hi,


+/*
+ * Some video bioses and gfx drivers will assume the bdf of IGD is 00:02.0.
+ * So user need to set it to 00:02.0 in Xen configure file explicitly,
+ * otherwise IGD will fail to work.
+ */
+pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0));

That is asking for trouble.  Slot 2 is used by the qemu vga cards by
default, and for quite a while (before memory api was merged) it even
was impossible to change it.  libvirt still places the vga card at slot
2 for that reason -> boom.  I wouldn't be surprised if you find that
assumption in other management libs / apps too.

Why do you need that patch in the first place?  It should be possible to
configure qemu to not occupy slot 2 if you need it that way.  Just pass
'-vga none' to qemu.  Which you probably want anyway if you pass-through
a vga to the guest.  And explicitly configure a slot (via addr=
property) for all your pci devices.  Doing it only for the IGD works too
if you list the device before any other pci device on the qemu command
line.

cheers,
   Gerd


I already added vga none support on libxl, useful also for this cases:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e5738ff47b9d2e1948024100f87b1a25fcf004a

This patch is already tested and working, for now I not tested and I 
can't test with intel gpu passthrough, someone can test it with intel 
gpu passthrough?


Thanks for any reply and sorry for my bad english.





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

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 15:56, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:

Il 16/05/2014 14:47, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:

This patch adds basic spice support for pv domUs.
The qemu parameters are the same as the hvm ones and they works.
Therefore xl cfg parameters are the same as the hvm ones except that
features not supported yet by pv domUs (vdagent and usbredirection)
are kept disabled by default.
It also enables vfb and vkb required to have basic spice working.

Based on your response in <53722538.80...@m2r.biz> I'm not sure if this
an accurate description of what you are doing here. AFAICT what you are
actually doing is enabling SPICE as a backend for the PVFB device, as an
alternative to VNC and SDL. Is that correct or not?

Yes,

In that case then these spice settings should be part of
libxl_device_vfb, like the vnc ones are and they should configurable in
xl configuration files as:

vfb = [ 'spice=1,spiceport=NNN' ]

There should be no need to move the HVM spice parameters to the top
level of the domain configuration. I'm afraid my previous advice was
based on an incorrect understanding of what you were implementing
(derived from the commit message not being clear about what was actually
going on).


The only 2 main problem reimained with spice I think that are qxl not
working on linux domUs(xen related)

Given the lack of clarity shown so far about what this existing patch is
actually doing doing I'm a little concerned about how QXL is going to
fit into the model in the future.

Ian.



About libxl patch for QXL support is still the same except the refresh 
with new xen-unstable.

My latest test is based on this source that include all my latest patches:
https://github.com/Fantu/Xen/commits/rebase/m2r-next
I'll repost it with updated and full noted in description.
Regarging qxl problem on xen linux domUs I didn't found other useful 
details to solve the problem and I not have sufficient time now for 
advanced debug.


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 14:47, Ian Campbell ha scritto:

On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:

This patch adds basic spice support for pv domUs.
The qemu parameters are the same as the hvm ones and they works.
Therefore xl cfg parameters are the same as the hvm ones except that
features not supported yet by pv domUs (vdagent and usbredirection)
are kept disabled by default.
It also enables vfb and vkb required to have basic spice working.

Based on your response in <53722538.80...@m2r.biz> I'm not sure if this
an accurate description of what you are doing here. AFAICT what you are
actually doing is enabling SPICE as a backend for the PVFB device, as an
alternative to VNC and SDL. Is that correct or not?

Ian.



Yes, if nobody has a better idea when I'll have sufficient time I'll try 
to complete the vfb part duplicating thespice parametersin vfb[] and 
adding parts "missing" looking like the example code about vnc.
In this patch version (5) for now I did one fix and all other your 
previous advices except the add of spice.enable check in 
libxl__need_xenpv_qemu not needed because is always true with vfb added.


About complete spice (hvm-only for now) I am also other patches adding 2 
more spice parameters that help to lower cpu usage while maintaining the 
highest quality effects and graphics even on high resolutions.
In my latest test I had windows 7 xen domUs with qxl, max resolution and 
32 bit color on 21-23 inch monitor with good performance.
The only 2 main problem reimained with spice I think that are qxl not 
working on linux domUs(xen related) and the high cpu usage for missed 
hardware video coding/decoding support (not xen related).


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v4] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 13/05/2014 13:00, Ian Campbell ha scritto:

On Tue, 2014-05-13 at 12:51 +0200, Fabio Fantoni wrote:

Il 13/05/2014 11:50, Ian Campbell ha scritto:

On Tue, 2014-05-13 at 10:00 +0200, Fabio Fantoni wrote:

But: Does spice already require a VFB? In which case the existing
handing of that will suffice.

I think I'm probably confused about something: Does this patch
enable/expose SPICE to the guest? Or does it simply enable the existing
PVFB's output to be exposed from the qemu process to a spice client? I
had been thinking this was a parallel feature to PVFB, but I'm starting
to suspect this might actually be an additional feature *of* PVFB, which
is correct? (I'm afraid that depending on which it is I might have to
check back over my review to make sure I haven't suggested anything
stupid)

Does QXL change that answer?

QXL and other emulated vga is now not supported on pv domUs because
require an emulated pci bus and MMIO not supported on pv domUs FWIK.

Right, but what about the previous paragraph? That was the important bit
for me to understand, since it impacts the entire configuration model
and libxl API.


During my first test, I was enabled spice in pv domus but the guest wont
show nothing while connecting to it.
On my second shot, I've added -vga xenfb but it is deprecated. This way
I've got at least video out but no mouse nor keyboard.
Following the suggestions from Stefano Stabellini I've then activated
vfb the same way as for vnc and i got it all working but mouse, which is
only visible in some circumstances (such grafical debian installer) but
always working (even if not visible).
The last one is the actual patch.
Probably the vfb part is not complete or at least improvable.
Perhaps it is even not necessary if pvfb will became modified to works
with spice, so domUs use this through its modules.

Is SPICE a mechanism for exposing the PVFB or is it something entirely
separate? That is the crux of my question above.

I added also qemu-devel and spice-devel on cc:
Any one on this please?


I feel I'm not perfectly undrestanding pvfb. Please would you like
better describe me this component?

I need to understand what it is this patch is actually doing. I'm
starting to worry that perhaps you don't understand either.

Make possible using spice with basic features also on pv domUs.

*How* is the important thing. How is SPICE exposed to the guest?


FWIK spice-server is inside qemu, used but not "visible" inside the 
guest (seems similar to qemu's vnc in hvm domUs).
Inside the guest there are some advanced and optional features visible 
(installing software and additional drivers like spice-guest-tools).
The advanced features are actually not supported in the pv domUs for 
some missed requirements (for example virtio-serial and emulated pci).



How is
SPICE exposed to the user/client?


Users can use these clients to connect to guest using spice: 
remote-viewer (mainly used), spicy or spicec (deprecated).
These clients basically connect to domU's qemu using spice and also to 
some additional software/drivers installed in domU's S.O. for some 
advanced features (if enabled).




I'm a bit surprised you've been pushing a patch to enable something
without knowing the answers to these sorts questions. If you don't
understand what it does how do you know it is doing the correct thing,
and how can you therefore explain it to the person reviewing the patch?


Unfortunately at the moment seems there is no other person available to 
implementing full spice support into xen, so I'm trying to do it myself 
even if with a very short knowledge about it and few time.
Spice is a lot better then what I have used since now (xen's vnc + guest 
rdp and proprietary usb redirection).
My main goal is to use spice full featured on a thin client system to 
gain pc-like experience accessing hvm and pv domUs.
Also use different architectures (for example starting with arm on thin 
client) for now impossibile with proprietary usbredirection (only for 
x86) and with some problem that usbredirect used by spice hasn't ecc...


Spice requires the same qemu parameters on both pv and hvm domUs.
The main difference is that with pv which actually lack of video out and 
keyboard/pointer input, I have used the only thing I found working: vfb 
(+vkb).





Since emulated vgas is not supported on pv I use vfb instead, even if
this part is incomplete and rudimental.

What is incomplete and rudimentary?


The patch's part about setting/use of vfb(+vkb) with spice on pv domUs.




I'm waiting from some aswers from spice and qemu teams to share some
light on the question above.

Thanks for any reply and sorry for my bad english.


Another thing: i noticed that vnc has all its parameters duplicated in
vfb too. For the moment I omissed them since i feel they are not
necessary - aren't they

It really depends on the a

Re: [Qemu-devel] [PATCH v4] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 13/05/2014 11:50, Ian Campbell ha scritto:

On Tue, 2014-05-13 at 10:00 +0200, Fabio Fantoni wrote:

But: Does spice already require a VFB? In which case the existing
handing of that will suffice.

I think I'm probably confused about something: Does this patch
enable/expose SPICE to the guest? Or does it simply enable the existing
PVFB's output to be exposed from the qemu process to a spice client? I
had been thinking this was a parallel feature to PVFB, but I'm starting
to suspect this might actually be an additional feature *of* PVFB, which
is correct? (I'm afraid that depending on which it is I might have to
check back over my review to make sure I haven't suggested anything
stupid)

Does QXL change that answer?

QXL and other emulated vga is now not supported on pv domUs because
require an emulated pci bus and MMIO not supported on pv domUs FWIK.

Right, but what about the previous paragraph? That was the important bit
for me to understand, since it impacts the entire configuration model
and libxl API.


During my first test, I was enabled spice in pv domus but the guest wont
show nothing while connecting to it.
On my second shot, I've added -vga xenfb but it is deprecated. This way
I've got at least video out but no mouse nor keyboard.
Following the suggestions from Stefano Stabellini I've then activated
vfb the same way as for vnc and i got it all working but mouse, which is
only visible in some circumstances (such grafical debian installer) but
always working (even if not visible).
The last one is the actual patch.
Probably the vfb part is not complete or at least improvable.
Perhaps it is even not necessary if pvfb will became modified to works
with spice, so domUs use this through its modules.

Is SPICE a mechanism for exposing the PVFB or is it something entirely
separate? That is the crux of my question above.


I added also qemu-devel and spice-devel on cc:
Any one on this please?




I feel I'm not perfectly undrestanding pvfb. Please would you like
better describe me this component?

I need to understand what it is this patch is actually doing. I'm
starting to worry that perhaps you don't understand either.


Make possible using spice with basic features also on pv domUs.
Since emulated vgas is not supported on pv I use vfb instead, even if 
this part is incomplete and rudimental.
I'm waiting from some aswers from spice and qemu teams to share some 
light on the question above.


Thanks for any reply and sorry for my bad english.




Another thing: i noticed that vnc has all its parameters duplicated in
vfb too. For the moment I omissed them since i feel they are not
necessary - aren't they

It really depends on the answer to my questions above.

If SPICE is nothing to do with PVFB then it obviously makes no sense for
it to be separate.

If SPICE is just a backend for PVFB then it actually makes *more* sense
to expose spice as a PVFB configuration parameter than as a set of top
level options. The fact that VNC is exposed as a top level thing too is
somewhat anomalous but was done for xend compatibility (nb: it is the
top level duplicating the vfb VNC settings, not vice versa IMHO).

Ian.

Re: [Qemu-devel] [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 09/05/2014 16:46, Ian Campbell ha scritto:

On Fri, 2014-05-09 at 10:38 -0400, Ross Philipson wrote:

Can it be used to patch the DSDT? Or were you (Ian) thinking that the bulk
of the ACPI PCI stuff can be moved there ?

I think it can "shadow" or extend existing DSDT stuff, I don't think it
can patch as sych. But here we want to dynamically add an entire method
I think? (or hide, but I don't think that is possible).

Yea the SSDTs extend the DSDT. The DSDT is loaded to create the name
space and then SSDTs are loaded and added to the name space. If you need
to make runtime modifications like this, it is much easier to do it in
an SSDT as you suggest. What I don't know is whether you could extend
say a device, as in this case, with with a single method in a separate
SSDT. I have never really seen something like that before.

So it could be used by having two template SSDTs (one for ejectable, one
for not) and outputting the correct ones as necessary?


WRT to hide vs. remove, I believe the intent is to effectively remove
the eject method from a given device by renaming it. It could simply be
removed making the device not eject-able but I think they are trying to
avoid having to recalculate and update the checksum on the DSDT.

How does one make the device be not eject-able? I thought it was via the
presence or absence of _EJ0 (hence the renaming hack).


As to whether this has to be done at runtime, I don't know. If it does,
I wrote a lib that can generate basically any (rev2) AML on the fly. We
used it e.g. to generate WMI functionality in an SSDT at runtime. I
would be happy to share if it is useful.

Thanks. hvmloader seems to generate various bits on the fly based on
basic templates already, although perhaps those cases are simpler than
this one.

Ian.



I saw that newer qemu versions generate acpi tables in it.
Can be a good idea add the acpi changes needed by xen in qemu instead 
works on acpi tables also in hvmloader? (and perhaps even avoid 
unexpected cases with new versions of qemu or similar)

If this is a stupid idea sorry for the loss of time.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 08/05/2014 13:23, Gonglei (Arei) ha scritto:

Hi,


-Original Message-
From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
Sent: Thursday, May 08, 2014 4:17 PM
To: Gonglei (Arei); qemu-devel@nongnu.org; xen-de...@lists.xen.org
Cc: ian.campb...@citrix.com; jbeul...@suse.com;
stefano.stabell...@eu.citrix.com; anthony.per...@citrix.com; Huangweidong
(C); Hanweidong (Randy); Gaowei (UVP); Michael S. Tsirkin
Subject: Re: [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods
for PCIslots that support hotplug by runtime patching

Il 08/05/2014 06:12, Gonglei (Arei) ha scritto:

Hi,


In Xen platform, after using upstream qemu, the all of pci devices will

show

hotplug in the windows guest. In this situation, the windows guest may

occur

blue screen when VM' user click the icon of VGA card for trying unplug

VGA

card.
However, we don't hope VM's user can do such dangerous operation, and
showing
all pci devices inside the guest OS is unfriendly.

This is done by runtime patching:
 - Rename _EJ0 methods for PCI slots in DSDT to EJ0_:note that this

has

the

   same checksum, but is ignored by OSPM.
 - At compile time, look for these methods in ASL source,find the

matching

AML,
   and store the offsets of these methods in a table named

aml_ej0_data.

 - At run time, go over aml_ej0_data, check which slots not support

hotplug

and
   patch the ACPI table, replacing _EJ0 with EJ0_.

Signed-off-by: Gaowei 
Signed-off-by: Gonglei 

Tested-by: Fabio Fantoni 

Thanks for this very useful patch that avoid that unaware users or as
mistake make windows domUs unusable.


Thanks.


I tried to quickly look at the patch to understand how to add some
optional components, for example on my case the pv drivers, the audio
card and the spice guest tools (see attachment) but I don't understand
how to do it.
Can someone give me some advices about it please?


Maybe you can hard code at libxl__build_device_model_args_new()
in tools/libxl/libxl_dm.c


Best regards,
-Gonglei


I believe I not understand what you mean.
About adding these components I already do this:
- gplpv: http://wiki.xen.org/wiki/Xen_Windows_GplPv
http://www.ejbdigital.com.au/gplpv
- spice:
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#spice_graphics_suppo
rt
http://www.spice-space.org/download/binaries/spice-guest-tools/
- audio: add soundhw="hda" in domU's xl cfg file

This patch disables hotplug capabilities from essential pci devices.


No, if pci devices do not support hotplug, which class's no_hotplug property 
will be
set to 1, then the pci device will not show in guest os, opposite will be 
shown, such
as your pv drivers and Intel hda card.

Please see intel_hda_class_init_common() and xen_platform_class_init() 
functions.
As a comparison, you can see vga devices' class init function 
cirrus_vga_class_init()
has below code:

k->no_hotplug = 1;

If I understand what you mean wrong, please forgive me.


I saw in qemu code that intel_hda_class_init_common() and 
xen_platform_class_init() functions (and probably also virtio serial 
one) not have k->no_hotplug but in windows domUs show them in hotplug 
devices list, also with this your patch applied. (see part of 
screenshoot in attachment)

I not understand how to remove also them from windows hotplug devices list.

Thanks for any reply and sorry for my bad english.




What I mean if there is a way to prevent some other components being
part of the above list of hotplug devices.

Thanks for any reply and sorry for my bad english.

Best regards,
-Gonglei

Re: [Qemu-devel] [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 08/05/2014 06:12, Gonglei (Arei) ha scritto:

Hi,


In Xen platform, after using upstream qemu, the all of pci devices will show
hotplug in the windows guest. In this situation, the windows guest may

occur

blue screen when VM' user click the icon of VGA card for trying unplug VGA
card.
However, we don't hope VM's user can do such dangerous operation, and
showing
all pci devices inside the guest OS is unfriendly.

This is done by runtime patching:
- Rename _EJ0 methods for PCI slots in DSDT to EJ0_:note that this has

the

  same checksum, but is ignored by OSPM.
- At compile time, look for these methods in ASL source,find the

matching

AML,
  and store the offsets of these methods in a table named

aml_ej0_data.

- At run time, go over aml_ej0_data, check which slots not support

hotplug

and
  patch the ACPI table, replacing _EJ0 with EJ0_.

Signed-off-by: Gaowei 
Signed-off-by: Gonglei 

Tested-by: Fabio Fantoni 

Thanks for this very useful patch that avoid that unaware users or as
mistake make windows domUs unusable.


Thanks.


I tried to quickly look at the patch to understand how to add some
optional components, for example on my case the pv drivers, the audio
card and the spice guest tools (see attachment) but I don't understand
how to do it.
Can someone give me some advices about it please?


Maybe you can hard code at libxl__build_device_model_args_new()
in tools/libxl/libxl_dm.c


Best regards,
-Gonglei


I believe I not understand what you mean.
About adding these components I already do this:
- gplpv: http://wiki.xen.org/wiki/Xen_Windows_GplPv 
http://www.ejbdigital.com.au/gplpv
- spice: 
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#spice_graphics_support 
http://www.spice-space.org/download/binaries/spice-guest-tools/

- audio: add soundhw="hda" in domU's xl cfg file

This patch disables hotplug capabilities from essential pci devices.

What I mean if there is a way to prevent some other components being 
part of the above list of hotplug devices.


Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 07/05/2014 11:43, Gonglei (Arei) ha scritto:

Hi, all

Ping...anyone? Thanks!



Best regards,
-Gonglei



-Original Message-
From: Gonglei (Arei)
Sent: Sunday, May 04, 2014 5:25 PM
To: qemu-devel@nongnu.org; xen-de...@lists.xen.org
Cc: ian.campb...@citrix.com; jbeul...@suse.com;
stefano.stabell...@eu.citrix.com; fabio.fant...@m2r.biz;
anthony.per...@citrix.com; Huangweidong (C); Hanweidong (Randy); Gaowei
(UVP); Gonglei (Arei)
Subject: [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods for
PCIslots that support hotplug by runtime patching

From: Gaowei 

In Xen platform, after using upstream qemu, the all of pci devices will show
hotplug in the windows guest. In this situation, the windows guest may occur
blue screen when VM' user click the icon of VGA card for trying unplug VGA
card.
However, we don't hope VM's user can do such dangerous operation, and
showing
all pci devices inside the guest OS is unfriendly.

This is done by runtime patching:
   - Rename _EJ0 methods for PCI slots in DSDT to EJ0_:note that this has the
 same checksum, but is ignored by OSPM.
   - At compile time, look for these methods in ASL source,find the matching
AML,
 and store the offsets of these methods in a table named aml_ej0_data.
   - At run time, go over aml_ej0_data, check which slots not support hotplug
and
 patch the ACPI table, replacing _EJ0 with EJ0_.

Signed-off-by: Gaowei 
Signed-off-by: Gonglei 


Tested-by: Fabio Fantoni 

Thanks for this very useful patch that avoid that unaware users or as 
mistake make windows domUs unusable.


I tried to quickly look at the patch to understand how to add some 
optional components, for example on my case the pv drivers, the audio 
card and the spice guest tools (see attachment) but I don't understand 
how to do it.

Can someone give me some advices about it please?

Thanks for any reply.


---
v3->v2:
  reformat on the latest master
v2->v1:
  rework by Jan Beulich's suggestion:
  - adjust the code style

  tools/firmware/hvmloader/acpi/Makefile |  44 ++-
  tools/firmware/hvmloader/acpi/acpi2_0.h|   4 +
  tools/firmware/hvmloader/acpi/build.c  |  22 ++
  tools/firmware/hvmloader/acpi/dsdt.asl |   1 +
  tools/firmware/hvmloader/acpi/mk_dsdt.c|   2 +
  tools/firmware/hvmloader/ovmf.c|   6 +-
  tools/firmware/hvmloader/rombios.c |   4 +
  tools/firmware/hvmloader/seabios.c |   8 +
  tools/firmware/hvmloader/tools/acpi_extract.py | 308
+
  .../hvmloader/tools/acpi_extract_preprocess.py |  41 +++
  10 files changed, 428 insertions(+), 12 deletions(-)
  create mode 100644 tools/firmware/hvmloader/tools/acpi_extract.py
  create mode 100644
tools/firmware/hvmloader/tools/acpi_extract_preprocess.py

diff --git a/tools/firmware/hvmloader/acpi/Makefile
b/tools/firmware/hvmloader/acpi/Makefile
index 2c50851..f79ecc3 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -24,30 +24,46 @@ OBJS  = $(patsubst %.c,%.o,$(C_SRC))
  CFLAGS += $(CFLAGS_xeninclude)

  vpath iasl $(PATH)
+vpath python $(PATH)
+
+.DELETE_ON_ERROR:$(filter dsdt_%.c,$(C_SRC))
+
  all: acpi.a

  ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
iasl -vs -p $* -tc $<
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
+   sed -e 's/AmlCode/$*/g' $*.hex >$@.tmp
+   $(call move-if-changed,$@.tmp $@)
rm -f $*.hex $*.aml

  mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c

  dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --dm-version qemu-xen >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.tmp
+   sed -i 's/AmlCode/dsdt_anycpu_qemu_xen/g' $@.tmp
+   ./mk_dsdt --dm-version qemu-xen >> $@.tmp
+   sed -i 's/aml_ej0_name/dsdt_anycpu_qemu_xen_aml_ej0_name/g'
$@.tmp
+   sed -i 's/aml_adr_dword/dsdt_anycpu_qemu_xen_aml_adr_dword/g'
$@.tmp
+   $(call move-if-changed,$@.tmp $@)

  # NB. awk invocation is a portable alternative to 'head -n -1'
  dsdt_%cpu.asl: dsdt.asl mk_dsdt
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --maxcpu $*  >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.tmp
+   sed -i 's/AmlCode/dsdt_$*cpu/g' $@.tmp
+   ./mk_dsdt --maxcpu $*  >> $@.tmp
+   $(call move-if-changed,$@.tmp $@)

-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
-   iasl -vs -p $* -tc $*.asl
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
-   echo "int $*_len=sizeof($*);" >>$@
-   rm -f $*.aml $*.hex
+$(filter dsdt_%.c,$(C_SRC)): %.c: iasl python %.asl
+   cpp -P $*.asl > $*.asl.i.orig
+   python ../t

Re: [Qemu-devel] [Xen-devel] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 28/04/2014 14:04, Gonglei (Arei) ha scritto:

Hi,


Subject: Re: [Qemu-devel] [Xen-devel] Hvmloader: Modify ACPI to only supply
_EJ0 methods for PCIslots that support hotplug by runtime patching

On Mon, 2014-04-28 at 12:14 +0200, Fabio Fantoni wrote:

Il 22/01/2014 15:32, Fabio Fantoni ha scritto:

Il 28/10/2013 10:38, Jan Beulich ha scritto:

On 24.10.13 at 14:17, "Gonglei (Arei)" 
wrote:

Now I test the patch based on the codes of trunk, which works well.
The patch has been modified after your suggestion.

Partly. I looks reasonable now, but still not pretty. But the tools
maintainers will have to have the final say here anyway.

Jan


Are there news about this patch?

Thanks for any reply.

Ping

AFAICT the ball here is in the submitters court.

Ian.


It's so long time now, and I go near to forget this patch.
Because my work is now mainly on KVM. But the patch is
really usefully for XEN.


Best regards,
-Gonglei


Could you repost it for xen 4.5?

Thanks for any reply.

Re: [Qemu-devel] [Xen-devel] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 22/01/2014 15:32, Fabio Fantoni ha scritto:

Il 28/10/2013 10:38, Jan Beulich ha scritto:
On 24.10.13 at 14:17, "Gonglei (Arei)"  
wrote:

Now I test the patch based on the codes of trunk, which works well.
The patch has been modified after your suggestion.

Partly. I looks reasonable now, but still not pretty. But the tools
maintainers will have to have the final say here anyway.

Jan



Are there news about this patch?

Thanks for any reply.

Ping

[Qemu-devel] High dom0 cpu usage using spice

[Fabio Fantoni]

After endless troubles I'm finally approaching to use spice on xen in 
production in place of vnc+rdp.
I have noticed an high dom0 cpu usage by guest's qemu process when spice 
is used (in particular using video streaming).


This is my test system:

Dom0:
Dell Poweredge T310 with cpu xeon X3450 and 12 gb of ram
Debian 7 (Wheezy) 64 bit with kernel from package 
linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages 
for xen, spice and usb redirection.
Seabios 1.7.4-4, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from 
debian unstable sources.
Latest xen-unstable with some patches 
(https://github.com/Fantu/Xen/commits/hvm-improve.t10) with qemu 2.0.0-rc2.
jpeg-turbo from x2go repository to make spice-server using it and 
decrease cpu usage.


DomU:
windows 7 pro 64 bit with latest gplpv and spice guest tools 0.74
stdvga with 32 mb videoram (qxl for now not working on xen, my latest 
test report of some months ago was without replies)

resolution 1280x768x16bit

Spice client:
good notebook with core i5 cpu with Fedora 20 updated


On start of my tests the dom0 cpu usage was avarage to 60-100% even with 
only one active guest using spice.
Disabling the spice images compression the dom0 cpu usage was up to 30% 
but with drawback of an increased network traffic, specially during 
video streaming.


Can someone advice me to further keep cpu down and/or other optimizations?
Thanks for any reply.

Re: [Qemu-devel] [Spice-devel] Automatic spice port selection

[Fabio Fantoni]

Il 22/04/2014 10:35, Gerd Hoffmann ha scritto:

   Hi,


Can someone add spice automatic port selection on qemu similar to vnc ones
please?

Not so easy as this is handled by spice-server not qemu, so this
requires some new interfaces to communicate the listening address to
qemu.  Otherwise you can't see the port selected in 'info spice', which
would make the whole thing pretty pointless.

Also note that the automatic port selection code in qemu is rarely used
in practice due to libvirt doing the port selection in typical setups.
And it is a bit flaky.  I've seen it happily grab port 5900 in ipv6
space even though it was in use in ipv4 space.  Which is probably not
the behavior expected by most users ...

cheers,
   Gerd


Thanks for your reply.
In xen I always used the vnc automatic port selection, which use the 
qemu's auto port selection.
Now I'm switching from vnc to spice on xen production systems, and I 
need an automatic port selection like vnc.
I believe that lot of xen users will like this feature and part of them 
still stuck on vnc due to the lack of it.

Could any one help to add this feature?
Why not implement it on libxl? (awaiting xen-devel feedback)

Thanks for any reply.

Re: [Qemu-devel] [Xen-devel] [PATCH v3 2/4] GlobalProperty: Display warning about unused -global

[Fabio Fantoni]

Il 18/04/2014 18:54, Fabio Fantoni ha scritto:


Il 18/04/2014 17:59, Andreas Färber ha scritto:

Am 18.04.2014 17:36, schrieb Fabio Fantoni:

2014-04-18 17:21 GMT+02:00 Andreas Färber mailto:afaer...@suse.de>>:

 Hi Don,

 Am 25.03.2014 00 :55, schrieb Don Slutz:
 > This can help a user understand why -global was ignored.
 >
 > For example: with "-vga cirrus"; "-global vga.vgamem_mb=16" 
is just

 > ignored when "-global cirrus-vga.vgamem_mb=16" is not.
 >
 > This is currently clear when the wrong property is provided:
 >
 > out/x86_64-softmmu/qemu-system-x86_64 -global
 cirrus-vga.vram_size_mb=16 -monitor pty -vga cirrus
 > char device redirected to /dev/pts/20 (label compat_monitor0)
 > qemu-system-x86_64: Property '.vram_size_mb' not found
 > Aborted (core dumped)
 >
 > vs
 >
 > out/x86_64-softmmu/qemu-system-x86_64 -global 
vga.vram_size_mb=16

 -monitor pty -vga cirrus
 > char device redirected to /dev/pts/20 (label compat_monitor0)
 > VNC server running on `::1:5900'
 > ^Cqemu: terminating on signal 2


I added the cirrus video memory setting in libxl time ago (using 
-global

vga.vram_size_mb), testing it with qemu 1.3 and also on qemu 1.6 when I
changed from -vga to -device if I remember good.
Has been changed in recent versions or something was not right even
though it seemed right to me?

There are multiple graphics cards to choose from. When using -vga std or
-device vga, then -global vga.foo=bar gets used; if -vga cirrus or
-device cirrus-vga then it needs to be -global cirrus-vga.foo=bar and
any -global vga.foo=bar gets ignored - unless you manage to add it as
secondary (PCI) graphics card.


Thanks for your reply.
Can you tell me if also -device cirrus-vga,vram_size_mb=N is correct 
and working?


I probably found the correct values settable:

in

in hw/display/cirrus_vga.c:

2988 static Property pci_vga_cirrus_properties[] = {
2989 DEFINE_PROP_UINT32("vgamem_mb", struct PCICirrusVGAState,
2990cirrus_vga.vga.vram_size_mb, 8),
2991 DEFINE_PROP_END_OF_LIST(),
2992 };
Than I "-device cirrus-vga,vgamem_mb=N", not show errors and should be 
correct, right?


in hw/display/vga-pci.c:

 182 static Property vga_pci_properties[] = {
183 DEFINE_PROP_UINT32("vgamem_mb", PCIVGAState, vga.vram_size_mb, 
16),
184 DEFINE_PROP_BIT("mmio", PCIVGAState, flags, 
PCI_VGA_FLAG_ENABLE_MMIO, true),

185 DEFINE_PROP_END_OF_LIST(),
186 };
I tried time ago the videoram setting of stdvga on xen but seems was not 
worked (no error but performance remain bad on medium/large resolution, 
trying kvm with same parameters is better), I not know if is vgabios 
problem or low level xen changes are needed.
The mmio option seems new to me, what it is in practice, may need to 
disable it in xen?


Thanks for any reply and sorry for my bad english.




Thanks for any reply.


Regards,
Andreas

P.S. Please remember to use text format mails.

[Qemu-devel] spice bug: QXLInterface::client_monitors_config failed/missing unexpectedly

[Fabio Fantoni]

Testing latest xen with qemu 2.0.0-rc2 and spice-server 0.12.4 I found 
this bug on qemu logs of domU using emulated vga different from qxl (for 
now not working on xen, already reported in the past but not yet resolved):

...
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 142.148000 ms, bitrate 
416109 bps (0.396832 Mbps) LOW BANDWIDTH

inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer:
main_channel_handle_parsed: agent start
(/usr/sbin/xl:3581): Spice-Warning **: 
red_dispatcher.c:334:red_dispatcher_client_monitors_config: spice bug: 
QXLInterface::client_monitors_config failed/missing unexpectedly


main_channel_handle_parsed: agent start
(/usr/sbin/xl:3581): Spice-Warning **: 
red_dispatcher.c:334:red_dispatcher_client_monitors_config: spice bug: 
QXLInterface::client_monitors_config failed/missing unexpectedly


(/usr/sbin/xl:3581): Spice-Warning **: 
red_dispatcher.c:334:red_dispatcher_client_monitors_config: spice bug: 
QXLInterface::client_monitors_config failed/missing unexpectedly


main_channel_handle_parsed: agent start
(/usr/sbin/xl:3581): Spice-Warning **: 
red_dispatcher.c:334:red_dispatcher_client_monitors_config: spice bug: 
QXLInterface::client_monitors_config failed/missing unexpectedly


It is normal not using qxl and does not create problems or needs to be 
placed?

If you need more informations or test tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [Xen-devel] [PATCH v3 2/4] GlobalProperty: Display warning about unused -global

[Fabio Fantoni]

Il 18/04/2014 17:59, Andreas Färber ha scritto:

Am 18.04.2014 17:36, schrieb Fabio Fantoni:

2014-04-18 17:21 GMT+02:00 Andreas Färber mailto:afaer...@suse.de>>:

 Hi Don,

 Am 25.03.2014 00 :55, schrieb Don Slutz:
 > This can help a user understand why -global was ignored.
 >
 > For example: with "-vga cirrus"; "-global vga.vgamem_mb=16" is just
 > ignored when "-global cirrus-vga.vgamem_mb=16" is not.
 >
 > This is currently clear when the wrong property is provided:
 >
 > out/x86_64-softmmu/qemu-system-x86_64 -global
 cirrus-vga.vram_size_mb=16 -monitor pty -vga cirrus
 > char device redirected to /dev/pts/20 (label compat_monitor0)
 > qemu-system-x86_64: Property '.vram_size_mb' not found
 > Aborted (core dumped)
 >
 > vs
 >
 > out/x86_64-softmmu/qemu-system-x86_64 -global vga.vram_size_mb=16
 -monitor pty -vga cirrus
 > char device redirected to /dev/pts/20 (label compat_monitor0)
 > VNC server running on `::1:5900'
 > ^Cqemu: terminating on signal 2


I added the cirrus video memory setting in libxl time ago (using -global
vga.vram_size_mb), testing it with qemu 1.3 and also on qemu 1.6 when I
changed from -vga to -device if I remember good.
Has been changed in recent versions or something was not right even
though it seemed right to me?

There are multiple graphics cards to choose from. When using -vga std or
-device vga, then -global vga.foo=bar gets used; if -vga cirrus or
-device cirrus-vga then it needs to be -global cirrus-vga.foo=bar and
any -global vga.foo=bar gets ignored - unless you manage to add it as
secondary (PCI) graphics card.


Thanks for your reply.
Can you tell me if also -device cirrus-vga,vram_size_mb=N is correct and 
working?


Thanks for any reply.


Regards,
Andreas

P.S. Please remember to use text format mails.

Re: [Qemu-devel] [Xen-devel] [PATCH v3 2/4] GlobalProperty: Display warning about unused -global

[Fabio Fantoni]

2014-04-18 17:21 GMT+02:00 Andreas Färber :

> Hi Don,
>
> Am 25.03.2014 00:55, schrieb Don Slutz:
> > This can help a user understand why -global was ignored.
> >
> > For example: with "-vga cirrus"; "-global vga.vgamem_mb=16" is just
> > ignored when "-global cirrus-vga.vgamem_mb=16" is not.
> >
> > This is currently clear when the wrong property is provided:
> >
> > out/x86_64-softmmu/qemu-system-x86_64 -global cirrus-vga.vram_size_mb=16
> -monitor pty -vga cirrus
> > char device redirected to /dev/pts/20 (label compat_monitor0)
> > qemu-system-x86_64: Property '.vram_size_mb' not found
> > Aborted (core dumped)
> >
> > vs
> >
> > out/x86_64-softmmu/qemu-system-x86_64 -global vga.vram_size_mb=16
> -monitor pty -vga cirrus
> > char device redirected to /dev/pts/20 (label compat_monitor0)
> > VNC server running on `::1:5900'
> > ^Cqemu: terminating on signal 2
>

I added the cirrus video memory setting in libxl time ago (using -global
vga.vram_size_mb), testing it with qemu 1.3 and also on qemu 1.6 when I
changed from -vga to -device if I remember good.
Has been changed in recent versions or something was not right even though it
seemed right to me?

Thanks for any reply and sorry for my bad english.


> >
> > Signed-off-by: Don Slutz 
>
> Improving this is greatly appreciated, thanks.
>
> Now, I can see two ways things can go wrong: a) Mistyping or later
> refactoring devices, or b) user typos or thinkos.
> And four ways to set globals: -global, config file (I hope?), legacy
> command line options (vl.c) and machine .compat_props.
>
> If a property does not exist on the instance of an existing type,
> object_property_parse() will raise an Error and we will abort in
> device_post_init().
>
> What we are silently missing is if a type is misspelled; for that we can
> probably add an Error **errp to the two qdev_prop_register_global*()
> functions - assuming QOM types are already registered at that point.
> qom-test would help us catch any such mistake by instantiating each
> machine.
>
> I note that your proposed check is not failing, but still, with hot-add
> of e.g. PCI devices we might well get a global property default for a
> type that is not instantiated immediately but possibly used later on.
>
> > ---
> >  hw/core/qdev-properties-system.c |  1 +
> >  hw/core/qdev-properties.c| 15 +++
> >  include/hw/qdev-core.h   |  1 +
> >  include/hw/qdev-properties.h |  1 +
> >  vl.c |  2 ++
> >  5 files changed, 20 insertions(+)
>
> FWIW I'd prefer "qdev:" for consistency (and yes, it's ambiguous), since
> there are no "GlobalProperty" files or directory.
>
> > diff --git a/hw/core/qdev-properties-system.c
> b/hw/core/qdev-properties-system.c
> > index de83561..9c742ca 100644
> > --- a/hw/core/qdev-properties-system.c
> > +++ b/hw/core/qdev-properties-system.c
> > @@ -444,6 +444,7 @@ static int qdev_add_one_global(QemuOpts *opts, void
> *opaque)
> >  g->driver   = qemu_opt_get(opts, "driver");
> >  g->property = qemu_opt_get(opts, "property");
> >  g->value= qemu_opt_get(opts, "value");
> > +g->not_used = true;
> >  qdev_prop_register_global(g);
> >  return 0;
> >  }
>
> IIUC your patch relies on not_used being false in the non-QemuOpts case
> to avoid noise when using -nodefaults or pc*-x.y. Still, the C99 struct
> initializations elsewhere get that field as well, hmm. An alternative
> would be a separate linked list for user-supplied globals.
>
> > diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> > index c67acf5..437c008 100644
> > --- a/hw/core/qdev-properties.c
> > +++ b/hw/core/qdev-properties.c
> > @@ -951,6 +951,20 @@ void qdev_prop_register_global_list(GlobalProperty
> *props)
> >  }
> >  }
> >
> > +void qdev_prop_check_global(void)
> > +{
> > +GlobalProperty *prop;
> > +
> > +QTAILQ_FOREACH(prop, &global_props, next) {
> > +if (!prop->not_used) {
> > +continue;
> > +}
> > +fprintf(stderr, "Warning: \"-global %s.%s=%s\" not used\n",
> > +prop->driver, prop->property, prop->value);
> > +
> > +}
> > +}
> > +
> >  void qdev_prop_set_globals_for_type(DeviceState *dev, const char
> *typename,
> >  Error **errp)
> >  {
> > @@ -962,6 +976,7 @@ void qdev_prop_set_globals_for_type(DeviceState
> *dev, const char *typename,
> >  if (strcmp(typename, prop->driver) != 0) {
> >  continue;
> >  }
> > +prop->not_used = false;
> >  object_property_parse(OBJECT(dev), prop->value, prop->property,
> &err);
> >  if (err != NULL) {
> >  error_propagate(errp, err);
> > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > index dbe473c..131fb49 100644
> > --- a/include/hw/qdev-core.h
> > +++ b/include/hw/qdev-core.h
> > @@ -235,6 +235,7 @@ typedef struct GlobalProperty {
> >  const char *driver;
> >  const char *property;
> >  const 

Re: [Qemu-devel] [Spice-devel] Automatic spice port selection

[Fabio Fantoni]

2014-04-18 9:42 GMT+02:00 Christophe Fergeau :

>
>
> - Mail original -
> > Il 26/03/2014 17:15, Fabio Fantoni ha scritto:
> > > Time ago I have read somewhere that there is an option to
> > > automatically spice port in qemu as for vnc.
> > > I started to write a libxl patch to add this feature like the vnc one:
> > >
> https://github.com/Fantu/Xen/commit/63c54f354a34e7eb27b1c69016789a372a75843c
> > >
> > >
> > > Testing this patch lead to a missing "to=" parameter and I didn't
> > > found nothing else.
> > >
> > > Is there someone that can tell me that if it is possible to let qemu
> > > automatically assign a spice port like for vnc?
>
> libvirt does automatic port assignemnt for SPICE, but I think it does it
> 'manually' (with no support from SPICE). I don't think spice-server/qemu
> has magic to automatically allocate the spice port to be used.
>
> Christophe
>

Thanks for reply.
Can someone add spice automatic port selection on qemu similar to vnc ones
please?

Re: [Qemu-devel] Automatic spice port selection

[Fabio Fantoni]

Il 26/03/2014 17:15, Fabio Fantoni ha scritto:
Time ago I have read somewhere that there is an option to 
automatically spice port in qemu as for vnc.

I started to write a libxl patch to add this feature like the vnc one:
https://github.com/Fantu/Xen/commit/63c54f354a34e7eb27b1c69016789a372a75843c 



Testing this patch lead to a missing "to=" parameter and I didn't 
found nothing else.


Is there someone that can tell me that if it is possible to let qemu 
automatically assign a spice port like for vnc?


Thanks for any reply.


Ping

Re: [Qemu-devel] [Spice-devel] [Xen-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 07/04/2014 15:19, Fabio Fantoni ha scritto:

Il 07/04/2014 12:20, Christophe Fergeau ha scritto:

On Mon, Apr 07, 2014 at 11:59:06AM +0200, Fabio Fantoni wrote:

Today I did some tests also with hvm and spice and I found another
segfault with different backtrace to solve:

(gdb) c
Continuing.

*Program received signal SIGSEGV, Segmentation fault.**
**0x55855d30 in interface_client_monitors_config
(sin=0x563b0260, **
**mc=0x0) at ui/spice-display.c:557**
**557 if (mc->num_of_monitors > 0) {*
(gdb) bt full
#0  0x55855d30 in interface_client_monitors_config (
sin=0x563b0260, mc=0x0) at ui/spice-display.c:557
ssd = 0x563b0210
info = {xoff = 0, yoff = 0, width = 0, height = 0}
rc = 32767
__func__ = "interface_client_monitors_config"
#1  0x74af5113 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
A backtrace with spice-server debugging symbols installed would be 
helpful.


Christophe


Sorry, the -dbg for spice-server on official debian packages is 
missing, now I created and installed also the -dbg package and this is 
the new backtrace:



(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x55855d30 in interface_client_monitors_config 
(sin=0x563b0260,

mc=0x0) at ui/spice-display.c:557
557 if (mc->num_of_monitors > 0) {
(gdb) bt full
#0  0x55855d30 in interface_client_monitors_config (
sin=0x563b0260, mc=0x0) at ui/spice-display.c:557
ssd = 0x563b0210
info = {xoff = 0, yoff = 0, width = 0, height = 0}
rc = 32767
__func__ = "interface_client_monitors_config"
#1  0x74af5113 in red_dispatcher_use_client_monitors_config ()
at red_dispatcher.c:318
now = 0x563b0300
#2  0x74ad87f5 in agent_msg_filter_process_data (
filter=filter@entry=0x562eb0c4,
data=data@entry=0x7fffe0280128 "\001", len=328, len@entry=348)
at agent-msg-filter.c:95
msg_header = {protocol = , type = out>,

  opaque = , size = 328,
  data = 0x831fd4 }
__FUNCTION__ = "agent_msg_filter_process_data"
#3  0x74b1af76 in reds_on_main_agent_data (mcc=0x56326e70,
message=0x7fffe0280128, size=348) at reds.c:1117
dev_state = 0x562eb0a8
header = 
res = 
__FUNCTION__ = "reds_on_main_agent_data"
#4  0x74ae989a in main_channel_handle_parsed 
(rcc=0x56326e70,

size=, type=, message=0x7fffe0280128)
---Type  to continue, or q  to quit---
at main_channel.c:911
main_chan = 0x562ef2b0
mcc = 0x56326e70
__FUNCTION__ = "main_channel_handle_parsed"
#5  0x74aee470 in red_peer_handle_incoming 
(handler=0x5632af80,

stream=0x565adba0) at red_channel.c:287
ret_handle = 
bytes_read = 
msg_type = 107
parsed = 
parsed_free = 0x74ba8620 
msg_size = 348
#6  red_channel_client_receive (rcc=rcc@entry=0x56326e70)
at red_channel.c:309
No locals.
#7  0x74af0d8c in red_channel_client_event (fd=,
event=, data=0x56326e70) at red_channel.c:1435
rcc = 0x56326e70
#8  0x55851f82 in watch_read (opaque=0x5666e0a0)
at ui/spice-core.c:101
watch = 0x5666e0a0
#9  0x557ce1f8 in qemu_iohandler_poll 
(pollfds=0x562e8e00, ret=1)

at iohandler.c:143
revents = 1
pioh = 0x5634e080
---Type  to continue, or q  to quit---
ioh = 0x5632fa30
#10 0x557cf2a4 in main_loop_wait (nonblocking=0) at 
main-loop.c:485

ret = 1
timeout = 4294967295
timeout_ns = 4237075
#11 0x5587acd8 in main_loop () at vl.c:2051
nonblocking = false
last_io = 1
#12 0x558826b2 in main (argc=36, argv=0x7fffe358,
envp=0x7fffe480) at vl.c:4507
i = 64
snapshot = 0
linux_boot = 0
icount_option = 0x0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a1b5c4 ""
boot_order = 0x562e7ee0 "dc"
ds = 0x563d8fd0
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x562e7e30
---Type  to continue, or q  to quit---
machine_opts = 0x562e84b0
olist = 0x55e00e00
optind = 36
optarg = 0x7fffe915 
"if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"

loadvm = 0x0
machine_class = 0x562e02a0
machine = 0x55e067e0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
qtest_log = 0x0
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = true
userconfig = true
log_mask = 0x0

Re: [Qemu-devel] [Spice-devel] [Xen-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 07/04/2014 12:20, Christophe Fergeau ha scritto:

On Mon, Apr 07, 2014 at 11:59:06AM +0200, Fabio Fantoni wrote:

Today I did some tests also with hvm and spice and I found another
segfault with different backtrace to solve:

(gdb) c
Continuing.

*Program received signal SIGSEGV, Segmentation fault.**
**0x55855d30 in interface_client_monitors_config
(sin=0x563b0260, **
**mc=0x0) at ui/spice-display.c:557**
**557 if (mc->num_of_monitors > 0) {*
(gdb) bt full
#0  0x55855d30 in interface_client_monitors_config (
sin=0x563b0260, mc=0x0) at ui/spice-display.c:557
ssd = 0x563b0210
info = {xoff = 0, yoff = 0, width = 0, height = 0}
rc = 32767
__func__ = "interface_client_monitors_config"
#1  0x74af5113 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.

A backtrace with spice-server debugging symbols installed would be helpful.

Christophe


Sorry, the -dbg for spice-server on official debian packages is missing, 
now I created and installed also the -dbg package and this is the new 
backtrace:



(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x55855d30 in interface_client_monitors_config 
(sin=0x563b0260,

mc=0x0) at ui/spice-display.c:557
557 if (mc->num_of_monitors > 0) {
(gdb) bt full
#0  0x55855d30 in interface_client_monitors_config (
sin=0x563b0260, mc=0x0) at ui/spice-display.c:557
ssd = 0x563b0210
info = {xoff = 0, yoff = 0, width = 0, height = 0}
rc = 32767
__func__ = "interface_client_monitors_config"
#1  0x74af5113 in red_dispatcher_use_client_monitors_config ()
at red_dispatcher.c:318
now = 0x563b0300
#2  0x74ad87f5 in agent_msg_filter_process_data (
filter=filter@entry=0x562eb0c4,
data=data@entry=0x7fffe0280128 "\001", len=328, len@entry=348)
at agent-msg-filter.c:95
msg_header = {protocol = , type = ,
  opaque = , size = 328,
  data = 0x831fd4 }
__FUNCTION__ = "agent_msg_filter_process_data"
#3  0x74b1af76 in reds_on_main_agent_data (mcc=0x56326e70,
message=0x7fffe0280128, size=348) at reds.c:1117
dev_state = 0x562eb0a8
header = 
res = 
__FUNCTION__ = "reds_on_main_agent_data"
#4  0x74ae989a in main_channel_handle_parsed (rcc=0x56326e70,
size=, type=, message=0x7fffe0280128)
---Type  to continue, or q  to quit---
at main_channel.c:911
main_chan = 0x562ef2b0
mcc = 0x56326e70
__FUNCTION__ = "main_channel_handle_parsed"
#5  0x74aee470 in red_peer_handle_incoming 
(handler=0x5632af80,

stream=0x565adba0) at red_channel.c:287
ret_handle = 
bytes_read = 
msg_type = 107
parsed = 
parsed_free = 0x74ba8620 
msg_size = 348
#6  red_channel_client_receive (rcc=rcc@entry=0x56326e70)
at red_channel.c:309
No locals.
#7  0x74af0d8c in red_channel_client_event (fd=,
event=, data=0x56326e70) at red_channel.c:1435
rcc = 0x56326e70
#8  0x55851f82 in watch_read (opaque=0x5666e0a0)
at ui/spice-core.c:101
watch = 0x5666e0a0
#9  0x557ce1f8 in qemu_iohandler_poll (pollfds=0x562e8e00, 
ret=1)

at iohandler.c:143
revents = 1
pioh = 0x5634e080
---Type  to continue, or q  to quit---
ioh = 0x5632fa30
#10 0x557cf2a4 in main_loop_wait (nonblocking=0) at 
main-loop.c:485

ret = 1
timeout = 4294967295
timeout_ns = 4237075
#11 0x5587acd8 in main_loop () at vl.c:2051
nonblocking = false
last_io = 1
#12 0x558826b2 in main (argc=36, argv=0x7fffe358,
envp=0x7fffe480) at vl.c:4507
i = 64
snapshot = 0
linux_boot = 0
icount_option = 0x0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a1b5c4 ""
boot_order = 0x562e7ee0 "dc"
ds = 0x563d8fd0
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x562e7e30
---Type  to continue, or q  to quit---
machine_opts = 0x562e84b0
olist = 0x55e00e00
optind = 36
optarg = 0x7fffe915 
"if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"

loadvm = 0x0
machine_class = 0x562e02a0
machine = 0x55e067e0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
qtest_log = 0x0
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = true
userconfig = true
log_mask = 0x0
log_file = 0x0
mem_trace = {malloc = 0x558

Re: [Qemu-devel] [Xen-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 03/04/2014 12:13, Fabio Fantoni ha scritto:

Il 03/04/2014 10:45, Ian Campbell ha scritto:

On Thu, 2014-04-03 at 10:15 +0200, Fabio Fantoni wrote:

Seems that do segfault when I connect to vnc or spice, in the test of
this backtrace after connect to vnc, spice and other things of my
patches are disabled, so do not think it is a problem caused by my 
patches.

The last spice patch of yours I saw was incorrectly accessing the wrong
half of various unions which is liable to cause all sorts of corruption
or strange behaviour. Please can you reproduce this issue without any
patches applied.

Ian.



After saw the full backtrace I saw on qemu git recent patches with fix 
on input, than I tried to update qemu to latest commit 
(82c6f513735297ad76acaaf2e87f0c5a0b3647a7) and now the segfault seems 
solve, I did some fast test with vnc and spice on same pv domUs 
without qemu crashes.
About libxl patch of spice support for pv domUs I'll improve it 
following your reply and also try to find more details about pointer 
not visible but working with spice on pv domUs.

Thanks to all for your help.



Today I did some tests also with hvm and spice and I found another 
segfault with different backtrace to solve:

(gdb) c
Continuing.

*Program received signal SIGSEGV, Segmentation fault.**
**0x55855d30 in interface_client_monitors_config 
(sin=0x563b0260, **

**mc=0x0) at ui/spice-display.c:557**
**557 if (mc->num_of_monitors > 0) {*



(gdb) bt full
#0  0x55855d30 in interface_client_monitors_config (
sin=0x563b0260, mc=0x0) at ui/spice-display.c:557
ssd = 0x563b0210
info = {xoff = 0, yoff = 0, width = 0, height = 0}
rc = 32767
__func__ = "interface_client_monitors_config"
#1  0x74af5113 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#2  0x74ad87f5 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#3  0x74b1af76 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#4  0x74ae989a in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#5  0x74aee470 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#6  0x74af0d8c in ?? ()
   from /usr/lib/x86_64-linux-gnu/libspice-server.so.1
No symbol table info available.
#7  0x55851f82 in watch_read (opaque=0x5666a8d0)
---Type  to continue, or q  to quit---
at ui/spice-core.c:101
watch = 0x5666a8d0
#8  0x557ce1f8 in qemu_iohandler_poll (pollfds=0x562e8e00, 
ret=2)

at iohandler.c:143
revents = 1
pioh = 0x5634e080
ioh = 0x5666adb0
#9  0x557cf2a4 in main_loop_wait (nonblocking=0) at 
main-loop.c:485

ret = 2
timeout = 4294967295
timeout_ns = 25664603
#10 0x5587acd8 in main_loop () at vl.c:2051
nonblocking = false
last_io = 3
#11 0x558826b2 in main (argc=36, argv=0x7fffe368,
envp=0x7fffe490) at vl.c:4507
i = 64
snapshot = 0
linux_boot = 0
icount_option = 0x0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a1b5c4 ""
boot_order = 0x562e7ee0 "dc"
ds = 0x563d8fd0
---Type  to continue, or q  to quit---
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x562e7e30
machine_opts = 0x562e84b0
olist = 0x55e00e00
optind = 36
optarg = 0x7fffe923 
"if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"

loadvm = 0x0
machine_class = 0x562e02a0
machine = 0x55e067e0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
qtest_log = 0x0
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = true
userconfig = true
log_mask = 0x0
log_file = 0x0
---Type  to continue, or q  to quit---
mem_trace = {malloc = 0x5587e56a ,
  realloc = 0x5587e5c2 ,
  free = 0x5587e629 , calloc = 0, 
try_malloc = 0,

  try_realloc = 0}
trace_events = 0x0
trace_file = 0x0
__func__ = "main"
args = {machine = 0x55e067e0, ram_size = 2130706432,
  boot_order = 0x562e7ee0 "dc", kernel_filename = 0x0,
  kernel_cmdline = 0x55a1b5c4 "", initrd_filename = 0x0,
  cpu_model = 0x0}
(gdb)


qemu from source git/master commit 82c6f513735297ad76acaaf2e87f0c5a0b3647a7
spice server packages is version 0.12.4-0nocelt2 recompiled from debian 
unstable source.


If you need more informations/tests tell me and I'll post them.

Thanks for any reply.

Re: [Qemu-devel] [Xen-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 03/04/2014 10:45, Ian Campbell ha scritto:

On Thu, 2014-04-03 at 10:15 +0200, Fabio Fantoni wrote:

Seems that do segfault when I connect to vnc or spice, in the test of
this backtrace after connect to vnc, spice and other things of my
patches are disabled, so do not think it is a problem caused by my patches.

The last spice patch of yours I saw was incorrectly accessing the wrong
half of various unions which is liable to cause all sorts of corruption
or strange behaviour. Please can you reproduce this issue without any
patches applied.

Ian.



After saw the full backtrace I saw on qemu git recent patches with fix 
on input, than I tried to update qemu to latest commit 
(82c6f513735297ad76acaaf2e87f0c5a0b3647a7) and now the segfault seems 
solve, I did some fast test with vnc and spice on same pv domUs without 
qemu crashes.
About libxl patch of spice support for pv domUs I'll improve it 
following your reply and also try to find more details about pointer not 
visible but working with spice on pv domUs.

Thanks to all for your help.

Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 02/04/2014 18:05, Anthony PERARD ha scritto:

On Tue, Apr 01, 2014 at 05:01:18PM +0200, Fabio Fantoni wrote:

Today I tried latest qemu 2.0 compiled from git (commit
63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
Debian 7 (Wheezy) 64 bit with kernel from package linux-image-3.2.0-4-amd64
version 3.2.54-2 and all dependency packages for xen, spice and usb
redirection.
Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from
debian unstable sources.
The xen-unstable upstream commit is
4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream:
tools: various things just to build test
tools: Improve make debball
libxl: Add qxl vga interface support for upstream qemu
libxl: add basic spice support for pv domUs

Have you try without your last two patches? Or even any patch at all?


I did some thing with same build and qemu 1.6 the day before and all was 
working, the problem start with change of qemu with 2.0.

I also tried disabling all things of my patches.




Qemu crashes always on domU S.O. start, on both pv and hvm domUs.

Same dom0 with qemu 1.6 from xen-unstable repository used for some tests
yesterday and was full working.
I also update seabios to 1.7.4-4 compiled from debian unstable sources but
the problem persists.

I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu
segfault related on each domU in dom0 syslog, for example the latest:
[  844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1 sp
7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000]

If you need more informations, tests and/or logs tell me and I'll post them.

What is in your guest config files?



The cfg of test with full backtrace on other my mail:

name='wheezy'
memory=1024
vcpus=2
device_model_override="/usr/lib/xen/bin/qemu-gdb"
disk=['/mnt/vm/disks/wheezy.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
#vfb=['vnc=0']
#vnc=0
#vncunused=1
#keymap="it"
#vnclisten=0.0.0.0
#spice=1
#spicehost="0.0.0.0"
#spiceport=6002
#spicepasswd="test"
#bootloader='pygrub'
# Only for installation
#kernel = "/boot/domu/wheezy/vmlinuz"
kernel = "/mnt/vm/pvgrub2/grub/pvgrub2.xen"
#ramdisk = "/boot/domu/wheezy/initrd.gz"
#extra = "debian-installer/exit/always_halt=true -- quiet console=tty0"

Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 02/04/2014 18:03, Anthony PERARD ha scritto:

On Wed, Apr 02, 2014 at 01:13:31PM +0200, Fabio Fantoni wrote:

- if you posted qemu's backtrace at the sigsegv.

I tried to use gdb following this old post:
https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html
but with same changes:

/usr/lib/xen/bin# vi qemu-system-i386
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak "$@"

gdb /usr/lib/xen/bin/qemu-system-i386.bak
target remote localhost:1234

This command with gdb on qemu fails:
xl -vvv create /etc/xen/wheezy.cfg
...
libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 device
model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device model
did not start: -3
libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled
...

the dom0 syslog show segfault also in this case and the qemu log is
different on first lines (probably for gdbserver):
less /var/log/xen/qemu-dm-wheezy.log
Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238
Listening on port 1234
Remote debugging from host 127.0.0.1
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 =
Invalid argument): Internal error
xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument


gdb on xl create show:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb)

(gdb) bt full
#0  0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#1  0x0013 in ?? ()
No symbol table info available.
#2  0x7fffe871 in ?? ()
No symbol table info available.
#3  0x7fffe897 in ?? ()
No symbol table info available.
#4  0x7fffe8a2 in ?? ()
No symbol table info available.
#5  0x7fffe8a5 in ?? ()
No symbol table info available.
#6  0x7fffe8ae in ?? ()
No symbol table info available.
#7  0x7fffe8ef in ?? ()
No symbol table info available.
#8  0x7fffe8f4 in ?? ()
No symbol table info available.
#9  0x7fffe913 in ?? ()
No symbol table info available.
#10 0x7fffe91f in ?? ()
No symbol table info available.
#11 0x7fffe92b in ?? ()
No symbol table info available.
#12 0x7fffe931 in ?? ()
---Type  to continue, or q  to quit---

the qemu include debug and is not stripped:
file /usr/lib/xen/bin/qemu-system-i386.bak
/usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
2.6.26, BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not
stripped
and I also tried:
aptitude install libc6-dbg
but same result.

I not understand what I missed for correct xl create and/or gdb
informations.
Can someone help me please?

Using gdb on qemu is not easy, you need to be quick.

When you "xl create", you have about 10 second to start gdb on qemu,
otherwise, xl will fail to create a guest.

So I advise you to start "gdb /usr/lib/xen/bin/qemu-system-i386.bak" in
a second terminal, write "target remote localhost:1234" BUT not Enter,
to keep the command ready to run.
Then, start "xl create" and imediatly, run the "target" command in gdb
and "c" (for continue) which will start qemu.

That should help you reach the point where you can get the backtrace,
after the segv.



Thanks for your reply.
I following your istructions, after "c" xl create finish.
gdb show:

(gdb) C
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x5584b4c1 in qemu_input_event_send (src=0x0, evt=0x5630a420)
at ui/input.c:146
146 s->handler->event(s->dev, src, evt);



(gdb) bt full
#0  0x5584b4c1 in qemu_input_event_send (src=0x0, 
evt=0x5630a420)

at ui/input.c:146
s = 0x0
#1  0x5584baef in qemu_input_queue_rel (src=0x0, 
axis=INPUT_AXIS_X,

value=1) at ui/input.c:272
evt = 0x5630a420
#2  0x55871043 in pointer_event (vs=0x5630a4c0, 
button_mask=0,

x=478, y=186) at ui/vnc.c:1531
bmap = {1, 2, 4, 8, 16}
con = 0x0
width = 640
height = 480
#3  0x55872c00 in protocol_client_msg (vs=0x5630a4c0,
data=0x562fe420 "\005", len=6) at ui/vnc.c:2139
i = 1446028480
limit = 22063
vd = 0x77eb6010
#4  0x55870861 in vnc_client_read (opaque=0x5630a4c0)
at ui/vnc.c:1389
len = 6
ret = 6
vs = 0x5630a4c0
ret = 6
#5  0x557cd5cc in qemu_iohandler_poll (pollfds=0x562e6a00, 
ret=1)

at iohandler.c:143
---Type  to continue, or q  to quit---
revents = 1
pioh = 0x562fa780
ioh = 0x55

Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 02/04/2014 15:31, Laszlo Ersek ha scritto:

On 04/02/14 13:13, Fabio Fantoni wrote:

Il 01/04/2014 18:24, Laszlo Ersek ha scritto:

On 04/01/14 17:01, Fabio Fantoni wrote:

Today I tried latest qemu 2.0 compiled from git (commit
63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
Debian 7 (Wheezy) 64 bit with kernel from package
linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages
for xen, spice and usb redirection.
Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from
debian unstable sources.
The xen-unstable upstream commit is
4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not
upstream:
tools: various things just to build test
tools: Improve make debball
libxl: Add qxl vga interface support for upstream qemu
libxl: add basic spice support for pv domUs

Qemu crashes always on domU S.O. start, on both pv and hvm domUs.

I may have misunderstood you (hence my gdb suggestion may not have been
appropriate) -- does the guest kernel crash *in* qemu, or does the qemu
host-side process crash? I understood your message to imply the latter.


Same dom0 with qemu 1.6 from xen-unstable repository used for some tests
yesterday and was full working.
I also update seabios to 1.7.4-4 compiled from debian unstable sources
but the problem persists.

I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu
segfault related on each domU in dom0 syslog, for example the latest:
[  844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1
sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000]

Can you reproduce this qemu process SIGSEGV while running qemu in
(host-)gdb? Or else, can you save a coredump and look into it with gdb?

The steps you describe with gdbserver target the guest OS as debuggee. I
suggested that the host side qemu process be debugged (because that's
what crashes).

Laszlo


The gdbserver target in my previous test was 
/usr/lib/xen/bin/qemu-system-i386.bak on dom0 which is called by xl 
create and crashes with segfault. I don't understand how doing that 
would target the guest OS as debuggee.

Can you describe the steps to target the right process?
Thanks for any reply.




If you need more informations, tests and/or logs tell me and I'll post
them.

Whoever looks into this would be greatly helped:
- if you bisected the issue (between 1.6 and 2.0-rcX),

I tried time ago qemu 1.7 and qemu 2.0 on start of development without
problem on domUs start but I'll retry.


- if you posted qemu's backtrace at the sigsegv.

I tried to use gdb following this old post:
https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html
but with same changes:

/usr/lib/xen/bin# vi qemu-system-i386
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak "$@"

gdb /usr/lib/xen/bin/qemu-system-i386.bak
target remote localhost:1234

This command with gdb on qemu fails:
xl -vvv create /etc/xen/wheezy.cfg
...
libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13
device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device
model did not start: -3
libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled
...

the dom0 syslog show segfault also in this case and the qemu log is
different on first lines (probably for gdbserver):
less /var/log/xen/qemu-dm-wheezy.log
Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238
Listening on port 1234
Remote debugging from host 127.0.0.1
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22
= Invalid argument): Internal error
xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument


gdb on xl create show:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb)

(gdb) bt full
#0  0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#1  0x0013 in ?? ()
No symbol table info available.
#2  0x7fffe871 in ?? ()
No symbol table info available.
#3  0x7fffe897 in ?? ()
No symbol table info available.
#4  0x7fffe8a2 in ?? ()
No symbol table info available.
#5  0x7fffe8a5 in ?? ()
No symbol table info available.
#6  0x7fffe8ae in ?? ()
No symbol table info available.
#7  0x7fffe8ef in ?? ()
No symbol table info available.
#8  0x7fffe8f4 in ?? ()
No symbol table info available.
#9  0x7fffe913 in ?? ()
No symbol table info available.
#10 0x7fffe91f in ?? ()
No symbol table info available.
#11 0x7fffe92b in ?? ()
No symbol table info available.
#12 0x7fffe931 in ?? ()
---Type  to continue, or q  to quit---

the qemu include debug and is not stripped:
file /usr/lib/xen/bin/qemu-system-i386.ba

Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Il 01/04/2014 18:24, Laszlo Ersek ha scritto:

On 04/01/14 17:01, Fabio Fantoni wrote:

Today I tried latest qemu 2.0 compiled from git (commit
63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
Debian 7 (Wheezy) 64 bit with kernel from package
linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages
for xen, spice and usb redirection.
Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from
debian unstable sources.
The xen-unstable upstream commit is
4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream:
tools: various things just to build test
tools: Improve make debball
libxl: Add qxl vga interface support for upstream qemu
libxl: add basic spice support for pv domUs

Qemu crashes always on domU S.O. start, on both pv and hvm domUs.

Same dom0 with qemu 1.6 from xen-unstable repository used for some tests
yesterday and was full working.
I also update seabios to 1.7.4-4 compiled from debian unstable sources
but the problem persists.

I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu
segfault related on each domU in dom0 syslog, for example the latest:
[  844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1
sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000]

If you need more informations, tests and/or logs tell me and I'll post
them.

Whoever looks into this would be greatly helped:
- if you bisected the issue (between 1.6 and 2.0-rcX),


I tried time ago qemu 1.7 and qemu 2.0 on start of development without 
problem on domUs start but I'll retry.



- if you posted qemu's backtrace at the sigsegv.


I tried to use gdb following this old post:
https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html
but with same changes:

/usr/lib/xen/bin# vi qemu-system-i386
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak "$@"

gdb /usr/lib/xen/bin/qemu-system-i386.bak
target remote localhost:1234

This command with gdb on qemu fails:
xl -vvv create /etc/xen/wheezy.cfg
...
libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 
device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device 
model did not start: -3

libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled
...

the dom0 syslog show segfault also in this case and the qemu log is 
different on first lines (probably for gdbserver):

less /var/log/xen/qemu-dm-wheezy.log
Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238
Listening on port 1234
Remote debugging from host 127.0.0.1
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 
= Invalid argument): Internal error

xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument


gdb on xl create show:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.

Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb)

(gdb) bt full
#0  0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#1  0x0013 in ?? ()
No symbol table info available.
#2  0x7fffe871 in ?? ()
No symbol table info available.
#3  0x7fffe897 in ?? ()
No symbol table info available.
#4  0x7fffe8a2 in ?? ()
No symbol table info available.
#5  0x7fffe8a5 in ?? ()
No symbol table info available.
#6  0x7fffe8ae in ?? ()
No symbol table info available.
#7  0x7fffe8ef in ?? ()
No symbol table info available.
#8  0x7fffe8f4 in ?? ()
No symbol table info available.
#9  0x7fffe913 in ?? ()
No symbol table info available.
#10 0x7fffe91f in ?? ()
No symbol table info available.
#11 0x7fffe92b in ?? ()
No symbol table info available.
#12 0x7fffe931 in ?? ()
---Type  to continue, or q  to quit---

the qemu include debug and is not stripped:
file /usr/lib/xen/bin/qemu-system-i386.bak
/usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.26, 
BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not stripped

and I also tried:
aptitude install libc6-dbg
but same result.

I not understand what I missed for correct xl create and/or gdb 
informations.

Can someone help me please?

Thanks for any reply



Laszlo

[Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Fabio Fantoni]

Today I tried latest qemu 2.0 compiled from git (commit 
63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
Debian 7 (Wheezy) 64 bit with kernel from package 
linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages 
for xen, spice and usb redirection.
Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from 
debian unstable sources.
The xen-unstable upstream commit is 
4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream:

tools: various things just to build test
tools: Improve make debball
libxl: Add qxl vga interface support for upstream qemu
libxl: add basic spice support for pv domUs

Qemu crashes always on domU S.O. start, on both pv and hvm domUs.

Same dom0 with qemu 1.6 from xen-unstable repository used for some tests 
yesterday and was full working.
I also update seabios to 1.7.4-4 compiled from debian unstable sources 
but the problem persists.


I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu 
segfault related on each domU in dom0 syslog, for example the latest:
[  844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1 
sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000]


If you need more informations, tests and/or logs tell me and I'll post them.

Thanks for any reply.

[Qemu-devel] Automatic spice port selection

[Fabio Fantoni]

Time ago I have read somewhere that there is an option to automatically 
spice port in qemu as for vnc.

I started to write a libxl patch to add this feature like the vnc one:
https://github.com/Fantu/Xen/commit/63c54f354a34e7eb27b1c69016789a372a75843c

Testing this patch lead to a missing "to=" parameter and I didn't found 
nothing else.


Is there someone that can tell me that if it is possible to let qemu 
automatically assign a spice port like for vnc?


Thanks for any reply.

Re: [Qemu-devel] [Xen-devel] [BUGFIX][PATCH v2] configure: Disable libtool if -fPIE does not work with it (bug #1257099)

[Fabio Fantoni]

Il 03/02/2014 12:59, Stefano Stabellini ha scritto:

On Wed, 15 Jan 2014, Paolo Bonzini wrote:

Il 03/01/2014 03:12, Don Slutz ha scritto:

Adjust TMPO and added TMPB, TMPL, and TMPA.  libtool needs the names
to be fixed (TMPB).

Add new functions do_libtool and libtool_prog.

Add check for broken gcc and libtool.

Signed-off-by: Don Slutz 
---
Was posted as an attachment.

https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html

  configure | 63 ++-
  1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index edfea95..852d021 100755
--- a/configure
+++ b/configure
@@ -12,7 +12,10 @@ else
  fi
  
  TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c"

-TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o"
+TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}"
+TMPO="${TMPDIR1}/${TMPB}.o"
+TMPL="${TMPDIR1}/${TMPB}.lo"
+TMPA="${TMPDIR1}/lib${TMPB}.la"
  TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe"
  
  # NB: do not call "exit" in the trap handler; this is buggy with some shells;

@@ -86,6 +89,38 @@ compile_prog() {
do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags
  }
  
+do_libtool() {

+local mode=$1
+shift
+# Run the compiler, capturing its output to the log.
+echo $libtool $mode --tag=CC $cc "$@" >> config.log
+$libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $?
+# Test passed. If this is an --enable-werror build, rerun
+# the test with -Werror and bail out if it fails. This
+# makes warning-generating-errors in configure test code
+# obvious to developers.
+if test "$werror" != "yes"; then
+return 0
+fi
+# Don't bother rerunning the compile if we were already using -Werror
+case "$*" in
+*-Werror*)
+   return 0
+;;
+esac
+echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log
+$libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $?
+error_exit "configure test passed without -Werror but failed with 
-Werror." \
+"This is probably a bug in the configure script. The failing command" \
+"will be at the bottom of config.log." \
+"You can run configure with --disable-werror to bypass this check."
+}
+
+libtool_prog() {
+do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || 
return $?
+do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib
+}
+
  # symbolically link $1 to $2.  Portable version of "ln -sf".
  symlink() {
rm -rf "$2"
@@ -1367,6 +1402,32 @@ EOF
fi
  fi
  
+# check for broken gcc and libtool in RHEL5

+if test -n "$libtool" -a "$pie" != "no" ; then
+  cat > $TMPC <
I'm applying this to a "configure" branch on my github repository.  Thanks!

Paolo, did this patch ever make it upstream? If so, do you have a commit
id?


I searched it on upstream qemu git (master branch now with qemu 2.0 in 
development) and I not found it.



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

Re: [Qemu-devel] [Xen-devel] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching

[Fabio Fantoni]

Il 28/10/2013 10:38, Jan Beulich ha scritto:

On 24.10.13 at 14:17, "Gonglei (Arei)"  wrote:

Now I test the patch based on the codes of trunk, which works well.
The patch has been modified after your suggestion.

Partly. I looks reasonable now, but still not pretty. But the tools
maintainers will have to have the final say here anyway.

Jan



Are there news about this patch?

Thanks for any reply.

Re: [Qemu-devel] [Xen-devel] [PATCH v2 0/2] build QEMU with Xen support on ARM

[Fabio Fantoni]

2013/12/18 Konrad Rzeszutek Wilk 

> On Wed, Dec 18, 2013 at 07:15:43PM +, Stefano Stabellini wrote:
> > Hi all,
> > the xenpv machine provides Xen paravirtualized backends for console,
> > disk and framebuffer. xenfb in particular is the only open source
> > framebuffer backend available.
> > On ARM we don't need QEMU to emulate any hardware but xenpv would still
> > be useful at least to provide xenfb.
> > This patch series allows QEMU to build and run (xenpv) with Xen support
> > on ARM.
> >
>
> This should work out of the box (with changes to the toolstack) to work
> under x86 right? I would have to do some 'vga=none' to disable the VGA
> framebuffer?
>

With this you can disable emulated vga:
http://lists.xen.org/archives/html/xen-devel/2013-12/msg00725.html
About xenfb FWIK you need also another patch already posted to support
xenfb on hvm domUs:
http://lists.xen.org/archives/html/xen-devel/2013-12/msg02592.html

I already tested vga=none but not xenfb on hvm for now.


>
> >
> > Changes in v2:
> > - use SCNu64 instead of PRIu64 with sscanf;
> > - assert mfn == (xen_pfn_t)mfn;
> > - use HOST_LONG_BITS to check for QEMU's address space size.
> >
> >
> > Stefano Stabellini (2):
> >   xen_backend: introduce xenstore_read_uint64 and
> xenstore_read_fe_uint64
> >   xen: build on ARM
> >
> >  hw/display/xenfb.c   |   18 ++
> >  hw/xen/xen_backend.c |   18 ++
> >  include/hw/xen/xen_backend.h |2 ++
> >  xen-all.c|2 +-
> >  xen-mapcache.c   |4 ++--
> >  5 files changed, 33 insertions(+), 11 deletions(-)
> >
> > ___
> > Xen-devel mailing list
> > xen-de...@lists.xen.org
> > http://lists.xen.org/xen-devel
>
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
>

Re: [Qemu-devel] [Spice-devel] Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 13/12/2013 17:22, Wei Liu ha scritto:

On Fri, Dec 13, 2013 at 10:51:01AM +0100, Fabio Fantoni wrote:

Il 12/12/2013 17:05, Fabio Fantoni ha scritto:

Il 12/12/2013 16:23, Wei Liu ha scritto:

On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
[...]

I did some other tests, I narrowed down the commit range to
the one between:

commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony')
where there is virtio net regression with xen

and

commit962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013
15:42:43 + (xen: Mark fixed platform I/O as unaligned)
where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013
19:02:41 +
and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
15:42:46 +
but qemu crashes on xl create for another error and I haven't found
which is the commit to apply with git cherry-pick so that I can
check if the virtio net regression is present.

Can someone help me please?

I added also qemu-devel to cc.


I did a quick test with Xen's QEMU, currently at

commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
Merge: 79c097d 35bdc13
Author: Stefano Stabellini 
Date:   Tue Jun 25 11:34:24 2013 +

 Merge remote branch 'perard/cpu-hotplug-port-v2' into
xen-staging-master-7


>from git://xenbits.xen.org/qemu-upstream-unstable.git

My guest is Squeeze with stock kernel 2.6.32.

vif=['model=virtio-net-pci,bridge=xenbr0']

No pci=nomsi in guest kernel command line.

Everything worked fine. And /proc/interrupts shows that it's indeed
using MSI for virtio PCI.

I'm kind of confused. (And in the long run of this thread I probably
didn't remember everything.)

Wei.

I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6
(xen_disk: mark ioreq as mapped before unmapping in error case)"

>from git://xenbits.xen.org/qemu-upstream-4.3-testing.git.

There are only 4 commits difference between mine and your test.
FWIK the only other difference is domUs kernel versions, and the
msi problem is probably a regression between kernel 2.6.32 and 3.2
(the "older" domUs used in my tests was Precise with kernel 3.2).
Tomorrow I'll try also with squeeze.

I tested with squeeze and with qemu 1.3.1, virtio net works also
without pci=nomsi, so seems kernel regression about msi using xen
(that make virtio devices not working) between versions 2.6.32 and
3.2.
Any idea about solve it?


3.2 is still old to be honest. I don't think we have the bandwidth to
look at it.

It's never easy to debug problem involving several software components.
The right thing to do is to use a) latest stable kernel tree which is
still actively maintained, b) Linus's tree. Only those actively trees
maintained / developed people have incentive / time to look at.

If you're using a specific distro kernel, it would be probably helpful
to report bug to that distro as well -- only if you're sure the bug
you're seeing is distro kernel's bug.

If you really want this feature so bad. I would sugguest you try latest
stable kernel to see if it works. If not, you probably need to revisit
your requirement and look for another route to achieve your goal.

Wei.


Thanks for your reply.
About kernel msi regression I'll do other tests.
Could it be useful to try this patch:
https://bugzilla.kernel.org/attachment.cgi?id=113791
or is it totally unrelated?



About the other regression (the upstream qemu 1.6 regression that causes 
qemu crash with virtio net) can someone help me please?



I did some other tests, I narrowed down the commit range to
the one between:

commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony')
where there is virtio net regression with xen

and

commit962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013
15:42:43 + (xen: Mark fixed platform I/O as unaligned)
where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013
19:02:41 +
and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
15:42:46 +
but qemu crashes on xl create for another error and I haven't found
which is the commit to apply with git cherry-pick so that I can
check if the virtio net regression is present.

Can someone help me please?


Thanks for any reply.

Re: [Qemu-devel] [Spice-devel] Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 12/12/2013 17:05, Fabio Fantoni ha scritto:

Il 12/12/2013 16:23, Wei Liu ha scritto:

On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
[...]
I did some other tests, I narrowed down the commit range to the one 
between:


commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony')
where there is virtio net regression with xen

and

commit962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013
15:42:43 + (xen: Mark fixed platform I/O as unaligned)
where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013
19:02:41 +
and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
15:42:46 +
but qemu crashes on xl create for another error and I haven't found
which is the commit to apply with git cherry-pick so that I can
check if the virtio net regression is present.

Can someone help me please?

I added also qemu-devel to cc.




I did a quick test with Xen's QEMU, currently at

commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
Merge: 79c097d 35bdc13
Author: Stefano Stabellini 
Date:   Tue Jun 25 11:34:24 2013 +

 Merge remote branch 'perard/cpu-hotplug-port-v2' into 
xen-staging-master-7


from git://xenbits.xen.org/qemu-upstream-unstable.git

My guest is Squeeze with stock kernel 2.6.32.

vif=['model=virtio-net-pci,bridge=xenbr0']

No pci=nomsi in guest kernel command line.

Everything worked fine. And /proc/interrupts shows that it's indeed
using MSI for virtio PCI.

I'm kind of confused. (And in the long run of this thread I probably
didn't remember everything.)

Wei.


I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6 
(xen_disk: mark ioreq as mapped before unmapping in error case)" from 
git://xenbits.xen.org/qemu-upstream-4.3-testing.git.

There are only 4 commits difference between mine and your test.
FWIK the only other difference is domUs kernel versions, and the msi 
problem is probably a regression between kernel 2.6.32 and 3.2 (the 
"older" domUs used in my tests was Precise with kernel 3.2).

Tomorrow I'll try also with squeeze.


I tested with squeeze and with qemu 1.3.1, virtio net works also without 
pci=nomsi, so seems kernel regression about msi using xen (that make 
virtio devices not working) between versions 2.6.32 and 3.2.

Any idea about solve it?



RIguardo invece l'altra regressione qemu tra il 4 e 22 luglio che da 
errore xen mapcache usando virtio net puoi aiutarmi?
Another question: the qemu 1.6 regression between july 4th-22nd 
commits (qemu crash on domU kernel load with xen mapcache error with 
virtio net), could you help me?


Thanks for any reply.


I did another test about this qemu regression and I'm unable to decrease 
the range of commits :(

Re: [Qemu-devel] [Spice-devel] Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 12/12/2013 16:23, Wei Liu ha scritto:

On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
[...]

I did some other tests, I narrowed down the commit range to the one between:

commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony')
where there is virtio net regression with xen

and

commit962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013
15:42:43 + (xen: Mark fixed platform I/O as unaligned)
where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013
19:02:41 +
and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
15:42:46 +
but qemu crashes on xl create for another error and I haven't found
which is the commit to apply with git cherry-pick so that I can
check if the virtio net regression is present.

Can someone help me please?

I added also qemu-devel to cc.




I did a quick test with Xen's QEMU, currently at

commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
Merge: 79c097d 35bdc13
Author: Stefano Stabellini 
Date:   Tue Jun 25 11:34:24 2013 +

 Merge remote branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7

from git://xenbits.xen.org/qemu-upstream-unstable.git

My guest is Squeeze with stock kernel 2.6.32.

vif=['model=virtio-net-pci,bridge=xenbr0']

No pci=nomsi in guest kernel command line.

Everything worked fine. And /proc/interrupts shows that it's indeed
using MSI for virtio PCI.

I'm kind of confused. (And in the long run of this thread I probably
didn't remember everything.)

Wei.


I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6 (xen_disk: 
mark ioreq as mapped before unmapping in error case)" from 
git://xenbits.xen.org/qemu-upstream-4.3-testing.git.

There are only 4 commits difference between mine and your test.
FWIK the only other difference is domUs kernel versions, and the msi 
problem is probably a regression between kernel 2.6.32 and 3.2 (the 
"older" domUs used in my tests was Precise with kernel 3.2).

Tomorrow I'll try also with squeeze.

RIguardo invece l'altra regressione qemu tra il 4 e 22 luglio che da 
errore xen mapcache usando virtio net puoi aiutarmi?
Another question: the qemu 1.6 regression between july 4th-22nd commits 
(qemu crash on domU kernel load with xen mapcache error with virtio 
net), could you help me?


Thanks for any reply.

Re: [Qemu-devel] [Spice-devel] Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 11/12/2013 17:55, Wei Liu ha scritto:

On Wed, Dec 11, 2013 at 05:11:37PM +0100, Fabio Fantoni wrote:

Il 11/12/2013 16:38, Wei Liu ha scritto:

On Wed, Dec 11, 2013 at 02:41:57PM +0100, Fabio Fantoni wrote:
[...]

Thanks for your reply.
Before starting bisection I tried with qemu 1.3.1 from
qemu-upstream-4.3-testing.git
No more crash with virtio net but it needs pci=nomsi to be
working, same thing for vdagent, so seems that msi problem is with
all virtio devices.
Then the problems seem 2 different, on your build you have virtio
devices working without setting pci=nomsi need to know the
differences and find the cause.

Your test with virtio net working without pci=nomsi was on ovmf only
or you tried also with seabios?

I only tried OVMF recently and since you were replying to this thread I
presumed you used OVMF as well.

I not tried ovmf for this case, I'll do.
Based on your post seem that msi problem with virtio is missed on ovmf.


Not sure, it doesn't necessary mean that it uses MSI.

Second thought on this, even if OVMF (the firmware) works it doesn't
have anything to do with kernel.

So the only option would be to fix the bug, not work around it.


I tested with Ubuntu Saucy and Ubuntu Precise, both with latest
xen-unstable (based on commit
2f718161bc292bfbdf1aeefd3932b73c0965373d), latest commit of

If you're using OVMF I suggest you update your branch to he latest
master.


qemu-upstream-4.3-testing.git and latest stable seabios from debian
package 1.7.3-2

So that you're not using seabios tree from xenbits?

debian package use upstream 1.7.3.2 version, so I not think do difference.


On both case pci=nomsi was needed to have virtio net working.

I watch the pdf of virtio spec. of this post:
http://lists.xen.org/archives/html/xen-devel/2013-12/msg01654.html
however, are not able to understand the possible cause of the
problem encountered with msi on virtio devices with xen.


That's not very relevant. The bug is in implementation.


About the crash of qemu 1.6.1 with virtio net is confirmed that is
a regression, is not critical because is not implement on libxl
now but I'll do further research.



I test with qemu 1.4 and 1.5 and they haven't the regression showing
xenmap cache error with virtio net.

So you've found out the bug was introduced in 1.6, good.


Watching history seems there aren't commits about xen mapcache
between 1.5 and 1.6, other xen and virtio changes are many, from a
quick look I could not find commit suspects to be tested.
Someone can suggest me the commits more suspects to be testedplease?


How many commits between 1.5 and 1.6? If it is not too many I think
doing bisection would be a good idea.

Wei.

I did other tests but take very long time due to a some of other
bugs fixes later.

the results for now are:

regression present on commit
c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013 15:14:18
(Merge remote-tracking branch 'bonzini/iommu-for-anthony') plus
cherry-pick of commit 755ec4ca0f92188458ad7ca549a75161cbdcf6ff pc:
Initializing ram_memory under Xen.

qemu crash on hvm domU start for other problem of which I have not
found the fix for now:
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
15:42:46 + (ne2000: pass device to ne2000_setup_io, use it as
owner)
plus cherry-pick of commit 755ec4ca0f92188458ad7ca549a75161cbdcf6ff
pc: Initializing ram_memory under Xen.

xl dmesg:
(d1) Multiprocessor initialisation:
(d1)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d1)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d1) Testing HVM environment:
(d1)  - REP INSB across page boundaries ... Bad value at 0x0050:
saw 98765400 ex
(d1) pected 987654ff
(d1) Bad value at 0x00500ffc: saw  expected ff00
(d1) Bad value at 0x005c: saw  expected ff00
(d1) Bad value at 0x00601000: saw  expected 00ff
(d1) failed
(d1)  - GS base MSRs and SWAPGS ... passed
(d1) Passed 1 of 2 tests
(d1) FAILED 1 of 2 tests
(d1) *** HVMLoader bug at tests.c:242
(d1) *** HVMLoader crashed.



It crashes in HVMloader, not QEMU. So this is probably not what you
need.

Wei.


I did some other tests, I narrowed down the commit range to the one between:

commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013 
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony') 
where there is virtio net regression with xen


and

commit962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013 
15:42:43 + (xen: Mark fixed platform I/O as unaligned)

where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013 
19:02:41 +

and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013 15:42:46 
+
but qemu crashes on xl create for another error and I haven't found 
which is the commit to apply with git cherry-pick so that I can check if 
the virtio 

Re: [Qemu-devel] Qxl problem with xen domU, is xen spice and/or qemu bugs?

[Fabio Fantoni]

Il 01/10/2013 14:52, Fabio Fantoni ha scritto:

Il 27/09/2013 15:53, Fabio Fantoni ha scritto:

Il 27/09/2013 10:51, Gerd Hoffmann ha scritto:

   Hi,


#2 When using f19 try without X11 first.  You should have a working
 framebuffer console on qxldrmfb before trying to get X11 going.
I tried on Fedora19 minimal installation and with qxl the text 
console

is working and lsmod show also qxl.

Good, so the kernel driver is running fine.


Is this your intended?

Yes.


#3 qxl has a bunch of tracepoints. Enable them, then compare xen
 results with kvm/tcg results to see where things start going 
wrong.

I enabled qxl debug with these qemu paramters:
-global qxl-vga.debug=1 -global qxl-vga.guestdebug=20

debug=1 doesn't do much, most is in tracepoints these days. I'm using
the stderr tracer most of the time (enable it using configure). Then
you can turn on qxl_* either in monitor (trace-events command) or via
-trace events=.


Thanks for reply, I used trace of qxl_* instead of -global debug 
options (is it right or must I maintain also global qxl debug option?).

On attachment the new qemu log of windows 7 test with qxl vga.
The test was made as for below:
I tried also W7 domU on xen with spice-guest-tools-0.65.exe and qxl: 
domU starts, loads correctly the DE, vdagent and mouse are both 
working, but screen refreshing is very lagging (also only open of 
start menu). 


Can you check the log to see if there are strange things to fix also 
on spice and/or qemu?

Thanks for any reply.


I tried to test Fedora19 on debian sid kvm host same qemu version
(1.6) on both sides but with qxl fails to start the DE, also in
fallback mode. Probably there are also regression on qemu and/or 
spice

about qxl.

I'm not aware of any regressions.
I'd suggest to try latest spice-server release.


I double checked and is already to latest version:
http://packages.debian.org/sid/libspice-server1



After I updated Fedora19 vm on kvm, it works with qxl.

I compared xen and kvm logs and the only relevant difference that I 
found is this line on /var/log/messages of xen domU:

ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0
I attached all messages and Xorg logs for both xen and kvm (Fedora19) 
tests with qxl.


And about xen hypervisor logs (with xl dmesg) the only difference 
between stdvga and qxl (same domU) is that qxl log has 3 "pci dev bar" 
more. Full logs on attachments.


Thanks for any reply.



HTH,
   Gerd









I made other tests with qxl using  xen_platform_pci=0 (now that it is 
functioning with qemu upstream too).
On a W7 domU the main problem with performances with qxl drivers seems 
to be solved but unfortunately I didn't find a way to have both qxl and 
xen gplpv working.

On a Saucy domU (ubuntu 13.10) with this kernel patch applied (see below):
http://lists.xen.org/archives/html/xen-devel/2013-12/msg00583.html
the black screen and X process to 100% persists.
Attached the xorg log with a backtrace in it.
Anyone on this please?

Thanks for any reply.
[ 5.296] 
X.Org X Server 1.14.3
Release Date: 2013-09-12
[ 5.296] X Protocol Version 11, Revision 0
[ 5.296] Build Operating System: Linux 3.2.0-37-generic x86_64 Ubuntu
[ 5.296] Current Operating System: Linux Saucy-HVM-domU 3.11.0-14-generic 
#21 SMP Wed Dec 4 14:54:14 CET 2013 x86_64
[ 5.296] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-14-generic 
root=UUID=c53c1a0c-2d49-42e1-bf04-082a984d03d8 ro quiet splash vt.handoff=7
[ 5.296] Build Date: 15 October 2013  09:23:37AM
[ 5.296] xorg-server 2:1.14.3-3ubuntu2 (For technical support please see 
http://www.ubuntu.com/support) 
[ 5.296] Current version of pixman: 0.30.2
[ 5.296]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 5.296] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 5.296] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec  4 16:25:30 
2013
[ 5.297] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 5.298] (==) No Layout section.  Using the first Screen section.
[ 5.298] (==) No screen section available. Using defaults.
[ 5.298] (**) |-->Screen "Default Screen Section" (0)
[ 5.298] (**) |   |-->Monitor ""
[ 5.298] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 5.298] (==) Automatically adding devices
[ 5.298] (==) Automatically enabling devices
[ 5.298] (==) Automatically adding GPU devices
[ 5.298] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 5.298]Entry deleted from font path.
[ 5.298] (WW) The directory "/usr/share/fonts/X11/100dpi/" does

Re: [Qemu-devel] [BUG] ahci -device ide-hd|ide-cd select a bus already in use

[Fabio Fantoni]

Il 03/12/2013 11:32, Markus Armbruster ha scritto:

Fabio Fantoni  writes:


I started to test/implement q35 cipset on xen hvm domUs.
I found that ide disks and cdrom don't works with q35 using old qemu
parameters without -device, this is not a blocking problem.
I tried with new qemu parameters and ahci and the disk works.
When I tried to add more that one ahci disk/cdrom devices qemu gave
this error:

qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1:
Can't create IDE unit 1, bus supports only 1 units
qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1:
Device initialization failed.
qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1:
Device 'ide-cd' could not be initialized

I used qemu 1.6.1 for the test and searching online I found the same
problem was reported also on fedora, ubuntu and red hat bugtrackers.
Looking for the solution on qemu-devel and git I found this patch:
http://git.qemu.org/?p=qemu.git;a=commit;h=0ee20e665840d8a887c145b368ee121cb86a028e
It is applied on qemu 1.6 but it seems it doesn't solve the problem of
the selection of full bus but it only show an error when it happens.
Xen with old qemu parameters use index instead of bus and unit but it
seems missing if I try to use it on -device.
I also read docs/qdev-device-use.txt but it doesn't mention index with
new -device ide-hd|ide-cd parameters and I found nothing about if=none
or any ahci disks informations, I think that this document needs to be
updated/improved.

Thanks for any reply.

You didn't tell us your complete command line.  Your error messages
suggest you try to add more than one device to the same IDE bus, like
this:

 $ qemu -nodefaults -S -display none -monitor stdio -M q35 -drive 
if=none,id=drive0,file=test.qcow2 -drive if=none,id=drive1 -device 
ide-hd,drive=drive0 -device ide-cd,drive=drive1
 QEMU 1.7.50 monitor - type 'help' for more information
 (qemu) upstream-qemu: -device ide-cd,drive=drive1: Can't create IDE unit 
1, bus supports only 1 units
 upstream-qemu: -device ide-cd,drive=drive1: Device initialization failed.
 upstream-qemu: -device ide-cd,drive=drive1: Device 'ide-cd' could not be 
initialized


Sorry, these are qemu parameters of my domU:

libxl: debug: libxl_dm.c:1327:libxl__spawn_local_dm: Spawning 
device-model /usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
/usr/lib/xen/bin/qemu-system-i386

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -xen-domid
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   9
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
chardev=libxl-cmd,mode=control

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -nodefaults
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -name
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   W7-q35
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 0.0.0.0:0,to=99
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -k
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   it
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   VGA
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   order=d
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -smp
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   2,maxcpus=2
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:3b:27:20

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -netdev
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -machine
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   q35,accel=xen
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   xen-platform
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: i82801b11-bridge
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -drive
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
file=/mnt/vm/disks/W7-q35.disk1.xm,if=none,id=drive-sata-disk0,format=raw,cache=writeback

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -device
libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm: 
ide-drive,drive=drive-sata-disk0,id=sata0

libxl: debug: libxl_dm.c:1329:libxl__spawn_local_dm:   -drive
libxl: debug: libxl_dm.c:1329:libxl__spawn_loca

[Qemu-devel] [BUG] ahci -device ide-hd|ide-cd select a bus already in use

[Fabio Fantoni]

I started to test/implement q35 cipset on xen hvm domUs.
I found that ide disks and cdrom don't works with q35 using old qemu 
parameters without -device, this is not a blocking problem.

I tried with new qemu parameters and ahci and the disk works.
When I tried to add more that one ahci disk/cdrom devices qemu gave this 
error:
qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1: 
Can't create IDE unit 1, bus supports only 1 units
qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1: 
Device initialization failed.
qemu-system-i386: -device ide-cd,drive=drive-sata-disk1,id=sata1: 
Device 'ide-cd' could not be initialized
I used qemu 1.6.1 for the test and searching online I found the same 
problem was reported also on fedora, ubuntu and red hat bugtrackers.

Looking for the solution on qemu-devel and git I found this patch:
http://git.qemu.org/?p=qemu.git;a=commit;h=0ee20e665840d8a887c145b368ee121cb86a028e
It is applied on qemu 1.6 but it seems it doesn't solve the problem of 
the selection of full bus but it only show an error when it happens.
Xen with old qemu parameters use index instead of bus and unit but it 
seems missing if I try to use it on -device.
I also read docs/qdev-device-use.txt but it doesn't mention index with 
new -device ide-hd|ide-cd parameters and I found nothing about if=none 
or any ahci disks informations, I think that this document needs to be 
updated/improved.


Thanks for any reply.

Re: [Qemu-devel] Questions about Spice pv domUs

[Fabio Fantoni]

Il 07/11/2013 16:25, Stefano Stabellini ha scritto:

On Thu, 7 Nov 2013, Fabio Fantoni wrote:

Il 06/11/2013 18:16, Stefano Stabellini ha scritto:

On Tue, 5 Nov 2013, Fabio Fantoni wrote:

Il 30/09/2013 16:56, Fabio Fantoni ha scritto:

I'm trying to implement basic spice support on xen pv domUs.

Test seems ok on Ubuntu 12.04 pv domU except mouse which is not visible.
I also tried agent-mouse=off on qemu spice options but is not working or
maybe spicy (from spice-gtk 0.20) has problem in this case (option to
grab
mouse is already enabled).
I can't add vdagent for now on pv because it hasn't  pci support.
Are there xen parts which may give problem with mouse or couldn't be a
xen
related problem?

Given that PCI and USB buses are both missing in PV guests, I guess that
the issue might be that spice assumes that the mouse is somehow emulated
by a USB device? I think it could be difficult to disentangle spice
support from usb/pci.
You could try to run only the mouse part of the xenfb protocol to get
mouse support.

BTW where are you running the spice backend? Is it a standalone daemon?


For now I did only fast test forcing qemu parameters for pv dom's on libxl
code with the same spice paramters used for hvm domUs.
On first test was not working, then I added xenfb vga, and the screen works
but mouse not.

Is it possible that you are actually not using spice at all, but just
using straight xenfb?



Yes, is spice on qemu, simply with xenfb as vga instead of stdvga that I 
use with hvm domUs for now.
About qxl vga (optimal for increase spice performance and more 
resolutions support), seems that requires other modifications/fix xen 
side that are not able to do :(

Latest debug that I tried if can be useful:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
Waiting for news about it I'm trying to implement at least the basic 
spice support on pv for use spice for both hvm and pv (atleast the part 
of domUs maintenance).




Qemu parameters on my test was:

libxl: debug: libxl_dm.c:1282:libxl__spawn_local_dm: Spawning
device-model
/usr/lib/xen/bin/qemu-system-i386 with arguments:
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:
/usr/lib/xen/bin/qemu-system-i386
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm: -xen-domid
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   19
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -chardev
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-19,server,nowait
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -mon
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:
chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm: -nodefaults
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm: -xen-attach
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -name
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   PRECISE
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -k
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   it
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -spice
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:
port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=off
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -vga
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   xenfb
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   xenpv
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   -m
libxl: debug: libxl_dm.c:1284:libxl__spawn_local_dm:   1025

I have also another question for qemu developers: I tried to change qemu
-vga parameter to -device but isn't working and I not found nothing on
docs
or man. Is xenfb available with new qemu parameter -device?

As I replied in the other email, xenfb is configured and initialized via
xenstore. Why do you want a command line parameter for it?

I tried to do fast greps without find active code about xenfb.
Can you tell me what I must search for find the new part about xenfb please?

The xenfb code is here:

hw/display/xenfb.c

It is registered here:

hw/i386/xen_machine_pv.c:xen_init_pv


Thanks, then I must search on qemu code what xenstore parameters enable 
xenfb and after search on xen, right?