[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm guest



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> Sent: Wednesday, June 27, 2012 3:29 PM
> To: Ren, Yongjie
> Cc: Stefano Stabellini; xen-devel@xxxxxxxxxxxxx; Ian Jackson; Tim (Xen.org)
> Subject: RE: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> guest
> 
> On Wed, 2012-06-27 at 02:45 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > To: Ian Campbell
> > > Cc: Ren, Yongjie; xen-devel@xxxxxxxxxxxxx; Ian Jackson; Tim (Xen.org);
> > > Stefano Stabellini
> > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a
> hvm
> > > guest
> > >
> > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > >
> > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > So, select a standard VGA card with VBE as the default emulated
> > > graphics device.
> > > >
> > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > switching the default to something more modern seems like a
> > > reasonable
> > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > point.
> > > >
> > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > >
> > > I think it is a good thing.
> > > The only thing to keep in mind is that QEMU upstream is switching to
> > > 16MB of videoram for stdvga. So at some point in the near future
> > > upstream QEMU will stop working correctly with xen 4.2, unless we
> bump
> > > the videoram to 16MB too.
> > >
> > Yes, we should pay attention to this when using upstream QEMU.
> >
> > >
> > > > > It's also a workaround for the following bug.
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > > >
> > > > Do you understand the root cause of that bug?
> > > >
> > I don't understand the root cause.
> >
> > > > It's hard to see how detaching a VF relates to the VGA emulation in
> use.
> > > > Can you explain it? Are you sure you aren't just masking the real issue
> > > > here?
> > >
> > It's strange that detaching a VF may break the graphics display.
> > As it only happens when 'stdvga=0', it might not be a normal usage.
> >
> > > Indeed. We cannot possibly accept the patch on the basis that it looks
> > > like it is masking an unrelated pci-passthrough bug.
> > >
> > I don't want to mask that bug, either. :-)
> > The following sentence is quoted from xl.cfg man page.
> > "If your guest supports VBE 2.0 or later (e.g. Windows XP onwards)
> > then you should enable this (stdvga option)."
> > If we set 'stdvga=1', we will not meet the bug (#1812).
> > I assume many Xen users (including me) are not very familiar with
> 'stdvga' and
> > will leave it as default (it's 0 before my patch).
> > If then, users may meet something *strange* like bug #1812.
> > I don't think it's friendly to end users, so I set the default value
> > of 'stdvga' to '1'.
> 
> There are good reasons which justify setting stdvga=1 by default. But
> anything to do with #1812 is not one of them. It is obviously wrong to
> justify making an unrelated configuration change on the basis that it
> hides a bug by default without first understanding the reasons for the
> bug.
> 
> I certainly hope you are not planning to close #1812 and stop
> investigating it if we change the stdvga default.
> 
Sure, I don't want to close bug #1812. As I'm not familiar with this, 
if someone want to fix it, I'll co-work with him/her about this issue. 
e.g. help to reproduce it or do some testing.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.