Hi Jan,
On 02/10/2020 07:12, Jan Beulich wrote:
On 01.10.2020 18:21, Julien Grall wrote:
On 30/09/2020 11:16, Jan Beulich wrote:
On 30.09.2020 10:52, Paul Durrant wrote:
Looking again, given that both send_guest_vcpu_virq() and
send_guest_global_virq() (rightly) hold the evtchn lock before
ca
On 01.10.2020 18:21, Julien Grall wrote:
> On 30/09/2020 11:16, Jan Beulich wrote:
>> On 30.09.2020 10:52, Paul Durrant wrote:
>>> Looking again, given that both send_guest_vcpu_virq() and
>>> send_guest_global_virq() (rightly) hold the evtchn lock before
>>> calling evtchn_port_set_pending() I thi
Hi Jan,
On 30/09/2020 11:16, Jan Beulich wrote:
On 30.09.2020 10:52, Paul Durrant wrote:
Looking again, given that both send_guest_vcpu_virq() and
send_guest_global_virq() (rightly) hold the evtchn lock before
calling evtchn_port_set_pending() I think you could do away with
the virq lock by add
On 30.09.2020 10:52, Paul Durrant wrote:
> Looking again, given that both send_guest_vcpu_virq() and
> send_guest_global_virq() (rightly) hold the evtchn lock before
> calling evtchn_port_set_pending() I think you could do away with
> the virq lock by adding checks in those functions to verify
> ev
Hi Jan,
On 30/09/2020 07:26, Jan Beulich wrote:
On 29.09.2020 19:18, Julien Grall wrote:
On 29/09/2020 14:37, Jan Beulich wrote:
On 29.09.2020 15:03, Julien Grall wrote:
I am thinking that it may be easier to hold the write lock when doing
the update.
... perhaps this is indeed better. I ha
iu' ; 'Stefano Stabellini'
> Subject: Re: [PATCH 11/12] evtchn: convert vIRQ lock to an r/w one
>
> On 30.09.2020 09:58, Paul Durrant wrote:
> >> From: Xen-devel On Behalf Of Jan
> >> Beulich
> >> Sent: 28 September 2020 12:02
> >&g
On 30.09.2020 09:58, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 September 2020 12:02
>>
>> @@ -334,6 +334,12 @@ void _spin_unlock_recursive(spinlock_t *
>> }
>> }
>>
>> +void _rw_barrier(rwlock_t *lock)
>> +{
>> +check_barrier(&lock->lock.debug);
>> +
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:02
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [
On 29.09.2020 19:18, Julien Grall wrote:
> On 29/09/2020 14:37, Jan Beulich wrote:
>> On 29.09.2020 15:03, Julien Grall wrote:
>>> I am thinking that it may be easier to hold the write lock when doing
>>> the update.
>>
>> ... perhaps this is indeed better. I have to admit that I never
>> fully und
Hi Jan,
On 29/09/2020 14:37, Jan Beulich wrote:
On 29.09.2020 15:03, Julien Grall wrote:
On 28/09/2020 12:02, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier).
On 29.09.2020 15:03, Julien Grall wrote:
> On 28/09/2020 12:02, Jan Beulich wrote:
>> There's no need to serialize all sending of vIRQ-s; all that's needed
>> is serialization against the closing of the respective event channels
>> (by means of a barrier). To facilitate the conversion, introduce a
Hi Jan,
On 28/09/2020 12:02, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier). To facilitate the conversion, introduce a new
rw_barrier().
Looking at the code b
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier). To facilitate the conversion, introduce a new
rw_barrier().
Signed-off-by: Jan Beulich
--- a/xen/common/domain.c
+++ b/xen/common/d
13 matches
Mail list logo
