From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: Xen's Linux kernel config options Date: Mon, 15 Dec 2014 12:12:29 +0100 Message-ID: <548EC21D.1040701@suse.com> References: <548AEAE7.8020604@suse.com> <548B25FC.6020601@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <548B25FC.6020601@citrix.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: David Vrabel , "xen-devel@lists.xensource.com" , "Ian.Campbell@citrix.com" , Jan Beulich , Konrad Rzeszutek Wilk , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 12/12/2014 06:29 PM, David Vrabel wrote: > On 12/12/14 13:17, Juergen Gross wrote: >> >> >> As a first draft I'd suggest the following: > > Some rough thoughts below. > >> Option Selects Depends >> ---------------------------------------------------------------------- >> XEN SWIOTLB_XEN(arm,arm64) > > XEN should get you basic support for making hypercalls and allowing > guest to identify themselves as running on Xen. I don't think it should > select SWIOTLB_XEN even on ARM as it is only needed for guests with > access to real hardware. Okay. > >> XEN_PV(x86) XEN_HAVE_PVMMU >> PARAVIRT >> PARAVIRT_CLOCK >> XEN_PVH(x86) XEN_PVHVM >> PARAVIRT >> PARAVIRT_CLOCK >> XEN_BACKEND XEN_PV(x86) || >> XEN_PVH(x86) || >> XEN_PVHVM >> XEN_BLKDEV_BACKEND >> XEN_PCIDEV_BACKEND(x86) >> XEN_SCSI_BACKEND >> XEN_NETDEV_BACKEND > [...] >> XEN_PVHVM > > Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK. Okay. > >> XEN_FRONTEND XEN_PV || >> XEN_PVH || >> XEN_PVHVM > > This enables all the basic infrastructure for frontends: event channels, > grant tables and Xenbus. > > Don't make XEN_FRONTEND depend on any XEN_* variant. It should be > possible to have frontend drivers without support for any of the > PV/PVHVM/PVH guest types. Frontends only need event channels, grant > table and xenbus. Okay. > Perhaps have XEN_FRONTEND select XEN instead? Hmm, with XEN not selecting anything else automatically (apart from stuff needed by frontends AND backends) this would be okay, I think. > You need an additional option to enable the Xen platform PCI device. > This should depend on XEN_FRONTEND. Yep. > >> XEN_XENBUS_FRONTEND > > Fold this into XEN_FRONTEND? Hmm, what about Xenstore in an own domain? I'd say XEN_FRONTEND should select XEN_XENBUS_FRONTEND, but XEN_XENBUS_FRONTEND should be available to non-frontend domains as well. > >> XEN_FBDEV_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND >> XEN_BLKDEV_FRONTEND XEN_XENBUS_FRONTEND >> HVC_XEN_FRONTEND XEN_XENBUS_FRONTEND >> HVC_XEN >> TCG_XEN XEN_XENBUS_FRONTEND >> XEN_PCIDEV_FRONTEND PCI_XEN >> XEN_XENBUS_FRONTEND >> XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND >> XEN_NETDEV_FRONTEND XEN_XENBUS_FRONTEND >> >> There might be some further adjustments needed (should XEN_DEV_EVTCHN >> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The >> main difference to the current status is the XEN setting no longer >> controlling all other options. > > XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for > interdomain comms). Okay. Juergen