|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4.1 3/4] x86/pt: enable binding of GSIs to a PVH Dom0
>>> On 19.06.17 at 18:45, <roger.pau@xxxxxxxxxx> wrote:
> On Wed, Jun 07, 2017 at 07:17:16AM -0600, Jan Beulich wrote:
>> >>> On 02.06.17 at 15:58, <roger.pau@xxxxxxxxxx> wrote:
>> > + else
>> > + {
>> > + /* MSI_TRANSLATE is not supported by the hardware domain. */
>>
>> s/by/for/ ?
>
> OK. I guess this is better because d is a target in this context?
Yes (as long as my understanding of English prepositions is
correct, which admittedly it often isn't).
>> > @@ -696,7 +777,8 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq
>> > *pirq)
>> > struct hvm_irq_dpci *dpci = domain_get_irq_dpci(d);
>> > struct hvm_pirq_dpci *pirq_dpci = pirq_dpci(pirq);
>> >
>> > - if ( !iommu_enabled || !dpci || !pirq_dpci ||
>> > + if ( !is_hvm_domain(d) || !iommu_enabled ||
>> > + (!is_hardware_domain(d) && !dpci) || !pirq_dpci ||
>> > !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
>> > return 0;
>>
>> So why again do we suddenly need !is_hvm_domain() here? With
>> the name of the function there shouldn't be any caller invoking it
>> for a PV guest.
>
> Sadly there is, in __do_IRQ_guest the following is used:
>
> if ( !hvm_do_IRQ_dpci(d, pirq) )
> send_guest_pirq(d, pirq);
>
> Without checking if d is a HVM or PV guest, so the check is needed (or
> needs to be moved further up in the call chain into __do_IRQ_guest).
Indeed I think callers of hvm_*() functions should make sure they
don't call them on non-HVM domains/vcpus.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |