From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: PVHVM drivers in upstream linux kernel Date: Tue, 2 Dec 2014 11:59:26 +0000 Message-ID: <547DA99E.5080001@citrix.com> References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com> <1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <547DA392.90701@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 02/12/14 11:33, Juergen Gross wrote: > > I think we have customers wanting to run a default kernel as domU. So it > isn't always the distro refusing paravirt, it might be the user... I don't think this is a sensible use case but I'm not adverse to improving the set of Xen config options. > To sort things out I'd suggest to: > - make XEN independent from PARAVIRT > - let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN > - let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build > a driver domain without XEN_DOM0) > - introduce XEN_FRONTEND, let it select XEN > - let frontend drivers and drivers needed by those depend on > XEN_FRONTEND > - let XEN_PVHVM select XEN_FRONTEND Rather than looking at the current set of configuration options, can you look at what user-visible functionality or use cases need to be covered by a (potentially new) set of configuration options? > - don't skip drivers/xen on make, as XEN might be selected via a > config item in that directory I don't think this matters. David