A few XML modeling questions

[Jim Fehlig]

Hi All,

I've been struggling a bit deciding how to model Xen's max_event_channels and 
e820_host xl.cfg(5) settings. For max_event_channels the man page says:

  Limit the guest to using at most N event channels (PV interrupts). Guests
  use hypervisor resources for each event channel they use.

  The default of 1023 should be sufficient for typical guests. The maximum
  value depends on what the guest supports. Guests supporting the FIFO-based
  event channel ABI support up to 131,071 event channels. Other guests are
  limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit x86).

So event channels are PV interrupts that are used by PV devices and timers, and 
as inter-processor interrupts. My initial thought was to add a maxEventChannels 
attribute to the xenbus controller, similar maxGrantFrames. The latter was added 
to allow specifying the max shared pages a guest could use, which in conjunction 
with event channels provides data transfer mechanism between front and backends 
for PV drivers. My only hesitation is that event channels are also used for 
inter-processor interrupts, which is a bit outside the notion of a virtual 
controller for Xen PV devices. However, the first sentence in the xenbus wiki 
[1] states:

  In practice, the bus is used for configuration negotiation, leaving most
  data transfer to be done via an interdomain channel composed of a shared
  page and an event channel.

So perhaps it is tolerable to consider max_event_channels an attribute of xenbus 
that is specified at domain creation, to then be used by the guest however it 
pleases up to the max value?

e820_host is a bit trickier. For this setting, which is PV-specific, the man 
page says:

  Selects whether to expose the host e820 (memory map) to the guest via the
  virtual e820. When this option is false (0) the guest pseudo-physical
  address space consists of a single contiguous RAM region. When this option
  is specified the virtual e820 instead reflects the host e820 and contains
  the same PCI holes. The total amount of RAM represented by the memory map
  is always the same, this option configures only how it is laid out.

  Exposing the host e820 to the guest gives the guest kernel the opportunity
  to set aside the required part of its pseudo-physical address space in order
  to provide address space to map passedthrough PCI devices. It is guest
  Operating System dependent whether this option is required, specifically it
  is required when using a mainline Linux ("pvops") kernel. This option
  defaults to true (1) if any PCI passthrough devices are configured and
  false (0) otherwise. If you do not configure any passthrough devices at
  domain creation time but expect to hotplug devices later then you should
  set this option. Conversely if your particular guest kernel does not
  require this behavior then it is safe to allow this to be enabled but
  you may wish to disable it anyway.

I'm tempted to unconditionally enable this setting. It is required for pvops 
kernels and apparently harmless for other PV kernels. I asked one of the Xen 
devs about any downsides to always enabling e820_host, to which he replied 
"Scattered memory blocks inside the guest, possibly leading to slightly higher 
overhead. But nothing really severe afaics.".

If there is a strong desire to model this setting it might best be placed under 
hypervisor features, e.g.

   <features>
     <xen>
       <hoste820 state='on'/>
     </xen>
   </features>

Opinions and/or comments are much appreciated.

Regards,
Jim

[1] https://wiki.xen.org/wiki/XenBus