Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission before xc_domain_irq_permission

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.12.14 at 11:55, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Tue, 2 Dec 2014, Jan Beulich wrote:
>> >>> On 01.12.14 at 20:22, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > xc_physdev_unmap_pirq might revoke the permission to map the irq from
>> > the domain causing the following xc_domain_irq_permission call to fail
>> > and return error (domain_pirq_to_irq returns 0).
>> 
>> Apart from the patch title being rather confusing, isn't the root
>> problem then xc_physdev_unmap_pirq() removes permissions? At
>> least after the strict splitting of permission granting and mapping for
>> MMIO (commit 0561e1f0) it would seem that if the underlying
>> hypercall here behaves similarly to the original behavior there, it
>> ought to be fixed in an analogous way.
> 
> The big difference is that 0561e1f0 makes XEN_DOMCTL_memory_mapping
> stricker, while you are suggesting to make xc_physdev_unmap_pirq laxer.
> 
> Are you sure that is a good idea? What if a third party caller of
> xc_physdev_unmap_pirq relies on that behaviour?

Yes, I think this would be correct. We expect tool stacks to be in
sync with the hypervisor. That said, I'm not sure it would actually
work, since if we did that change, the implicit access granting in
the map operation would also need to be dropped. Yet the map
operation is a prerequisite for XEN_DOMCTL_irq_permission to work
at all right now, as it needs to look up the pIRQ->IRQ translation
(which looks wrong to me now anyway, as it makes little sense for
the same pIRQ to be associated with the same IRQ in two different
domains, i.e. I think the pirq_{permit,deny}_access() calls there
really need to be irq_{permit,deny}_access(), handed the IRQ
translated from the passed in pIRQ).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel