Xen devel - Jun 2006 - PATCH (and RFC): new dom0 hypercall: DOM0_DOMAIN_SETUP

Hi,

for IA64, I''d like to create a new dom0 hypercall: DOM0_DOMAIN_SETUP.

The purpose of this hypercall is to do some setup in a new domain: it builds
the firmware (~ BIOS), and creates the mm structures.

This can''t be done a domain creation because memory (and max_mem) is
required.
This can''t be completly done in user space and since the code has to be
executed
for dom0 it is already present in the hypervisor.

Previously this was done during vcpusetcontext.  But this was almost a kuldge
and became difficult to manage when I worked on save & restore feature.

I don''t know wether or not other architectures might be interested in
this hypercall.
In the later case, we may define an arch-dependant content.

Tristan.


# HG changeset patch
# User gingold@virtu10
# Node ID 6838c14692df784c96f8fc28416e1c33b0dca74a
# Parent  67b9f433900069efbbc9b198158ef0639b41e4b6
Add DOM0_DOMAIN_SETUP hypercall.

Signed-off-by: Tristan Gingold <tristan.gingold@bull.net>

diff -r 67b9f4339000 -r 6838c14692df xen/include/public/dom0_ops.h
--- a/xen/include/public/dom0_ops.h	Thu Jun 15 08:47:00 2006 +0200
+++ b/xen/include/public/dom0_ops.h	Thu Jun 15 08:54:15 2006 +0200
@@ -513,6 +513,16 @@ struct dom0_hypercall_init {
 };
 typedef struct dom0_hypercall_init dom0_hypercall_init_t;
 DEFINE_XEN_GUEST_HANDLE(dom0_hypercall_init_t);
+
+#define DOM0_DOMAIN_SETUP   49
+#define DOM0_DOMAIN_SETUP_VMX	(1 << 0)
+typedef struct dom0_domain_setup {
+    domid_t  domain;          /* domain to be affected */
+    unsigned long flags;
+    unsigned long bp;         /* mpaddr of boot param area */
+    unsigned long maxmem;	  /* Highest memory address for MDT.  */
+} dom0_domain_setup_t;
+DEFINE_XEN_GUEST_HANDLE(dom0_domain_setup_t);
 
 struct dom0_op {
     uint32_t cmd;
@@ -555,6 +565,7 @@ struct dom0_op {
         struct dom0_irq_permission    irq_permission;
         struct dom0_iomem_permission  iomem_permission;
         struct dom0_hypercall_init    hypercall_init;
+        struct dom0_domain_setup      domain_setup;
         uint8_t                       pad[128];
     } u;
 };


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Keir,

   Do you have an comments on this new hypercall Tristan is proposing?
We have a patch pending in xen/ia64 that makes use of this new hypercall
as a first step towards domain save/restore.  Thanks,

	Alex

On Thu, 2006-06-15 at 10:19 +0200, Tristan Gingold
wrote:
> Hi,
> 
> for IA64, I''d like to create a new dom0 hypercall:
DOM0_DOMAIN_SETUP.
> 
> The purpose of this hypercall is to do some setup in a new domain: it
builds
> the firmware (~ BIOS), and creates the mm structures.
> 
> This can''t be done a domain creation because memory (and max_mem)
is required.
> This can''t be completly done in user space and since the code has
to be executed
> for dom0 it is already present in the hypervisor.
> 
> Previously this was done during vcpusetcontext.  But this was almost a
kuldge
> and became difficult to manage when I worked on save & restore feature.
> 
> I don''t know wether or not other architectures might be interested
in this hypercall.
> In the later case, we may define an arch-dependant content.
> 
> Tristan.
> 
> 
> # HG changeset patch
> # User gingold@virtu10
> # Node ID 6838c14692df784c96f8fc28416e1c33b0dca74a
> # Parent  67b9f433900069efbbc9b198158ef0639b41e4b6
> Add DOM0_DOMAIN_SETUP hypercall.
> 
> Signed-off-by: Tristan Gingold <tristan.gingold@bull.net>
> 
> diff -r 67b9f4339000 -r 6838c14692df xen/include/public/dom0_ops.h
> --- a/xen/include/public/dom0_ops.h	Thu Jun 15 08:47:00 2006 +0200
> +++ b/xen/include/public/dom0_ops.h	Thu Jun 15 08:54:15 2006 +0200
> @@ -513,6 +513,16 @@ struct dom0_hypercall_init {
>  };
>  typedef struct dom0_hypercall_init dom0_hypercall_init_t;
>  DEFINE_XEN_GUEST_HANDLE(dom0_hypercall_init_t);
> +
> +#define DOM0_DOMAIN_SETUP   49
> +#define DOM0_DOMAIN_SETUP_VMX	(1 << 0)
> +typedef struct dom0_domain_setup {
> +    domid_t  domain;          /* domain to be affected */
> +    unsigned long flags;
> +    unsigned long bp;         /* mpaddr of boot param area */
> +    unsigned long maxmem;	  /* Highest memory address for MDT.  */
> +} dom0_domain_setup_t;
> +DEFINE_XEN_GUEST_HANDLE(dom0_domain_setup_t);
>  
>  struct dom0_op {
>      uint32_t cmd;
> @@ -555,6 +565,7 @@ struct dom0_op {
>          struct dom0_irq_permission    irq_permission;
>          struct dom0_iomem_permission  iomem_permission;
>          struct dom0_hypercall_init    hypercall_init;
> +        struct dom0_domain_setup      domain_setup;
>          uint8_t                       pad[128];
>      } u;
>  };
-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 19 Jun 2006, at 15:22, Alex Williamson wrote:
>    Do you have an comments on this new hypercall Tristan is proposing?
> We have a patch pending in xen/ia64 that makes use of this new 
> hypercall
> as a first step towards domain save/restore.  Thanks,
Yes, we need something like it for proper HVM setup on x86 too. Leaving 
it until VCPU0 setcontext is not good.

