Hi,
On 04/05/2023 09:21, Jan Beulich wrote:
On 04.05.2023 10:13, Roger Pau Monné wrote:
On Thu, May 04, 2023 at 09:50:27AM +0200, Jan Beulich wrote:
On 04.05.2023 09:44, Roger Pau Monné wrote:
On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -438,12 +438,14 @@ struct domain
struct grant_table *grant_table;
+#ifdef CONFIG_HAS_PIRQ
/*
* Interrupt to event-channel mappings and other per-guest-pirq data.
* Protected by the domain's event-channel spinlock.
*/
struct radix_tree_root pirq_tree;
unsigned int nr_pirqs;
+#endif
Won't it be cleaner to just move this into arch_domain and avoid a
bunch of the ifdefary? As the initialization of the fields would be
moved to arch_domain_create() also.
That's hard to decide without knowing what e.g. RISC-V is going to
want. Taking (past) IA-64 into consideration - that would likely
have wanted to select this new HAS_PIRQ, and hence keeping these
pieces where they are imo makes sense.
I'm kind of confused, what does Arm do here? AFAICT the pirq_tree is
used by both PV and HVM guests in order to store the native interrupt
-> guest interrupt translation, doesn't Arm also need something
similar?
According to [1] they don't, hence the (new in v2) change here. Aiui
they simply map IRQ to pIRQ 1:1.
The vGIC is able to cope with vIRQ != pIRQ. But so far, we only allow a
domain to map 1:1.
For that we are storing the pIRQ to vIRQ mapping in the IRQ desc and
have a pointer to the desc in the vIRQ information.
So no need to a PIRQ tree on the Arm side.
Cheers,
--
Julien Grall
