|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [XEN][RFC PATCH 12/15] xl: Add interface to handle multiple device models
On Thu, 2012-03-22 at 15:59 +0000, Julien Grall wrote:
> This patch add a structure with contain all informations about
> a device model.
>
> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> ---
> tools/libxl/libxl.h | 4 ++--
> tools/libxl/libxl_internal.h | 1 +
> tools/libxl/libxl_types.idl | 11 +++++++++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b69030..a347a34 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -357,9 +357,9 @@ typedef struct {
> typedef struct {
> libxl_domain_create_info c_info;
> libxl_domain_build_info b_info;
> -
> int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
> -
> + int num_dms;
> + libxl_dm *dms;
> libxl_device_disk *disks;
> libxl_device_nic *vifs;
> libxl_device_pci *pcidevs;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e0a1070..247bdb9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -767,6 +767,7 @@ typedef struct {
> char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid
> */
> const char *pid_path; /* only for libxl_spawner_record_pid */
> int domid;
> + uint32_t dmid;
> libxl__spawn_starting *for_spawn;
> } libxl__spawner_starting;
>
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 413a1a6..7e48817 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -37,6 +37,7 @@ libxl_domain_type = Enumeration("domain_type", [
> libxl_device_model_version = Enumeration("device_model_version", [
> (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
> (2, "QEMU_XEN"), # Upstream based qemu-xen device model
> + (3, "MULTIPLE_QEMU_XEN"), # Handle multiple dm
Isn't this implicit in the provision or otherwise of num_dms?
> ])
>
> libxl_console_type = Enumeration("console_type", [
> @@ -224,6 +225,15 @@ libxl_domain_create_info = Struct("domain_create_info",[
>
> MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
>
> +libxl_dm = Struct("dm", [
> + ("id", uint32),
> + ("name", string),
> + ("path", string),
> + ("pcis", libxl_string_list),
> + ("mmios", libxl_string_list),
> + ("pios", libxl_string_list),
> + ])
Why does the user of libxl need to know the id? can't that be internal
to the library?
What are name and path? I guess path is something to do with xenstore
but isn't that also internal to the libxl<->dm interface not something
the caller of libxl need be aware of?
I'm not sure what syntax "pcis", "mmios" and "pios" are going to have
but I expect that this would be better represent as actual
datastructures rather than encoding it as a string.
How are toolstack supposed to know the values for e.g. pcis?
All in all this seems like a very raw/low-level interface. Can libxl not
expose something a bit more meaningful to toolstack authors? For example
if we consider emulated disk controllers then perhaps the options are
* Handled by the "primary" dm
* Handled by a single disaggregated dm
* Handled by multiple disaggregated dm's (one per disk controller)
Similarly for other classes or emulated device. Or maybe this should be
a flag on those actual devices (e.g. in libxl_device_FOO)?
> +
> # Instances of libxl_file_reference contained in this struct which
> # have been mapped (with libxl_file_reference_map) will be unmapped
> # by libxl_domain_build/restore. If either of these are never called
> @@ -289,6 +299,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> ("usbdevice", string),
> ("soundhw", string),
> ("xen_platform_pci", libxl_defbool),
> + ("max_servers", integer),
As a toolstack author how do I decide what number to use here?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |