Hi Stefano,
On 06/14/2017 07:15 PM, Stefano Stabellini wrote:
On Wed, 14 Jun 2017, Julien Grall wrote:
In any case, all those macros does not prevent re-ordering at the
processor
level nor read/write atomicity if the variable is misaligned.
My understanding is that the unwritten assumption in
On Wed, 14 Jun 2017, Julien Grall wrote:
> > > > > In any case, all those macros does not prevent re-ordering at the
> > > > > processor
> > > > > level nor read/write atomicity if the variable is misaligned.
> > > >
> > > > My understanding is that the unwritten assumption in Xen is that
> > > >
Hi Stefano,
On 06/14/2017 06:32 PM, Stefano Stabellini wrote:
On Wed, 14 Jun 2017, Julien Grall wrote:
I don't understand your explanation. There are no PV protocols under
xen/, they are implemented in other repositories. I grepped for ACCESS
under xen/include/public, in case you referred to th
On Wed, 14 Jun 2017, Julien Grall wrote:
> On 06/13/2017 11:19 PM, Stefano Stabellini wrote:
> > On Tue, 13 Jun 2017, Julien Grall wrote:
> > > On 12/06/2017 23:34, Stefano Stabellini wrote:
> > > > On Mon, 12 Jun 2017, Julien Grall wrote:
> > > > > Hi Andre,
> > > > >
> > > > > On 09/06/17 18:41,
On 06/14/2017 12:22 PM, Andre Przywara wrote:
As for the readability argument of "ACCESS_ONCE(*ptr) = foo;":
I agree, but was wondering why we don't have Linux' READ_ONCE/WRITE_ONCE
pairs in the first place. I see that the implementation of them is
nicely merged into one macro, but maybe we sho
Hi,
On 14/06/17 09:55, Julien Grall wrote:
>
>
> On 06/13/2017 11:19 PM, Stefano Stabellini wrote:
>> On Tue, 13 Jun 2017, Julien Grall wrote:
>>> On 12/06/2017 23:34, Stefano Stabellini wrote:
On Mon, 12 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 09/06/17 18:41, Andre Prz
On 06/13/2017 11:19 PM, Stefano Stabellini wrote:
On Tue, 13 Jun 2017, Julien Grall wrote:
On 12/06/2017 23:34, Stefano Stabellini wrote:
On Mon, 12 Jun 2017, Julien Grall wrote:
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we w
On Tue, 13 Jun 2017, Julien Grall wrote:
> On 12/06/2017 23:34, Stefano Stabellini wrote:
> > On Mon, 12 Jun 2017, Julien Grall wrote:
> > > Hi Andre,
> > >
> > > On 09/06/17 18:41, Andre Przywara wrote:
> > > > When reading the priority value of a virtual interrupt, we were taking
> > > > the res
On 12/06/2017 23:34, Stefano Stabellini wrote:
On Mon, 12 Jun 2017, Julien Grall wrote:
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so fa
On Mon, 12 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 09/06/17 18:41, Andre Przywara wrote:
> > When reading the priority value of a virtual interrupt, we were taking
> > the respective rank lock so far.
> > However for forwarded interrupts (Dom0 only so far) this may lead to a
> > deadlock
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IR
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IRQ affinity, calling the ITARGETSR handler
- this handl
12 matches
Mail list logo
