> -----Original Message----- > From: Christopher Clark [mailto:christopher.w.cl...@gmail.com] > Sent: 04 December 2018 09:03 > To: Julien Grall <julien.gr...@arm.com> > Cc: xen-devel <xen-devel@lists.xenproject.org>; n...@arm.com; Andrew Cooper > <andrew.coop...@citrix.com>; George Dunlap <george.dun...@citrix.com>; Ian > Jackson <ian.jack...@citrix.com>; Jan Beulich <jbeul...@suse.com>; Konrad > Rzeszutek Wilk <konrad.w...@oracle.com>; Stefano Stabellini > <sstabell...@kernel.org>; Tim (Xen.org) <t...@xen.org>; Wei Liu > <wei.l...@citrix.com>; Paul Durrant <paul.durr...@citrix.com>; Rich > Persaud <pers...@gmail.com>; Ross Philipson <ross.philip...@gmail.com>; > eric chanudet <eric.chanu...@gmail.com>; James McKenzie > <vore...@madingley.org>; Jason Andryuk <jandr...@gmail.com>; Daniel Smith > <dpsm...@apertussolutions.com> > Subject: Re: [PATCH 23/25] argo: signal x86 HVM and ARM via VIRQ > > On Sun, Dec 2, 2018 at 11:55 AM Julien Grall <julien.gr...@arm.com> wrote: > > > > Hi, > > > > On 01/12/2018 01:33, Christopher Clark wrote: > > > * x86 PV domains are notified via event channel. > > > > > > PV guests are known to have the event channel software present in the > guest > > > kernel, so it is fine to depend on and use it. > > > > > > * x86 HVM domains and all ARM domains are notified via VIRQ. > > > > > > The intent is to remove the requirement for event channel software to > be > > > installed within these guests in order to use Argo. VIRQ signalling is > also > > > the method that has been in use for the longest period with this > hypercall > > > in both XenClient and OpenXT. > > > > I am a bit confused. vIRQs are based on event channel, so how do you > > remove the requirement on event channel? > > Are VIRQs always delivered via events in all cases? I was under the > impression that was not necessarily so with HVM guests but I haven't > checked and could well be incorrect. > > A bit of context might help with how this multiple-method logic (as > submitted) was arrived at: > > 1) Both XenClient's original version of v4v, and that used in OpenXT, > deliver notifications to guests via VIRQ. > This logic has been performing fine for our uses cases, so there > hasn't really been a push to switch away from it.
I'm not aware of any way to map VIRQs to vectors directly so I think they have to be dealt with as any other event channel. Paul > > 2) The last version of v4v that was submitted to xen-devel for > iteration with the Xen community was intended to use event channels > instead, in response to a request from Jan at the time. Given that > expressed preference, I've added that, plumbing it in through via the > IPI event method exposed in patch #01, and then used in patch #05, of > the submitted series. > > 3) Bromium's uxen uses different logic for delivery of events to > non-PV guests: an edge-triggered, ISA IRQ, along these lines: > > #define ARGO_SIGNAL_ISA_IRQ 8 > hvm_isa_irq_assert(d, ARGO_SIGNAL_ISA_IRQ, NULL); > hvm_isa_irq_deassert(d, ARGO_SIGNAL_ISA_IRQ); > > I'm told that this avoids the need to EOI in the guest, reducing the > VMEXIT load, and using an ISA IRQ avoids some logic in Windows that > requires that a device be detected. I briefly looked into adding this > to Argo, but Linux wasn't immediately happy and I haven't had time to > look into it further given the proximity of the 4.12 release, with > other work still to complete. > > Anyway: since method 3 isn't ready to submit, and if VIRQs don't have > an advantage over using event channels directly wrt. to needing > in-guest support to function, then I can drop this patch (#23) and > simplify the get_config op (#25), which will leave all notifications > being delivered as events. > > Alternatively, if this is about which is the right delivery method for > ARM, with some valid reason to retain use of VIRQ for HVM x86, then > I'm happy to switch ARM over to deliver by the event method rather > than VIRQ if that makes more sense. > > Christopher _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
