[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest
> > > 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" _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |