xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <dunlapg@umich.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: Questions about hvm domU default devices with upstream qemu
Date: Tue, 10 Sep 2013 11:02:53 +0100	[thread overview]
Message-ID: <CAFLBxZbOjG5skoFnz8sZZJLHtTkoAX2ftCDHkA_oT91X6_hAvg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309051216530.6397@kaball.uk.xensource.com>

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

      parent reply	other threads:[~2013-09-10 10:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 13:51 Questions about hvm domU default devices with upstream qemu Fabio Fantoni
2013-09-04  8:30 ` Fabio Fantoni
2013-09-04 13:17   ` Stefano Stabellini
2013-09-04 14:23     ` Fabio Fantoni
2013-09-05 11:23       ` Stefano Stabellini
2013-09-05 12:21         ` Fabio Fantoni
2013-09-05 13:00           ` Stefano Stabellini
2013-09-05 13:52             ` Fabio Fantoni
2013-09-05 14:04               ` Stefano Stabellini
2013-09-05 15:18                 ` Fabio Fantoni
2013-09-09 11:10                   ` Stefano Stabellini
2013-09-10 10:02         ` George Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFLBxZbOjG5skoFnz8sZZJLHtTkoAX2ftCDHkA_oT91X6_hAvg@mail.gmail.com \
    --to=dunlapg@umich.edu \
    --cc=anthony.perard@citrix.com \
    --cc=fabio.fantoni@m2r.biz \
    --cc=ian.campbell@citrix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).