>>> On 16.06.15 at 11:45, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 June 2015 10:30
>> >>> On 16.06.15 at 11:15, wrote:
>> > From my reading, both QEMU upstream and trad are safe. They use a loop
>> of
>> > the form:
>> >
>> > while (read_ptr != write_ptr)
>> > {
>> >
ew Cooper; Wei Liu; Ian Jackson; Stefano Stabellini; xen-devel;
> Keir
> >> (Xen.org); Paul Durrant
> >> Subject: Re: [Xen-devel] [PATCH] x86/HVM: avoid pointer wraparound in
> >> bufioreq handling
> >>
> >> On Tue, 2015-06-16 at 09:37 +0100, Jan Beu
On Tue, 2015-06-16 at 10:34 +0100, Jan Beulich wrote:
> >>> On 16.06.15 at 10:59, wrote:
> > On Tue, 2015-06-16 at 09:37 +0100, Jan Beulich wrote:
> >> >>> On 16.06.15 at 10:20, wrote:
> >> > On Tue, 2015-06-16 at 07:44 +0100, Jan Beulich wrote:
> >> >> >>> On 15.06.15 at 16:30, wrote:
> >> >> >
>>> On 16.06.15 at 10:59, wrote:
> On Tue, 2015-06-16 at 09:37 +0100, Jan Beulich wrote:
>> >>> On 16.06.15 at 10:20, wrote:
>> > On Tue, 2015-06-16 at 07:44 +0100, Jan Beulich wrote:
>> >> >>> On 15.06.15 at 16:30, wrote:
>> >> > The number of slots per page being 511 (i.e. not a power of two)
On 16/06/15 07:40, Jan Beulich wrote:
On 15.06.15 at 17:55, wrote:
>> On 15/06/15 15:30, Jan Beulich wrote:
>>> +/* Canonicalize read/write pointers to prevent their overflow. */
>>> +while ( s->bufioreq_atomic &&
>>> +pg->ptrs.read_pointer >= IOREQ_BUFFER_SLOT_NUM )
>>> +
(Xen.org); Paul Durrant
>> Subject: Re: [Xen-devel] [PATCH] x86/HVM: avoid pointer wraparound in
>> bufioreq handling
>>
>> On Tue, 2015-06-16 at 09:37 +0100, Jan Beulich wrote:
>> > >>> On 16.06.15 at 10:20, wrote:
>> > > On Tue, 2015-06-16 a
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 16 June 2015 10:00
> To: Jan Beulich
> Cc: Andrew Cooper; Wei Liu; Ian Jackson; Stefano Stabellini; xen-devel; Keir
> (Xen.org); Paul Durrant
> Subject: Re: [Xen-devel] [PATCH] x
On Tue, 2015-06-16 at 09:37 +0100, Jan Beulich wrote:
> >>> On 16.06.15 at 10:20, wrote:
> > On Tue, 2015-06-16 at 07:44 +0100, Jan Beulich wrote:
> >> >>> On 15.06.15 at 16:30, wrote:
> >> > The number of slots per page being 511 (i.e. not a power of two) means
> >> > that the (32-bit) read and
>>> On 16.06.15 at 10:20, wrote:
> On Tue, 2015-06-16 at 07:44 +0100, Jan Beulich wrote:
>> >>> On 15.06.15 at 16:30, wrote:
>> > The number of slots per page being 511 (i.e. not a power of two) means
>> > that the (32-bit) read and write indexes going beyond 2^32 will likely
>> > disturb operati
On Tue, 2015-06-16 at 07:44 +0100, Jan Beulich wrote:
> >>> On 15.06.15 at 16:30, wrote:
> > The number of slots per page being 511 (i.e. not a power of two) means
> > that the (32-bit) read and write indexes going beyond 2^32 will likely
> > disturb operation. Extend I/O req server creation so th
>>> On 15.06.15 at 16:30, wrote:
> The number of slots per page being 511 (i.e. not a power of two) means
> that the (32-bit) read and write indexes going beyond 2^32 will likely
> disturb operation. Extend I/O req server creation so the caller can
> indicate that it is using suitable atomic acces
>>> On 15.06.15 at 17:55, wrote:
> On 15/06/15 15:30, Jan Beulich wrote:
>> +/* Canonicalize read/write pointers to prevent their overflow. */
>> +while ( s->bufioreq_atomic &&
>> +pg->ptrs.read_pointer >= IOREQ_BUFFER_SLOT_NUM )
>> +{
>> +union bufioreq_pointers ol
On 15/06/15 15:30, Jan Beulich wrote:
> The number of slots per page being 511 (i.e. not a power of two) means
> that the (32-bit) read and write indexes going beyond 2^32 will likely
> disturb operation. Extend I/O req server creation so the caller can
> indicate that it is using suitable atomic a
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. Extend I/O req server creation so the caller can
indicate that it is using suitable atomic accesses where needed (not
all accesses to the
14 matches
Mail list logo
