>>> On 17.08.18 at 12:32, <roger....@citrix.com> wrote:
> On Fri, Aug 17, 2018 at 04:04:34AM -0600, Jan Beulich wrote:
>> >>> On 14.08.18 at 15:43, <roger....@citrix.com> 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?
Oh, you're right - I was under the wrong impression that the function
would be called for both Dom0 and hwdom in this case (and would act
identically, on the assumption that Dom0 is going to go away soon
anyway). As a result
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
