On 11/07/2016 11:05 AM, Konrad Rzeszutek Wilk wrote: > On Sun, Nov 06, 2016 at 04:42:42PM -0500, Boris Ostrovsky wrote: >> PVH guests do not have IOAPIC which typically generates an SCI. For >> those guests SCI will be provided as a virtual interrupt. >> >> We also move VIRQ_MCA definition out of xen-mca.h to >> keep all x86-specific VIRQ_ARCH_* in one place. > I somehow assumed that the ACPI MADT would be in the PVH guest so the > SCI would be enumerated in there (the INT_SVC_OVR) along with the magic > way one can figure this out. > > But this implies that VIRQ17 is the SCI one? But how does > that connect to the SCI being at 9 (or 20)? > > I know we don't have the LAPIC in there but going forward we may really > want it. Could you kindly explain how this VIRQ ends transumuting itself > in the MADT value? Or would there be an event(virq)->emulated GSI > to be set? > > Sorry for not following that.
The IRQ is whatever FADT specifies (in libacpi/static_tables.c), the guest shouldn't care. The expectation is that the guest will them bind VIRQ_SCI to that IRQ. So in Linux this will be something like if (xen_pvh_domain()) bind_virq_to_irq(VIRQ_SCI, 0, acpi_gbl_FADT.sci_interrupt, 0); (and then bind_virq_to_irq() is modified to take IRQ number as argument, if available). > > Also you may want to expand the PVH markdown as well to document how the > CPU hotplug mechanism will work (or where you thinking to do that once > you get feedback on this, in which case pls ignore me). I'll add a comment there. -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel