Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Konrad Rzeszutek Wilk]

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.

Any suggestsion on how to fix this? Should we just wrap the
whole thing with #ifdef, like this?

diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..584be8e 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -696,7 +696,10 @@ static int __init xenfb_init(void)
 {
 	if (!xen_domain())
 		return -ENODEV;
-
+#ifdef CONFIG_X86
+	if (!xen_pv_domain())
+		return -ENODEV;
+#endif
 	/* Nothing to do if running in dom0. */
 	if (xen_initial_domain())
 		return -ENODEV;

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Stefano Stabellini]

On Fri, 27 Feb 2015, 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.
> 
> Any suggestsion on how to fix this? Should we just wrap the
> whole thing with #ifdef, like this?

Is vfb properly setup by Xend? Does the console show on the vfb framebuffer?

If the vfb console works but is undesirable because the user expects the
output on the main vnc window (the vga framebuffer), then could we find
a way to prioritize the vga console over vfb on x86?

If the vfb console doesn't work, for example because the backend is not
running, then maybe we could find a way in Linux to avoid vfb if it is
not actually "connected".


> diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
> index 09dc447..584be8e 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -696,7 +696,10 @@ static int __init xenfb_init(void)
>  {
>  	if (!xen_domain())
>  		return -ENODEV;
> -
> +#ifdef CONFIG_X86
> +	if (!xen_pv_domain())
> +		return -ENODEV;
> +#endif
>  	/* Nothing to do if running in dom0. */
>  	if (xen_initial_domain())
>  		return -ENODEV;
> 

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Konrad Rzeszutek Wilk]

On Mon, Mar 02, 2015 at 10:03:35AM +0000, Stefano Stabellini wrote:
> On Fri, 27 Feb 2015, 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.
> > 
> > Any suggestsion on how to fix this? Should we just wrap the
> > whole thing with #ifdef, like this?
> 
> Is vfb properly setup by Xend? Does the console show on the vfb framebuffer?

The vfb xenstore keys are. The VFB framebuffer (QEMU) is not - as it
in most cases runs as qemu-traditional which would not set it up.
> 
> If the vfb console works but is undesirable because the user expects the
> output on the main vnc window (the vga framebuffer), then could we find
> a way to prioritize the vga console over vfb on x86?

This is all about Xend and QEMU traditional. Fixing the bug in Xend would
be nice but I don't see anybody accepting the patch as those are
kind of 'dead'.
> 
> If the vfb console doesn't work, for example because the backend is not
> running, then maybe we could find a way in Linux to avoid vfb if it is
> not actually "connected".


That sounds complicated. Especially during early bootup.
> 
> 
> > diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
> > index 09dc447..584be8e 100644
> > --- a/drivers/video/fbdev/xen-fbfront.c
> > +++ b/drivers/video/fbdev/xen-fbfront.c
> > @@ -696,7 +696,10 @@ static int __init xenfb_init(void)
> >  {
> >  	if (!xen_domain())
> >  		return -ENODEV;
> > -
> > +#ifdef CONFIG_X86
> > +	if (!xen_pv_domain())
> > +		return -ENODEV;
> > +#endif
> >  	/* Nothing to do if running in dom0. */
> >  	if (xen_initial_domain())
> >  		return -ENODEV;
> > 

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[David Vrabel]

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?

> 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.

David

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Konrad Rzeszutek Wilk]

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.
> 
> David

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[David Vrabel]

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.

David

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Konrad Rzeszutek Wilk]

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

	if (xen_running_on_version_or_later(4, 5) && xen_hvm_domain())
	{
		/* 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
}


> 
> David

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Stefano Stabellini]

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
> }

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Ian Campbell]

On Tue, 2015-03-03 at 10:44 +0000, Stefano Stabellini wrote:
> 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.

This all sounds pretty gross, but if it is the way folks want to go,
shouldn't it try and determine that it is running on xend somehow
instead of guessing based on version number? 4.4 had xl in it too for
instance...

> 
> 
> > 	{
> > 		/* 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
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Konrad Rzeszutek Wilk]

> > > 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.
> 
> This all sounds pretty gross, but if it is the way folks want to go,
> shouldn't it try and determine that it is running on xend somehow
> instead of guessing based on version number? 4.4 had xl in it too for
> instance...

Right, so the secondary check would be to see if there is something
extra that Xend puts in the XenStore. And it looks to always
put 'protocol' in every device:

xm:
0 = ""
 protocol = "x86_32-abi"
 state = "1"
 backend-id = "0"
 backend = "/local/domain/0/backend/vfb/7/0"

While xl:
vfb = ""
 0 = ""
  backend = "/local/domain/0/backend/vfb/1/0"
  backend-id = "0"
  state = "1"

Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Ian Campbell]

On Tue, 2015-03-03 at 10:20 -0500, Konrad Rzeszutek Wilk wrote:
> > > > 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.
> > 
> > This all sounds pretty gross, but if it is the way folks want to go,
> > shouldn't it try and determine that it is running on xend somehow
> > instead of guessing based on version number? 4.4 had xl in it too for
> > instance...
> 
> Right, so the secondary check would be to see if there is something
> extra that Xend puts in the XenStore. And it looks to always
> put 'protocol' in every device:

protocol is also written by guest kernels, and I wouldn't be surprised
if libxl or other toolstakcs write it on oocasion too. So I'm afraid
that particualr key is not suitable/

> 
> xm:
> 0 = ""
>  protocol = "x86_32-abi"
>  state = "1"
>  backend-id = "0"
>  backend = "/local/domain/0/backend/vfb/7/0"
> 
> While xl:
> vfb = ""
>  0 = ""
>   backend = "/local/domain/0/backend/vfb/1/0"
>   backend-id = "0"
>   state = "1"
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel