Re: [Xen-devel] Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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



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