[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |