Xen devel - Jul 2013 - Questions about hvm domU default devices with upstream qemu

Last year I posted a question about default devices of upstream qemu 
that differ from qemu traditional, like empty floppy and cdrom in 
particular.
About empty floppy now is disabled as workaround.
About empty cdrom Stabellini tells that is useful, so I tried to use it 
but cd-insert was failing,and I must define other empty cdrom on xl 
configuration file, for example with: '',raw,hdb,ro,cdrom''.
It seem that there isn''t default devices usable without define them in 
xen, and I think that probably need to revise the definition of the 
devices to avoid empty and unusable ones and to do everything as best as 
possible (also with possibly reviewing qemu side).
Another good thing is also consider pv domU case and possible future 
support of spice and/or other useful features.
Thanks for any reply.

Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
> Last year I posted a question about default devices of upstream qemu 
> that differ from qemu traditional, like empty floppy and cdrom in 
> particular.
> About empty floppy now is disabled as workaround.
> About empty cdrom Stabellini tells that is useful, so I tried to use 
> it but cd-insert was failing,and I must define other empty cdrom on xl 
> configuration file, for example with:
'',raw,hdb,ro,cdrom''.
> It seem that there isn''t default devices usable without define
them in
> xen, and I think that probably need to revise the definition of the 
> devices to avoid empty and unusable ones and to do everything as best 
> as possible (also with possibly reviewing qemu side).
> Another good thing is also consider pv domU case and possible future 
> support of spice and/or other useful features.
> Thanks for any reply.
I seen no replies about this, I think is important improve upstream qemu 
support and remove the traditional ASA upstream will be equivalent or 
superior in all features.

I also think is good idea add q35 support on xen.
Seem that hvm domUs have performance limits, in particular on windows 
domUs (also with pv drivers) caused probably by old hardware emulation 
by qemu and/or xen support limited on some instruction sets.
I don''t know how to add essential q35 support on hvmloader to do some 
tests and have effective data about improvements.
Anyone on this?

Thanks for any reply.

On Wed, 4 Sep 2013, Fabio Fantoni wrote:
> Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
> > Last year I posted a question about default devices of upstream qemu
that
> > differ from qemu traditional, like empty floppy and cdrom in
particular.
> > About empty floppy now is disabled as workaround.
> > About empty cdrom Stabellini tells that is useful, so I tried to use
it but
> > cd-insert was failing,and I must define other empty cdrom on xl
> > configuration file, for example with:
'',raw,hdb,ro,cdrom''.
> > It seem that there isn''t default devices usable without
define them in xen,
> > and I think that probably need to revise the definition of the devices
to
> > avoid empty and unusable ones and to do everything as best as possible
(also
> > with possibly reviewing qemu side).
> > Another good thing is also consider pv domU case and possible future
support
> > of spice and/or other useful features.
> > Thanks for any reply.
> 
> I seen no replies about this, I think is important improve upstream qemu
> support and remove the traditional ASA upstream will be equivalent or
superior
> in all features.
> 
> I also think is good idea add q35 support on xen.
> Seem that hvm domUs have performance limits, in particular on windows domUs
> (also with pv drivers) caused probably by old hardware emulation by qemu
> and/or xen support limited on some instruction sets.
> I don''t know how to add essential q35 support on hvmloader to do
some tests
> and have effective data about improvements.
> Anyone on this?
I agree that this is important and thanks for raising the issue.
It would be nice if somebody stepped up to do the q35 work.

Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>> Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
>>> Last year I posted a question about default devices of upstream
qemu that
>>> differ from qemu traditional, like empty floppy and cdrom in
particular.
>>> About empty floppy now is disabled as workaround.
>>> About empty cdrom Stabellini tells that is useful, so I tried to
use it but
>>> cd-insert was failing,and I must define other empty cdrom on xl
>>> configuration file, for example with:
'',raw,hdb,ro,cdrom''.
>>> It seem that there isn''t default devices usable without
define them in xen,
>>> and I think that probably need to revise the definition of the
devices to
>>> avoid empty and unusable ones and to do everything as best as
possible (also
>>> with possibly reviewing qemu side).
>>> Another good thing is also consider pv domU case and possible
future support
>>> of spice and/or other useful features.
>>> Thanks for any reply.
>> I seen no replies about this, I think is important improve upstream
qemu
>> support and remove the traditional ASA upstream will be equivalent or
superior
>> in all features.
>>
>> I also think is good idea add q35 support on xen.
>> Seem that hvm domUs have performance limits, in particular on windows
domUs
>> (also with pv drivers) caused probably by old hardware emulation by
qemu
>> and/or xen support limited on some instruction sets.
>> I don''t know how to add essential q35 support on hvmloader to
do some tests
>> and have effective data about improvements.
>> Anyone on this?
> I agree that this is important and thanks for raising the issue.
> It would be nice if somebody stepped up to do the q35 work.
Thanks for reply, can you reply also on questions about default devices 
with upstream qemu please?

