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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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

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