Re: [Xen-devel] [PATCH 23/25] argo: signal x86 HVM and ARM via VIRQ

[James <james@xxxxxxxxxxx>]

I think there are two issues:

1) VIRQ vs some other sort of event channel

   For PV guests we originally chose a VIRQ in order to have a well known
   number against which the kernel driver could bind, so that it wasn't
   dependent on any of the other interdomain communication systems (such
   as xenstore) to find the correct channel.

   VIRQs and events in general make sense for PV domains since the
   up call mechanism fits well into the way argo expects scheduling to work.

   I dont see any pressing reason to not use a VIRQ for PV or PVH domains,
   perhaps I've missed something.

2) VIRQ vs direct injection of vector in hvm case.

   for HVM guests - you can make the argument for injection via a (potentially
   hardware) emulated LAPIC. In this case the best performance is obtained by
   not having to clear the interrupt (requiring another VMEXIT). The only two
   sorts of interrupts that have that property are 1) MSIs, and 2) edge 
interrupts
   via the IOAPIC:

   Not all operating systems had/have good MSI support, PCI doesn't [really] 
support
   edge interrupts on LNK[ABCD], and even if you go the PCI route almost no 
OSes do
   the right thing anyway. However it is possible to specify a device via ACPI 
with a
   fixed GSI with an edge interrupt. Windows from at least XP, and linux both 
handle
   that well and it's the perfect fit for sending the idempotent "you have work 
to
   do" type interrupt that argo needs.

   One of the design goals was that multiple independent actors in a VM should
   be able to run without knowledge of each other, and using a standard GSI 
allows
   something like an EDK II, grub and linux to all use it without having to hand
   forward state.


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