On Wed, 4 Sep 2013, Fabio Fantoni wrote:
> Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
> > On Wed, 4 Sep 2013, Fabio Fantoni wrote:
> > > Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
> > > > Last year I posted a question about default devices of
upstream qemu
> > > > that
> > > > differ from qemu traditional, like empty floppy and cdrom in
particular.
> > > > About empty floppy now is disabled as workaround.
> > > > About empty cdrom Stabellini tells that is useful, so I
tried to use it
> > > > but
> > > > cd-insert was failing,and I must define other empty cdrom on
xl
> > > > configuration file, for example with:
'',raw,hdb,ro,cdrom''.
> > > > It seem that there isn''t default devices usable
without define them in
> > > > xen,
> > > > and I think that probably need to revise the definition of
the devices
> > > > to
> > > > avoid empty and unusable ones and to do everything as best
as possible
> > > > (also
> > > > with possibly reviewing qemu side).
> > > > Another good thing is also consider pv domU case and
possible future
> > > > support
> > > > of spice and/or other useful features.
> > > > Thanks for any reply.
> > > I seen no replies about this, I think is important improve
upstream qemu
> > > support and remove the traditional ASA upstream will be
equivalent or
> > > superior
> > > in all features.
> > > 
> > > I also think is good idea add q35 support on xen.
> > > Seem that hvm domUs have performance limits, in particular on
windows
> > > domUs
> > > (also with pv drivers) caused probably by old hardware emulation
by qemu
> > > and/or xen support limited on some instruction sets.
> > > I don''t know how to add essential q35 support on
hvmloader to do some
> > > tests
> > > and have effective data about improvements.
> > > Anyone on this?
> > I agree that this is important and thanks for raising the issue.
> > It would be nice if somebody stepped up to do the q35 work.
> 
> Thanks for reply, can you reply also on questions about default devices
with
> upstream qemu please?
I think it might be a good idea to keep the same set of default devices
between qemu-traditional and qemu-xen.

We always had an empty cdrom and I don''t see why we should remove it.
If
cd-insert doesn''t work, it''s a bug and should be fixed.

Supporting spice in PV guests would be hard, because spice needs QXL
that is a PCI device. PV guests don''t have a PCI bus. Of course if
somebody did the work to make QXL and spice work with PV guests I would
be happy to accept it.

I agree that we should keep improving upstream QEMU, however removing
qemu-traditional is not going to be easy because it''s needed for
compatibility when a guest started with qemu-traditional is
live-migrated to a new system. But we can make sure that this remains
the only use case for it.

Il 05/09/2013 13:23, Stefano Stabellini ha scritto:
> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>> Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
>>> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>>>> Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
>>>>> Last year I posted a question about default devices of
upstream qemu
>>>>> that
>>>>> differ from qemu traditional, like empty floppy and cdrom
in particular.
>>>>> About empty floppy now is disabled as workaround.
>>>>> About empty cdrom Stabellini tells that is useful, so I
tried to use it
>>>>> but
>>>>> cd-insert was failing,and I must define other empty cdrom
on xl
>>>>> configuration file, for example with:
'',raw,hdb,ro,cdrom''.
>>>>> It seem that there isn''t default devices usable
without define them in
>>>>> xen,
>>>>> and I think that probably need to revise the definition of
the devices
>>>>> to
>>>>> avoid empty and unusable ones and to do everything as best
as possible
>>>>> (also
>>>>> with possibly reviewing qemu side).
>>>>> Another good thing is also consider pv domU case and
possible future
>>>>> support
>>>>> of spice and/or other useful features.
>>>>> Thanks for any reply.
>>>> I seen no replies about this, I think is important improve
upstream qemu
>>>> support and remove the traditional ASA upstream will be
equivalent or
>>>> superior
>>>> in all features.
>>>>
>>>> I also think is good idea add q35 support on xen.
>>>> Seem that hvm domUs have performance limits, in particular on
windows
>>>> domUs
>>>> (also with pv drivers) caused probably by old hardware
emulation by qemu
>>>> and/or xen support limited on some instruction sets.
>>>> I don''t know how to add essential q35 support on
hvmloader to do some
>>>> tests
>>>> and have effective data about improvements.
>>>> Anyone on this?
>>> I agree that this is important and thanks for raising the issue.
>>> It would be nice if somebody stepped up to do the q35 work.
>> Thanks for reply, can you reply also on questions about default devices
with
>> upstream qemu please?
> I think it might be a good idea to keep the same set of default devices
> between qemu-traditional and qemu-xen.
>
> We always had an empty cdrom and I don''t see why we should remove
it. If
> cd-insert doesn''t work, it''s a bug and should be fixed.
>
> Supporting spice in PV guests would be hard, because spice needs QXL
> that is a PCI device. PV guests don''t have a PCI bus. Of course if
> somebody did the work to make QXL and spice work with PV guests I would
> be happy to accept it.
>
> I agree that we should keep improving upstream QEMU, however removing
> qemu-traditional is not going to be easy because it''s needed for
> compatibility when a guest started with qemu-traditional is
> live-migrated to a new system. But we can make sure that this remains
> the only use case for it.
Thanks for reply.

About qemu default empty and unusable floppy and cdrom I have already 
reply at start of year that qemu traditional does not have them.
The tests were with xl only if I remember good, now I checked also on 
old production server with xend and qemu traditional. I confirm that hvm 
domUs is without empty floppy and cdrom also in that case.
cd-insert works (tested with xl and upstream qemu). cd-insert does not 
works only with qemu default empty cdrom because is undefined on xen side.

On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> Il 05/09/2013 13:23, Stefano Stabellini ha scritto:
> > On Wed, 4 Sep 2013, Fabio Fantoni wrote:
> > > Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
> > > > On Wed, 4 Sep 2013, Fabio Fantoni wrote:
> > > > > Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
> > > > > > Last year I posted a question about default
devices of upstream qemu
> > > > > > that
> > > > > > differ from qemu traditional, like empty floppy
and cdrom in
> > > > > > particular.
> > > > > > About empty floppy now is disabled as workaround.
> > > > > > About empty cdrom Stabellini tells that is useful,
so I tried to use
> > > > > > it
> > > > > > but
> > > > > > cd-insert was failing,and I must define other
empty cdrom on xl
> > > > > > configuration file, for example with:
'',raw,hdb,ro,cdrom''.
> > > > > > It seem that there isn''t default devices
usable without define them
> > > > > > in
> > > > > > xen,
> > > > > > and I think that probably need to revise the
definition of the
> > > > > > devices
> > > > > > to
> > > > > > avoid empty and unusable ones and to do everything
as best as
> > > > > > possible
> > > > > > (also
> > > > > > with possibly reviewing qemu side).
> > > > > > Another good thing is also consider pv domU case
and possible future
> > > > > > support
> > > > > > of spice and/or other useful features.
> > > > > > Thanks for any reply.
> > > > > I seen no replies about this, I think is important
improve upstream
> > > > > qemu
> > > > > support and remove the traditional ASA upstream will be
equivalent or
> > > > > superior
> > > > > in all features.
> > > > > 
> > > > > I also think is good idea add q35 support on xen.
> > > > > Seem that hvm domUs have performance limits, in
particular on windows
> > > > > domUs
> > > > > (also with pv drivers) caused probably by old hardware
emulation by
> > > > > qemu
> > > > > and/or xen support limited on some instruction sets.
> > > > > I don''t know how to add essential q35 support
on hvmloader to do some
> > > > > tests
> > > > > and have effective data about improvements.
> > > > > Anyone on this?
> > > > I agree that this is important and thanks for raising the
issue.
> > > > It would be nice if somebody stepped up to do the q35 work.
> > > Thanks for reply, can you reply also on questions about default
devices
> > > with
> > > upstream qemu please?
> > I think it might be a good idea to keep the same set of default
devices
> > between qemu-traditional and qemu-xen.
> > 
> > We always had an empty cdrom and I don''t see why we should
remove it. If
> > cd-insert doesn''t work, it''s a bug and should be
fixed.
> > 
> > Supporting spice in PV guests would be hard, because spice needs QXL
> > that is a PCI device. PV guests don''t have a PCI bus. Of
course if
> > somebody did the work to make QXL and spice work with PV guests I
would
> > be happy to accept it.
> > 
> > I agree that we should keep improving upstream QEMU, however removing
> > qemu-traditional is not going to be easy because it''s needed
for
> > compatibility when a guest started with qemu-traditional is
> > live-migrated to a new system. But we can make sure that this remains
> > the only use case for it.
> 
> Thanks for reply.
> 
> About qemu default empty and unusable floppy and cdrom I have already reply
at
> start of year that qemu traditional does not have them.
> The tests were with xl only if I remember good, now I checked also on old
> production server with xend and qemu traditional. I confirm that hvm domUs
is
> without empty floppy and cdrom also in that case.
>
> cd-insert works (tested with xl and upstream qemu). cd-insert does not
works
> only with qemu default empty cdrom because is undefined on xen side.
So HVM domUs do NOT have a cdrom drive by default with qemu-traditional.

Do they have an empty cdrom drive by default with qemu-xen?

Is the lack of a cdrom drive the reason why cd-insert doesn''t work by
default (unless you specify an empty cdrom drive in the VM config file)?

Il 05/09/2013 15:00, Stefano Stabellini ha scritto:
> On Thu, 5 Sep 2013, Fabio Fantoni wrote:
>> Il 05/09/2013 13:23, Stefano Stabellini ha scritto:
>>> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>>>> Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
>>>>> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>>>>>> Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
>>>>>>> Last year I posted a question about default devices
of upstream qemu
>>>>>>> that
>>>>>>> differ from qemu traditional, like empty floppy and
cdrom in
>>>>>>> particular.
>>>>>>> About empty floppy now is disabled as workaround.
>>>>>>> About empty cdrom Stabellini tells that is useful,
so I tried to use
>>>>>>> it
>>>>>>> but
>>>>>>> cd-insert was failing,and I must define other empty
cdrom on xl
>>>>>>> configuration file, for example with:
'',raw,hdb,ro,cdrom''.
>>>>>>> It seem that there isn''t default devices
usable without define them
>>>>>>> in
>>>>>>> xen,
>>>>>>> and I think that probably need to revise the
definition of the
>>>>>>> devices
>>>>>>> to
>>>>>>> avoid empty and unusable ones and to do everything
as best as
>>>>>>> possible
>>>>>>> (also
>>>>>>> with possibly reviewing qemu side).
>>>>>>> Another good thing is also consider pv domU case
and possible future
>>>>>>> support
>>>>>>> of spice and/or other useful features.
>>>>>>> Thanks for any reply.
>>>>>> I seen no replies about this, I think is important
improve upstream
>>>>>> qemu
>>>>>> support and remove the traditional ASA upstream will be
equivalent or
>>>>>> superior
>>>>>> in all features.
>>>>>>
>>>>>> I also think is good idea add q35 support on xen.
>>>>>> Seem that hvm domUs have performance limits, in
particular on windows
>>>>>> domUs
>>>>>> (also with pv drivers) caused probably by old hardware
emulation by
>>>>>> qemu
>>>>>> and/or xen support limited on some instruction sets.
>>>>>> I don''t know how to add essential q35 support
on hvmloader to do some
>>>>>> tests
>>>>>> and have effective data about improvements.
>>>>>> Anyone on this?
>>>>> I agree that this is important and thanks for raising the
issue.
>>>>> It would be nice if somebody stepped up to do the q35 work.
>>>> Thanks for reply, can you reply also on questions about default
devices
>>>> with
>>>> upstream qemu please?
>>> I think it might be a good idea to keep the same set of default
devices
>>> between qemu-traditional and qemu-xen.
>>>
>>> We always had an empty cdrom and I don''t see why we should
remove it. If
>>> cd-insert doesn''t work, it''s a bug and should be
fixed.
>>>
>>> Supporting spice in PV guests would be hard, because spice needs
QXL
>>> that is a PCI device. PV guests don''t have a PCI bus. Of
course if
>>> somebody did the work to make QXL and spice work with PV guests I
would
>>> be happy to accept it.
>>>
>>> I agree that we should keep improving upstream QEMU, however
removing
>>> qemu-traditional is not going to be easy because it''s
needed for
>>> compatibility when a guest started with qemu-traditional is
>>> live-migrated to a new system. But we can make sure that this
remains
>>> the only use case for it.
>> Thanks for reply.
>>
>> About qemu default empty and unusable floppy and cdrom I have already
reply at
>> start of year that qemu traditional does not have them.
>> The tests were with xl only if I remember good, now I checked also on
old
>> production server with xend and qemu traditional. I confirm that hvm
domUs is
>> without empty floppy and cdrom also in that case.
>>
>> cd-insert works (tested with xl and upstream qemu). cd-insert does not
works
>> only with qemu default empty cdrom because is undefined on xen side.
> So HVM domUs do NOT have a cdrom drive by default with qemu-traditional.
Exact.
>
> Do they have an empty cdrom drive by default with qemu-xen?
Yes
>
> Is the lack of a cdrom drive the reason why cd-insert doesn''t work
by
> default (unless you specify an empty cdrom drive in the VM config file)?
Yes.
xl cd-insert command works with cdrom devices already present on domU 
defined on xl file configuration.
The cdrom can be empty or not, the only exception is the empty cdrom 
added default by qemu that is not usable with cd-insert because not 
defined on xl file configuration.

On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> > > About qemu default empty and unusable floppy and cdrom I have
already
> > > reply at
> > > start of year that qemu traditional does not have them.
> > > The tests were with xl only if I remember good, now I checked
also on old
> > > production server with xend and qemu traditional. I confirm that
hvm domUs
> > > is
> > > without empty floppy and cdrom also in that case.
> > > 
> > > cd-insert works (tested with xl and upstream qemu). cd-insert
does not
> > > works
> > > only with qemu default empty cdrom because is undefined on xen
side.
> > So HVM domUs do NOT have a cdrom drive by default with
qemu-traditional.
> 
> Exact.
> 
> > 
> > Do they have an empty cdrom drive by default with qemu-xen?
> 
> Yes
> 
> > 
> > Is the lack of a cdrom drive the reason why cd-insert doesn''t
work by
> > default (unless you specify an empty cdrom drive in the VM config
file)?
> 
> Yes.
> xl cd-insert command works with cdrom devices already present on domU
defined
> on xl file configuration.
> The cdrom can be empty or not, the only exception is the empty cdrom added
> default by qemu that is not usable with cd-insert because not defined on xl
> file configuration.
I see. That should be fixed, by either removing the empty cdrom drive or
making it work properly with xl cd-insert.
I don''t have a strong opinion on this. Given that qemu-traditional
doesn''t have a cdrom drive by default, it might make sense to do the
same on qemu-xen.

Il 05/09/2013 16:04, Stefano Stabellini ha scritto:
> On Thu, 5 Sep 2013, Fabio Fantoni wrote:
>>>> About qemu default empty and unusable floppy and cdrom I have
already
>>>> reply at
>>>> start of year that qemu traditional does not have them.
>>>> The tests were with xl only if I remember good, now I checked
also on old
>>>> production server with xend and qemu traditional. I confirm
that hvm domUs
>>>> is
>>>> without empty floppy and cdrom also in that case.
>>>>
>>>> cd-insert works (tested with xl and upstream qemu). cd-insert
does not
>>>> works
>>>> only with qemu default empty cdrom because is undefined on xen
side.
>>> So HVM domUs do NOT have a cdrom drive by default with
qemu-traditional.
>> Exact.
>>
>>> Do they have an empty cdrom drive by default with qemu-xen?
>> Yes
>>
>>> Is the lack of a cdrom drive the reason why cd-insert
doesn''t work by
>>> default (unless you specify an empty cdrom drive in the VM config
file)?
>> Yes.
>> xl cd-insert command works with cdrom devices already present on domU
defined
>> on xl file configuration.
>> The cdrom can be empty or not, the only exception is the empty cdrom
added
>> default by qemu that is not usable with cd-insert because not defined
on xl
>> file configuration.
> I see. That should be fixed, by either removing the empty cdrom drive or
> making it work properly with xl cd-insert.
> I don''t have a strong opinion on this. Given that qemu-traditional
> doesn''t have a cdrom drive by default, it might make sense to do
the
> same on qemu-xen.
I think the best choice is to remove the qemu default empty cdrom, if 
possible without another workaround as for floppy but considering to 
change the method hvm domUs starts qemu.
I think that is probably better to add on qemu start command only 
components already defined xen side in order to avoid creation of 
unusable components added by qemu itself or mismatches on both sides.

Another actual problem is that is difficult to know if the qemu binary 
that should be used on xl create has the features/components requested 
and if they are compiled. Actually on xl create we can have only qemu 
log file after domU create failing.
Why not expose all features/components of a given qemu binary and let xl 
or other toolstack (not only xen) query them before start qemu itself?

Thanks for any reply.

On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> Il 05/09/2013 16:04, Stefano Stabellini ha scritto:
> > On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> > > > > About qemu default empty and unusable floppy and cdrom
I have already
> > > > > reply at
> > > > > start of year that qemu traditional does not have them.
> > > > > The tests were with xl only if I remember good, now I
checked also on
> > > > > old
> > > > > production server with xend and qemu traditional. I
confirm that hvm
> > > > > domUs
> > > > > is
> > > > > without empty floppy and cdrom also in that case.
> > > > > 
> > > > > cd-insert works (tested with xl and upstream qemu).
cd-insert does not
> > > > > works
> > > > > only with qemu default empty cdrom because is undefined
on xen side.
> > > > So HVM domUs do NOT have a cdrom drive by default with
qemu-traditional.
> > > Exact.
> > > 
> > > > Do they have an empty cdrom drive by default with qemu-xen?
> > > Yes
> > > 
> > > > Is the lack of a cdrom drive the reason why cd-insert
doesn''t work by
> > > > default (unless you specify an empty cdrom drive in the VM
config file)?
> > > Yes.
> > > xl cd-insert command works with cdrom devices already present on
domU
> > > defined
> > > on xl file configuration.
> > > The cdrom can be empty or not, the only exception is the empty
cdrom added
> > > default by qemu that is not usable with cd-insert because not
defined on
> > > xl
> > > file configuration.
> > I see. That should be fixed, by either removing the empty cdrom drive
or
> > making it work properly with xl cd-insert.
> > I don''t have a strong opinion on this. Given that
qemu-traditional
> > doesn''t have a cdrom drive by default, it might make sense to
do the
> > same on qemu-xen.
> 
> I think the best choice is to remove the qemu default empty cdrom, if
possible
> without another workaround as for floppy but considering to change the
method
> hvm domUs starts qemu.
> I think that is probably better to add on qemu start command only
components
> already defined xen side in order to avoid creation of unusable components
> added by qemu itself or mismatches on both sides.
> 
> Another actual problem is that is difficult to know if the qemu binary that
> should be used on xl create has the features/components requested and if
they
> are compiled. Actually on xl create we can have only qemu log file after
domU
> create failing.
> Why not expose all features/components of a given qemu binary and let xl or
> other toolstack (not only xen) query them before start qemu itself?
You are right, it would be nice to be able to know exactly what the qemu
binary supports. However it''s difficult to do because Linux distros are
free to choose any QEMU version they like and any set of compile time
options they want for qemu-xen.
As a consequence we would actually need to start QEMU and issue QMP
commands to figure out what is supported.  It would slow down VM
creation too much, so we would probably need to do this at host boot
time and store the settings somewhere on disk or on xenstore.

On Thu, Sep 5, 2013 at 12:23 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>> Il 04/09/2013 15:17, Stefano Stabellini ha scritto:
>> > On Wed, 4 Sep 2013, Fabio Fantoni wrote:
>> > > Il 04/07/2013 15:51, Fabio Fantoni ha scritto:
>> > > > Last year I posted a question about default devices of
upstream qemu
>> > > > that
>> > > > differ from qemu traditional, like empty floppy and
cdrom in particular.
>> > > > About empty floppy now is disabled as workaround.
>> > > > About empty cdrom Stabellini tells that is useful, so I
tried to use it
>> > > > but
>> > > > cd-insert was failing,and I must define other empty
cdrom on xl
>> > > > configuration file, for example with:
'',raw,hdb,ro,cdrom''.
>> > > > It seem that there isn''t default devices usable
without define them in
>> > > > xen,
>> > > > and I think that probably need to revise the definition
of the devices
>> > > > to
>> > > > avoid empty and unusable ones and to do everything as
best as possible
>> > > > (also
>> > > > with possibly reviewing qemu side).
>> > > > Another good thing is also consider pv domU case and
possible future
>> > > > support
>> > > > of spice and/or other useful features.
>> > > > Thanks for any reply.
>> > > I seen no replies about this, I think is important improve
upstream qemu
>> > > support and remove the traditional ASA upstream will be
equivalent or
>> > > superior
>> > > in all features.
>> > >
>> > > I also think is good idea add q35 support on xen.
>> > > Seem that hvm domUs have performance limits, in particular on
windows
>> > > domUs
>> > > (also with pv drivers) caused probably by old hardware
emulation by qemu
>> > > and/or xen support limited on some instruction sets.
>> > > I don''t know how to add essential q35 support on
hvmloader to do some
>> > > tests
>> > > and have effective data about improvements.
>> > > Anyone on this?
>> > I agree that this is important and thanks for raising the issue.
>> > It would be nice if somebody stepped up to do the q35 work.
>>
>> Thanks for reply, can you reply also on questions about default devices
with
>> upstream qemu please?
>
> I think it might be a good idea to keep the same set of default devices
> between qemu-traditional and qemu-xen.
>
> We always had an empty cdrom and I don''t see why we should remove
it. If
> cd-insert doesn''t work, it''s a bug and should be fixed.
It sounds similar to the floppy disk thing: if you don''t specifically
tell qemu that you do *not* want a cdrom, it will give you one; but
since xl doesn''t know anything about it, you can''t actually
use it.

It seems like there needs to be a "--no-default-devices" option for
qemu that will say, "No really, only put in what I ask you to put in."
>
> Supporting spice in PV guests would be hard, because spice needs QXL
> that is a PCI device. PV guests don''t have a PCI bus. Of course if
> somebody did the work to make QXL and spice work with PV guests I would
> be happy to accept it.
If I recall correctly, isn''t part of the problem that the PCI access
essentially requires synchronous communication via MMIO accesses?
We''d basically have to add a device model and MMIO handling to PV
guests.  Possible but far from simple.  (Possibly easier for PVH
domains once they come out.)

 -George