[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 23/25] argo: signal x86 HVM and ARM via VIRQ
> -----Original Message----- > From: Christopher Clark [mailto:christopher.w.clark@xxxxxxxxx] > Sent: 04 December 2018 09:03 > To: Julien Grall <Julien.Grall@xxxxxxx> > Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; nd@xxxxxxx; Andrew Cooper > <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>; Ian > Jackson <Ian.Jackson@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Konrad > Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; Stefano Stabellini > <sstabellini@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>; Wei Liu > <wei.liu2@xxxxxxxxxx>; Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Rich > Persaud <persaur@xxxxxxxxx>; Ross Philipson <ross.philipson@xxxxxxxxx>; > eric chanudet <eric.chanudet@xxxxxxxxx>; James McKenzie > <voreekf@xxxxxxxxxxxxx>; Jason Andryuk <jandryuk@xxxxxxxxx>; Daniel Smith > <dpsmith@xxxxxxxxxxxxxxxxxxxx> > 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.Grall@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |