On 3 November 2013 20:48, Marcel Apfelbaum wrote:
> The problem appears when a root memory region within an
> address space with size < UINT64_MAX has overlapping children
> with the same size. If the size of the root memory region is UINT64_MAX
> everyting is ok.
>
> Solved the regression by maki
On Sun, Nov 03, 2013 at 09:26:06PM +, Peter Maydell wrote:
> On 3 November 2013 20:48, Marcel Apfelbaum wrote:
> > The problem appears when a root memory region within an
> > address space with size < UINT64_MAX has overlapping children
> > with the same size. If the size of the root memory re
On Mon, 2013-11-04 at 08:18 +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 03, 2013 at 09:26:06PM +, Peter Maydell wrote:
> > On 3 November 2013 20:48, Marcel Apfelbaum wrote:
> > > The problem appears when a root memory region within an
> > > address space with size < UINT64_MAX has overlappi
On Mon, Nov 04, 2013 at 11:33:56AM +0200, Marcel Apfelbaum wrote:
> On Mon, 2013-11-04 at 08:18 +0200, Michael S. Tsirkin wrote:
> > On Sun, Nov 03, 2013 at 09:26:06PM +, Peter Maydell wrote:
> > > On 3 November 2013 20:48, Marcel Apfelbaum wrote:
> > > > The problem appears when a root memory
On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum wrote:
> The commit:
>
> Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
> Author: Marcel Apfelbaum
> Date: Mon Sep 16 11:21:16 2013 +0300
>
> hw/pci: partially handle pci master abort
>
> introduced a regression on make check:
Laszlo poin
On Thu, 2013-11-07 at 12:27 -0800, Jordan Justen wrote:
> On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum wrote:
> > The commit:
> >
> > Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
> > Author: Marcel Apfelbaum
> > Date: Mon Sep 16 11:21:16 2013 +0300
> >
> > hw/pci: partially handle
This is a QEMU bug report, only disguised as an edk2-devel followup.
The problem in a nutshell is that the OVMF binary, placed into pflash
(read-only KVM memslot) used to run in qemu-1.6, but it fails to start
in qemu-1.7. The OVMF reset vector reads as 0xFF bytes.
(Jordan and myself started writ
On Thu, 2013-11-07 at 22:12 +0100, Laszlo Ersek wrote:
> This is a QEMU bug report, only disguised as an edk2-devel followup.
>
> The problem in a nutshell is that the OVMF binary, placed into pflash
> (read-only KVM memslot) used to run in qemu-1.6, but it fails to start
> in qemu-1.7. The OVMF r
Il 07/11/2013 22:24, Marcel Apfelbaum ha scritto:
> Thank you Laszlo for the detailed info!
> I think the problem is right above. Why pci-hole and system.flash collide?
> IMHO we should not play with priorities here, better solve the collision.
We need to audit all the other boards that support PC
On 11/07/13 22:24, Marcel Apfelbaum wrote:
> On Thu, 2013-11-07 at 22:12 +0100, Laszlo Ersek wrote:
>> adding subregion 'pci-hole' to region 'system' at offset 6000
>> warning: subregion collision 6000/a000 (pci-hole) vs
>> ffe0/20 (system.flash)
> Thank you Laszlo for the
On 7 November 2013 21:38, Marcel Apfelbaum wrote:
> Thanks Paolo,
> Let me just point out what I know (or I think I know):
> 1. Not all architectures have the behavior: "Address space that is not
> RAM(and friends) is for sure PCI".
>Only x86 behaves like this (I think).
More specifically, t
On Thu, 2013-11-07 at 21:51 +, Peter Maydell wrote:
> On 7 November 2013 21:38, Marcel Apfelbaum wrote:
> > Thanks Paolo,
> > Let me just point out what I know (or I think I know):
> > 1. Not all architectures have the behavior: "Address space that is not
> > RAM(and friends) is for sure PCI"
On Thu, 2013-11-07 at 22:48 +0100, Laszlo Ersek wrote:
> On 11/07/13 22:24, Marcel Apfelbaum wrote:
> > On Thu, 2013-11-07 at 22:12 +0100, Laszlo Ersek wrote:
>
> >> adding subregion 'pci-hole' to region 'system' at offset 6000
> >> warning: subregion collision 6000/a000 (pci-hole)
On Thu, 2013-11-07 at 22:31 +0100, Paolo Bonzini wrote:
> Il 07/11/2013 22:24, Marcel Apfelbaum ha scritto:
> > Thank you Laszlo for the detailed info!
> > I think the problem is right above. Why pci-hole and system.flash collide?
> > IMHO we should not play with priorities here, better solve the c
Il 07/11/2013 22:51, Peter Maydell ha scritto:
>> > 1. Not all architectures have the behavior: "Address space that is not
>> > RAM(and friends)
>> > is for sure PCI". Only x86 behaves like this (I think).
>
> More specifically, the x86 pc behaves like this. Other
> x86 based systems could in
On 8 November 2013 08:05, Paolo Bonzini wrote:
> Il 07/11/2013 22:51, Peter Maydell ha scritto:
>>> > 1. Not all architectures have the behavior: "Address space that is not
>>> > RAM(and friends)
>>> > is for sure PCI". Only x86 behaves like this (I think).
>>
>> More specifically, the x86 pc
Il 08/11/2013 11:44, Peter Maydell ha scritto:
> On 8 November 2013 08:05, Paolo Bonzini wrote:
>> Il 07/11/2013 22:51, Peter Maydell ha scritto:
> 1. Not all architectures have the behavior: "Address space that is not
> RAM(and friends)
> is for sure PCI". Only x86 behaves like t
On Fri, 2013-11-08 at 09:05 +0100, Paolo Bonzini wrote:
> Il 07/11/2013 22:51, Peter Maydell ha scritto:
> >> > 1. Not all architectures have the behavior: "Address space that is not
> >> > RAM(and friends)
> >> > is for sure PCI". Only x86 behaves like this (I think).
> >
> > More specifical
On Fri, 2013-11-08 at 10:44 +, Peter Maydell wrote:
> On 8 November 2013 08:05, Paolo Bonzini wrote:
> > Il 07/11/2013 22:51, Peter Maydell ha scritto:
> >>> > 1. Not all architectures have the behavior: "Address space that is not
> >>> > RAM(and friends)
> >>> > is for sure PCI". Only x8
Am 07.11.2013 21:27, schrieb Jordan Justen:
> On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum wrote:
>> The commit:
>>
>> Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
>> Author: Marcel Apfelbaum
>> Date: Mon Sep 16 11:21:16 2013 +0300
>>
>> hw/pci: partially handle pci master abort
>>
Il 08/11/2013 16:08, Marcel Apfelbaum ha scritto:
> Actually, as I see, the default behavior of "system" memory region
> is to use unassigned_mem_ops that has valid.accepts method returning
> false (no read/write methods). I don't see that read all-ones/ignore
> writes is implemented.
Right, it's
On 11/08/13 16:42, Andreas Färber wrote:
> Am 07.11.2013 21:27, schrieb Jordan Justen:
>> On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum
>> wrote:
>>> The commit:
>>>
>>> Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
>>> Author: Marcel Apfelbaum
>>> Date: Mon Sep 16 11:21:16 2013 +0300
>
On Fri, 2013-11-08 at 17:12 +0100, Paolo Bonzini wrote:
> Il 08/11/2013 16:08, Marcel Apfelbaum ha scritto:
> > Actually, as I see, the default behavior of "system" memory region
> > is to use unassigned_mem_ops that has valid.accepts method returning
> > false (no read/write methods). I don't see
Il 08/11/2013 17:19, Laszlo Ersek ha scritto:
> I'm not very familiar with external files in tests though. Can I model
> it on "qdict-test-data.txt"?
>
> "qdict-test-data.txt" is located in the root source directory. When
> configure runs outside the root source directory (= separate build dir),
>
Am 08.11.2013 17:19, schrieb Laszlo Ersek:
> On 11/08/13 16:42, Andreas Färber wrote:
>> Jordan or Laszlo,
>>
>> Can either of you please add a small test case to i440fx-test using
>> -pflash and doing a read in the PCI hole (or wherever exactly) so that
>> we can avoid regressing yet again? :)
>
Il 08/11/2013 18:09, Andreas Färber ha scritto:
> I don't have personal experience with using external files there yet,
> but I was hoping that using -pflash pc-bios/bios.bin would just work
> since that'll be symlinked for execution from build directory iiuc.
>
> My thinking was the test could th
On 11/08/13 18:15, Paolo Bonzini wrote:
> Il 08/11/2013 18:09, Andreas Färber ha scritto:
>> I don't have personal experience with using external files there yet,
>> but I was hoping that using -pflash pc-bios/bios.bin would just work
>> since that'll be symlinked for execution from build directory
27 matches
Mail list logo
