[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen's Linux kernel config options



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.