[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

 


Rackspace

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