>>> On 12.01.15 at 15:54, wrote:
> On Fri, Jan 9, 2015 at 12:10 PM, Jan Beulich wrote:
> On 09.01.15 at 12:45, wrote:
>>> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
>>> On 09.01.15 at 12:18, wrote:
>> > +default:
>> > +xfree(buf);
>>
On Fri, Jan 9, 2015 at 12:10 PM, Jan Beulich wrote:
On 09.01.15 at 12:45, wrote:
>> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
>>> >>> On 09.01.15 at 12:18, wrote:
>>> >> > +default:
>>> >> > +xfree(buf);
>>> >> > +ASSERT(!buf);
>>>
At 12:46 + on 09 Jan (1420804005), Andrew Cooper wrote:
> On 09/01/15 12:10, Jan Beulich wrote:
> On 09.01.15 at 12:45, wrote:
> >> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
> >> On 09.01.15 at 12:18, wrote:
> >> +default:
> >> +xfr
On 09/01/15 12:10, Jan Beulich wrote:
On 09.01.15 at 12:45, wrote:
>> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
>> On 09.01.15 at 12:18, wrote:
>> +default:
>> +xfree(buf);
>> +ASSERT(!buf);
looks dodgy...
>>> I
>>> On 09.01.15 at 12:45, wrote:
> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
>> >>> On 09.01.15 at 12:18, wrote:
>> >> > +default:
>> >> > +xfree(buf);
>> >> > +ASSERT(!buf);
>> >
>> > looks dodgy...
>>
>> In which way? The "default" i
At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
> >>> On 09.01.15 at 12:18, wrote:
> >> > +default:
> >> > +xfree(buf);
> >> > +ASSERT(!buf);
> >
> > looks dodgy...
>
> In which way? The "default" is supposed to be unreachable, and sits
> in
>>> On 09.01.15 at 12:18, wrote:
> At 10:56 + on 09 Jan (1420797418), Andrew Cooper wrote:
>> On 09/01/15 10:27, Jan Beulich wrote:
>> > While the REP MOVS acceleration appears to have helped qemu-traditional
>> > based guests, qemu-upstream (or really the respective video BIOSes)
>> > doesn't
At 10:56 + on 09 Jan (1420797418), Andrew Cooper wrote:
> On 09/01/15 10:27, Jan Beulich wrote:
> > While the REP MOVS acceleration appears to have helped qemu-traditional
> > based guests, qemu-upstream (or really the respective video BIOSes)
> > doesn't appear to benefit from that. Instead th
>>> On 09.01.15 at 11:56, wrote:
> On 09/01/15 10:27, Jan Beulich wrote:
>> While the REP MOVS acceleration appears to have helped qemu-traditional
>> based guests, qemu-upstream (or really the respective video BIOSes)
>> doesn't appear to benefit from that. Instead the acceleration added
>> here
On 09/01/15 10:27, Jan Beulich wrote:
> While the REP MOVS acceleration appears to have helped qemu-traditional
> based guests, qemu-upstream (or really the respective video BIOSes)
> doesn't appear to benefit from that. Instead the acceleration added
> here provides a visible performance improveme
While the REP MOVS acceleration appears to have helped qemu-traditional
based guests, qemu-upstream (or really the respective video BIOSes)
doesn't appear to benefit from that. Instead the acceleration added
here provides a visible performance improvement during very early HVM
guest boot.
Signed-o
11 matches
Mail list logo
