From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Questions about hvm domU default devices with upstream qemu Date: Tue, 10 Sep 2013 11:02:53 +0100 Message-ID: References: <51D57DD6.3040503@m2r.biz> <5226EFB6.6050405@m2r.biz> <5227425F.1020305@m2r.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel , Ian Campbell , "qemu-devel@nongnu.org" , Fabio Fantoni , Stefano Stabellini , Anthony PERARD List-Id: xen-devel@lists.xenproject.org On Thu, Sep 5, 2013 at 12:23 PM, Stefano Stabellini 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