[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 4/6] xen/x86: Allow stubdom access to irq created for msi.





On 22/07/2019 10:06, Julien Grall wrote:
Hi Roger,

On 22/07/2019 09:45, Roger Pau Monné wrote:
On Sun, Jul 21, 2019 at 07:05:16PM +0100, Julien Grall wrote:
Hi,

On 7/20/19 10:21 PM, Marek Marczykowski-Górecki wrote:
On Sat, Jul 20, 2019 at 05:48:56PM +0100, Julien Grall wrote:
Hi,

Sorry for jumping late in the discussion.

On 7/17/19 2:00 AM, Marek Marczykowski-Górecki wrote:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index 586b783..c7a6a83 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -91,6 +91,7 @@ typedef struct irq_desc {
        spinlock_t lock;
        struct arch_irq_desc arch;
        cpumask_var_t affinity;
+    domid_t creator_domid; /* weak reference to domain handling this IRQ */

This x86 only. Can this be moved in arch_irq_desc to avoid increasing the
structure on Arm?

How (if at all) PCI passthrough is supported on ARM? Is qemu involved?
If so, and if that qemu would be isolated in stubdomain, I think ARM
would need a similar feature. If it not the case right now, but it is
planned, do you think it's worth moving it to arch_irq_desc and possibly
move back later?

PCI passthrough is not yet supported on Arm. However, I would not expect
QEMU to be involved at all for Arm.

In any case, I would still prefer to keep field in arch_irq_desc until we
see any usage on Arm.

I'm fine with putting it inside of the arch struct, but there's
nothing x86 specific about this field.

In theory yes, in practice this is only used by x86 today. I don't want to increase the size of irq_desc for unused field.

We can move because the field in irq_desc if there are a need on Arm.

s/because/later/


Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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