From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Xen's Linux kernel config options Date: Fri, 12 Dec 2014 17:29:32 +0000 Message-ID: <548B25FC.6020601@citrix.com> References: <548AEAE7.8020604@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <548AEAE7.8020604@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 , "xen-devel@lists.xensource.com" , David Vrabel , "Ian.Campbell@citrix.com" , Jan Beulich , Konrad Rzeszutek Wilk , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org 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. > 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. > 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. Perhaps have XEN_FRONTEND select XEN instead? You need an additional option to enable the Xen platform PCI device. This should depend on XEN_FRONTEND. > XEN_XENBUS_FRONTEND Fold this into XEN_FRONTEND? > 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). David