id Woodhouse
> >>> Sent: 11 August 2020 14:25
> >>> To: Paul Durrant ;
> >>> xen-devel@lists.xenproject.org; Roger Pau Monne
> >>>
> >>> Cc: Eslam Elnikety ; Andrew Cooper
> >>> ; Shan Haitao
> >>> ; Jan Beulich
; xen-devel@lists.xenproject.org;
>>> Roger Pau Monne
>>>
>>> Cc: Eslam Elnikety ; Andrew Cooper
>>> ; Shan Haitao
>>> ; Jan Beulich
>>> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist
>>> code
>>>
On Fri, Aug 14, 2020 at 03:13:51PM +0100, David Woodhouse wrote:
> On Thu, 2020-08-13 at 11:45 +0200, Roger Pau Monné wrote:
> > > The loop appears to be there to handle the case where multiple
> > > devices assigned to a domain have MSIs programmed with the same
> > > dest/vector... which seems li
On Thu, 2020-08-13 at 11:45 +0200, Roger Pau Monné wrote:
> > The loop appears to be there to handle the case where multiple
> > devices assigned to a domain have MSIs programmed with the same
> > dest/vector... which seems like an odd thing for a guest to do but I
> > guess it is at liberty to do
t;
> > Cc: Eslam Elnikety ; Andrew Cooper
> > ; Shan Haitao
> > ; Jan Beulich
> > Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist
> > code
> >
> > Resending this straw man patch at Roger's request, to restart discussion
t: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist code
>
> Resending this straw man patch at Roger's request, to restart discussion.
>
> Redux: In order to cope with the relatively rare case of unmaskable
> legacy MSIs, each vlapic EOI takes a domain-global s
Sorry for not replying earlier, wanted to finish something first.
On Tue, Aug 11, 2020 at 02:25:16PM +0100, David Woodhouse wrote:
> Resending this straw man patch at Roger's request, to restart discussion.
>
> Redux: In order to cope with the relatively rare case of unmaskable
> legacy MSIs, eac
Resending this straw man patch at Roger's request, to restart discussion.
Redux: In order to cope with the relatively rare case of unmaskable
legacy MSIs, each vlapic EOI takes a domain-global spinlock just to
iterate over all IRQs and determine that there's actually nothing to
do.
In my testing,
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 05 September 2018 11:45
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Eslam Elnikety ; Andrew Cooper
> ; Shan Haitao ; Jan
> Beulich
> Subject: Re: [Xen-devel] [PA
On Wed, 2018-09-05 at 10:40 +, Paul Durrant wrote:
>
> Actually the neatest approach would be to get information into the
> vlapic code as to whether APIC assist is suitable for the given
> vector so that the code there can selectively enable it, and then Xen
> would know it was safe to avoid
tao ; Jan
> Beulich
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist
> code
>
> > -Original Message-
> > From: David Woodhouse [mailto:dw...@infradead.org]
> > Sent: 05 September 2018 10:40
> > To: Paul Durrant ; xen-
> d
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 05 September 2018 10:40
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Jan Beulich
> ; Eslam Elnikety ; Shan Haitao
>
> Subject: Re: [Xen-devel] [PA
On Wed, 2018-09-05 at 09:36 +, Paul Durrant wrote:
>
> I see. Given that Windows has used APIC assist to circumvent its EOI
> then I wonder whether we can get away with essentially doing the
> same. I.e. for a completed APIC assist found in
> vlapic_has_pending_irq() we simply clear the APIC a
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 04 September 2018 21:31
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Jan Beulich
> ; Eslam Elnikety ; Shan Haitao
>
> Subject: Re: [Xen-devel] [PA
On Mon, 2018-09-03 at 10:12 +, Paul Durrant wrote:
>
> I believe APIC assist is intended for fully synthetic interrupts.
Hm, if by 'fully synthetic interrupts' you mean
vlapic_virtual_intr_delivery_enabled(), then no I think APIC assist
doesn't get used in that case at all.
> Is it definitel
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 25 August 2018 00:38
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Jan Beulich
> ; Eslam Elnikety ; Shan Haitao
>
> Subject: Re: [Xen-devel] [PATCH v2] x
On Thu, 2018-01-18 at 10:10 -0500, Paul Durrant wrote:
> Lastly the previous code did not properly emulate an EOI if a missed EOI
> was discovered in vlapic_has_pending_irq(); it merely cleared the bit in
> the ISR. The new code instead calls vlapic_EOI_set().
Hm, this *halves* my observed perform
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 January 2018 16:21
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2] x86/hvm: re-work viridian APIC assist code
>
> >>> On 18.01.18 at 16:10, wrote:
> > -int
>>> On 18.01.18 at 16:10, wrote:
> -int viridian_complete_apic_assist(struct vcpu *v)
> +bool viridian_apic_assist_completed(struct vcpu *v)
> {
> uint32_t *va = v->arch.hvm_vcpu.viridian.vp_assist.va;
> -int vector;
>
> if ( !va )
> -return 0;
> +return false;
>
It appears there is a case where Windows enables the APIC assist
enlightenment[1] but does not use it. This scenario is perfectly valid
according to the documentation, but causes the state machine in Xen to
become confused leading to a domain_crash() such as the following:
(XEN) d4: VIRIDIAN GUEST
20 matches
Mail list logo
