On 02/04/2015 13:45, Mark Cave-Ayland wrote:
> > Yes, it's better to revert for now. Can you submit the patch above, so
> > I include it in 2.4 and keep bisectability?
>
> Sure. Is your current 2.4 branch available on github or anywhere
> similar? That's just so once the patch has been applied,
On 01/04/15 08:55, Paolo Bonzini wrote:
> On 01/04/2015 00:34, Mark Cave-Ayland wrote:
>> On 30/03/15 12:47, Paolo Bonzini wrote:
>>
>>> On 30/03/2015 13:45, Peter Crosthwaite wrote:
Can the address_space_translate_address() length clamp be made
conditional on non-MMIO access as the RC f
On 01/04/2015 00:34, Mark Cave-Ayland wrote:
> On 30/03/15 12:47, Paolo Bonzini wrote:
>
>> On 30/03/2015 13:45, Peter Crosthwaite wrote:
>>> Can the address_space_translate_address() length clamp be made
>>> conditional on non-MMIO access as the RC fix? I submitted
>>> c3c1bb99d1c11978d9ce94d1b
On 30/03/15 12:47, Paolo Bonzini wrote:
> On 30/03/2015 13:45, Peter Crosthwaite wrote:
>> Can the address_space_translate_address() length clamp be made
>> conditional on non-MMIO access as the RC fix? I submitted
>> c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 as I think its the right
>> thing to do
On 30/03/2015 13:45, Peter Crosthwaite wrote:
> Can the address_space_translate_address() length clamp be made
> conditional on non-MMIO access as the RC fix? I submitted
> c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 as I think its the right
> thing to do regardless of memory type, but in reality it
On Mon, Mar 30, 2015 at 8:28 PM, Paolo Bonzini wrote:
>
>
> On 30/03/2015 12:20, Mark Cave-Ayland wrote:
>>> >
>>> > Of course, there's a QEMU regression too and I'm thinking of how to fix
>>> > it.
Can the address_space_translate_address() length clamp be made
conditional on non-MMIO access as
On 30/03/2015 12:20, Mark Cave-Ayland wrote:
>> >
>> > Of course, there's a QEMU regression too and I'm thinking of how to fix it.
> Hmmm that's interesting because the documentation refers to both
> registers being 16-bit: http://wiki.osdev.org/Bochs_VBE_Extensions. And
> indeed the pseudo-code
On 30/03/15 10:51, Paolo Bonzini wrote:
> On 28/03/2015 20:19, Mark Cave-Ayland wrote:
>> On 28/03/15 19:04, BALATON Zoltan wrote:
>>
>>> Hello,
>>>
>>> Commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 (exec: Respect
>>> as_tranlsate_internal length clamp) seems to break vga output with
>>> qemu-sy
On 28/03/2015 20:19, Mark Cave-Ayland wrote:
> On 28/03/15 19:04, BALATON Zoltan wrote:
>
>> Hello,
>>
>> Commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 (exec: Respect
>> as_tranlsate_internal length clamp) seems to break vga output with
>> qemu-system-ppc on x86_64 host. Since this commit, the
On 28/03/15 19:04, BALATON Zoltan wrote:
> Hello,
>
> Commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 (exec: Respect
> as_tranlsate_internal length clamp) seems to break vga output with
> qemu-system-ppc on x86_64 host. Since this commit, the output window
> does not get to the OpenBIOS console b
Hello,
Commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 (exec: Respect
as_tranlsate_internal length clamp) seems to break vga output with
qemu-system-ppc on x86_64 host. Since this commit, the output window does
not get to the OpenBIOS console but stays black. (Easy to reproduce by
just starti
11 matches
Mail list logo