I''d like the patch modified as follows:
  * Change flag name to XEN_DOMAINSETUP_hvm_guest (explicitly in Xen 
namespace; more the style of other flags added recently; not VMX 
specific).
  * Place the final two fields of the struct inside ifdef __ia64__.

Resubmit and I''ll apply.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Le Lundi 19 Juin 2006 16:35, Keir Fraser a écrit :
> On 19 Jun 2006, at 15:22, Alex Williamson wrote:
> >    Do you have an comments on this new hypercall Tristan is proposing?
> > We have a patch pending in xen/ia64 that makes use of this new
> > hypercall
> > as a first step towards domain save/restore.  Thanks,
>
> Yes, we need something like it for proper HVM setup on x86 too. Leaving
> it until VCPU0 setcontext is not good.
>
> I''d like the patch modified as follows:
>   * Change flag name to XEN_DOMAINSETUP_hvm_guest (explicitly in Xen
> namespace; more the style of other flags added recently; not VMX
> specific).
>   * Place the final two fields of the struct inside ifdef __ia64__.
Why not defining an arch-dependant struct for adding more fields to this 
structure ?  (I prefer to do that early than breaking compatibility later).

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

On 19 Jun 2006, at 15:43, Tristan Gingold wrote:
>> I''d like the patch modified as follows:
>>   * Change flag name to XEN_DOMAINSETUP_hvm_guest (explicitly in Xen
>> namespace; more the style of other flags added recently; not VMX
>> specific).
>>   * Place the final two fields of the struct inside ifdef __ia64__.
> Why not defining an arch-dependant struct for adding more fields to 
> this
> structure ?  (I prefer to do that early than breaking compatibility 
> later).
How does that ease binary compatibility if you want to add extra common 
fields later? You mean to have a pointer to the arch-dep struct?

  -- Keir

PS. The flag name: DOM0_DOMAIN_SETUP_ would actually be a fine prefix 
for flags. Use whatever you prefer.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Le Lundi 19 Juin 2006 16:45, Keir Fraser a écrit :
> On 19 Jun 2006, at 15:43, Tristan Gingold wrote:
> >> I''d like the patch modified as follows:
> >>   * Change flag name to XEN_DOMAINSETUP_hvm_guest (explicitly in
Xen
> >> namespace; more the style of other flags added recently; not VMX
> >> specific).
> >>   * Place the final two fields of the struct inside ifdef
__ia64__.
> >
> > Why not defining an arch-dependant struct for adding more fields to
> > this
> > structure ?  (I prefer to do that early than breaking compatibility
> > later).
>
> How does that ease binary compatibility if you want to add extra common
> fields later? You mean to have a pointer to the arch-dep struct?
Err, this was a bad argument.  I was thinking about avoiding #if arch /#endif 
in this public header.
> PS. The flag name: DOM0_DOMAIN_SETUP_ would actually be a fine prefix
> for flags. Use whatever you prefer.
Here is the patch.  I hope it looks like you expect it :-)

Tristan.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 19 Jun 2006, at 16:20, Tristan Gingold wrote:
>> How does that ease binary compatibility if you want to add extra 
>> common
>> fields later? You mean to have a pointer to the arch-dep struct?
> Err, this was a bad argument.  I was thinking about avoiding #if arch 
> /#endif
> in this public header.
I''m not too concerned about a few ifdefs here and there in the header 
files. I think sometimes it''s easier just to have all the architectural
cases in one place rather than having to go to separate arch-specific 
header files, even if it is "inelegant".
>> PS. The flag name: DOM0_DOMAIN_SETUP_ would actually be a fine prefix
>> for flags. Use whatever you prefer.
> Here is the patch.  I hope it looks like you expect it :-)
Looks fine.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel