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

Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 19 May 2016 10:00
> To: Paul Durrant
> Cc: Suravee.Suthikulpanit@xxxxxxx; George Dunlap; xen-
> devel@xxxxxxxxxxxxx; Keir (Xen.org)
> Subject: RE: [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after
> initialized HVM domain
> 
> >>> On 19.05.16 at 09:52, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> >--- a/xen/arch/x86/domain.c
> >> >+++ b/xen/arch/x86/domain.c
> >> >@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d,
> >> unsigned
> >> >int domcr_flags,
> >> >
> >> >if ( (rc = init_domain_irq_mapping(d)) != 0 )
> >> >goto fail;
> >> >-
> >> >-        if ( (rc = iommu_domain_init(d)) != 0 )
> >> >-            goto fail;
> >> >}
> >> >spin_lock_init(&d->arch.e820_lock);
> >> >
> >> >if ( has_hvm_container_domain(d) )
> >> >{
> >> >if ( (rc = hvm_domain_initialise(d)) != 0 )
> >> >-        {
> >> >-            iommu_domain_destroy(d);
> >> >goto fail;
> >> >-        }
> >> >}
> >>       >else
> >> >/* 64-bit PV guest by default. */
> >> >d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> >> >
> >> >+    if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
> >> >+        goto fail;
> >>
> >> This would in the error case fail to undo what hvm_domain_initialise() did.
> >> There was a fix very recently dealing with a similar issue. There really
> >> shouldn't be anything that can fail after hvm_domain_initialise().
> >
> > Why is that? There are many failure paths within hvm_domain_initialise().
> > What's wrong with calling hvm_domain_destroy() to undo the whole
> thing?
> 
> Well, I simply didn't check whether hvm_domain_destroy() would be
> suitable to be called in that case, but yes, it looks like it would be.
> 
> > (Although I do notice that the io_bitmap would appear to leak in that
> case...
> > but that looks like a bug to me).
> 
> That's a hardware domain only aspect, and failure to construct
> the hardware domain would be fatal to the system anyway.
>

Ok. No problem then.

  Paul

 > Jan


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

 


Rackspace

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