|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |