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

[Xen-devel] Modifying domain creation interface



Creating a new domain currently is a sequence of hypercalls with many of
those being mandatory and needed in a specific sequence. Its has been
discussed before to build a new interface for domain creation with _all_
the mandatory information passed to the hypervisor in one hypercall.

I'd like to suggest to extend this idea even more: instead of passing
the mandatory data only we could even add some optional data in a
generic way. Instead of extending the binary interface each time a new
configurable parameter is added for domains we could use a text based
interface for that purpose, similar to the boot parameters of the
hypervisor or the kernel. So instead adding e.g. a new flag for
switching the Meltdown mitigation on or off for a specific domain (this
example is the reason I thought of the new interface) to
xen_domctl_createdomain.flags we could pass a string "xpti=off" to the
hypervisor in the domain create hypercall parameters. Passing an array
of strings plus the number of array elements would allow to extend the
interface without having to change any header file.

It would even be possible to have something like:

domain_params=[ "xpti=off", "param_xy=foo" ]

in the xl config file of a domain allowing to specify new parameters
without having to modify xl/libxl. This would allow backports of
security patches which need some per-domain configuration aid (some
SUSE customers already asked for a way to switch Meltdown mitigation
on a per-domain basis in old versions).

Security is a point to be looked at, of course. OTOH it should be quite
easy to use a fuzzer for proving the parser to be secure, as the parser
can be constructed to be testable in user environment (like e.g. the
x86 instruction emulator).

Right now I will add a new binary flag (again for making backports
easier), but I think if we want to modify the domain creation
interface anyway, we should consider doing it in an easy extendable
way. I am targeting Xen 4.12 for that idea in case it is accepted, so
I wanted to start discussion early.

What do you think?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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