On Mon, 2 Mar 2015, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 02, 2015 at 02:38:50PM +0000, David Vrabel wrote:
> > On 02/03/15 14:25, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Mar 02, 2015 at 10:47:12AM +0000, David Vrabel wrote:
> > >> On 27/02/15 21:24, Konrad Rzeszutek Wilk wrote:
> > >>> This has been in queue for some time.
> > >>>
> > >>> In our kernels (UEK3) we had to revert said patch. The patch says:
> > >>>
> > >>> " xen/fb: allow xenfb initialization for hvm guests
> > >>>
> > >>> There is no reasons why an HVM guest shouldn't be allowed to use
> > >>> xenfb.
> > >>> As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
> > >>> Given that no Xen toolstacks configure a xenfb backend for x86 HVM
> > >>> guests, they are not affected.
> > >>>
> > >>> Please note that at this time QEMU needs few outstanding fixes to
> > >>> provide xenfb on ARM:
> > >>>
> > >>> http://marc.info/?l=qemu-devel&m=138739419700837&w=2
> > >>> "
> > >>>
> > >>> which is a lie. The "no Xen toolstacks configure a xenfb backend for
> > >>> x86 HVM" is actually a lie. If you try to boot this kernel under
> > >>> Xen with Xend it will be a problem - as Xend does setup an 'vfb'
> > >>> device.
> > >>>
> > >>> The end result is that during the bootup - up until X starts, there is
> > >>> no console output on the VNC window. As the Linux kernel tries to use
> > >>> the vfb console driver.
> > >>
> > >> This looks like a toolstack bug to me. If the toolstack has configured
> > >> a vfb backend surely that should be preferred to the emulated VGA?
> > >
> > > This is Xend. It is a bit brain dead in this category.
> > >
> > >>
> > >>> Any suggestsion on how to fix this? Should we just wrap the
> > >>> whole thing with #ifdef, like this?
> > >>
> > >> No. We want to avoid frontend drivers behaving differently on different
> > >> architectures.
> > >
> > > We could try detecting that it is Xend (not sure how?) - or that it is
> > > Xen 4.4 or below - which would be the only versions that could be run with
> > > Xend.
> >
> > That's even worse. Please just fix your toolstack to not create the vfb
> > backend if you don't want to use it.
>
> That is mighty hard from me looking at the code. Xend treats the 'vfb' as au
> dumping ground for VNC and VFB configurations - and it depends on them when
> an migration is progress.
>
> I am afraid that Xend is still widespread enough that we need some way to
> deal with it.
>
> The #idef hackery - while not a nice way can make this work.
>
> Or we can add this in an header/function as a quirk.
>
> boolean xen_pvfb_dont_init_quirk(void)
> {
> #ifdef CONFIG_X86
I would be OK with having such a quirk without the ifdef (no xend has
been known to work on ARM anyway).
> if (xen_running_on_version_or_later(4, 5) && xen_hvm_domain())
Shouldn't this be xen_running_on_version_or_earlier(4, 4)?
Xend has been removed in 4.5.
> {
> /* Do some XenStore keys to check if we might be running
> a brain dead Xend. */
>
> if (xen_keys_blah_blah(''))..
> return true;
> }
> #else
> return false;
> #endif
> }
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
