Re: Xen's Linux kernel config options

[Juergen Gross <jgross@suse.com>]

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