Re: [Xen-devel] [PATCH] arch/x86/hvm: Bind xen-created event channels to building domain

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 01/09/2013 09:56 AM, Ian Campbell wrote:
> On Wed, 2013-01-09 at 14:43 +0000, Daniel De Graaf wrote:
>> On 01/09/2013 06:12 AM, Ian Campbell wrote:
>>> On Thu, 2013-01-03 at 18:28 +0000, Daniel De Graaf wrote:
>>>> Instead of using a hardcoded domain 0 as the endpoint for the event
>>>> channels created in hvm_vcpu_initialise, use the domain ID of the
>>>> building domain so that a domain builder in a domain other than dom0 has
>>>> the expected access to the event channels.
>>>
>>> OOI what is the builder (I assume it's not specific to being a separate
>>> domain) doing that requires it to access to the IOEMU event channels?
>>>
>>> Ian.
>>>
>>
>> I believe this caused problems when the device model was running in the 
>> same domain as the domain builder (where that was not dom0), not during
>> the domain build process.
> 
> I thought the DM set HVM_PARAM_DM_DOMAIN itself?

It does, but only qemu-xen-traditional and only inside a stubdom due to:
#ifdef CONFIG_STUBDOM /* the hvmop is not supported on older hypervisors */
    xc_set_hvm_param(xc_handle, domid, HVM_PARAM_DM_DOMAIN, DOMID_SELF);
#endif


I was considering making HVM_PARAM_DM_DOMAIN effectively default to 
DOMID_SELF for the domain builder with the below patch, since the most
logical place to set the parameter in libxl (hvm_build_set_params called
by libxl__build_hvm) is called after vcpus are initialized in
libxl__build_pre, which means the event channels will be assigned to
domain 0 for a short time and then reassigned later.  It looks like
waiting for the device model domain to be started will also be
significantly later in the build process, since it's done in the
callbacks after adding disks.  While this is probably harmless, it just 
seems cleaner to initialize it to the domain ID from the start.

------------------------------------->8---------------------------

arch/x86/hvm: initialize HVM_PARAM_DM_DOMAIN to the building domain

Instead of assuming domain 0 runs the device model unless otherwise set,
initialize the parameter to the domain ID of the building domain.

Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 123a147..a1fb363 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -529,6 +529,7 @@ int hvm_domain_initialise(struct domain *d)
     hvm_init_guest_time(d);
 
     d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN] = 
current->domain->domain_id;
 
     hvm_init_cacheattr_region_list(d);
 
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 6b05f61..6348ab0 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -92,7 +92,7 @@
 /* Identity-map page directory used by Intel EPT when CR0.PG=0. */
 #define HVM_PARAM_IDENT_PT     12
 
-/* Device Model domain, defaults to 0. */
+/* Device Model domain, defaults to the building domain. */
 #define HVM_PARAM_DM_DOMAIN    13
 
 /* ACPI S state: currently support S0 and S3 on x86. */


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel