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

Re: [Xen-devel] [PATCH v5 3/8] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu



On Fri, Aug 17, 2018 at 04:04:34AM -0600, Jan Beulich wrote:
> >>> On 14.08.18 at 15:43, <roger.pau@xxxxxxxxxx> wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1304,11 +1304,9 @@ static void __hwdom_init 
> > intel_iommu_hwdom_init(struct domain *d)
> >  {
> >      struct acpi_drhd_unit *drhd;
> >  
> > -    if ( !iommu_hwdom_passthrough && is_pv_domain(d) )
> > -    {
> > -        /* Set up 1:1 page table for hardware domain. */
> > -        vtd_set_hwdom_mapping(d);
> > -    }
> > +    /* Inclusive mappings are enabled by default on Intel hardware for PV. 
> > */
> > +    if ( iommu_hwdom_inclusive == -1 )
> > +        iommu_hwdom_inclusive = is_pv_domain(d);
> 
> Hmm, I didn't notice this before, but there's an issue here for the
> late-hwdom case: What if Dom0 and the actual hardware domain
> differ in their PV-ness? I think you need to keep it at -1 here and
> take the still -1 value into account in arch_iommu_hwdom_init().
> iommu_hwdom_init() then also should not override it.

But isn't the late-hwdom the one that would be passed when calling
intel_iommu_hwdom_init?

Or else how is intel_iommu_hwdom_init going to differentiate between
Dom0 and a late-hwdom if the function is called for both?

Thanks, Roger.

_______________________________________________
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®.