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 theory
On 8 November 2013 08:05, Paolo Bonzini pbonz...@redhat.com 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
Il 08/11/2013 11:44, Peter Maydell ha scritto:
On 8 November 2013 08:05, Paolo Bonzini pbonz...@redhat.com 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
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 specifically, the x86 pc
On Fri, 2013-11-08 at 10:44 +, Peter Maydell wrote:
On 8 November 2013 08:05, Paolo Bonzini pbonz...@redhat.com 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
Am 07.11.2013 21:27, schrieb Jordan Justen:
On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum marce...@redhat.com wrote:
The commit:
Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
Author: Marcel Apfelbaum marce...@redhat.com
Date: Mon Sep 16 11:21:16 2013 +0300
hw/pci: partially
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 marce...@redhat.com
wrote:
The commit:
Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
Author: Marcel Apfelbaum marce...@redhat.com
Date: Mon Sep 16
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 that
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),
it
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? :)
For
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 then
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 iiuc.
On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum marce...@redhat.com wrote:
The commit:
Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
Author: Marcel Apfelbaum marce...@redhat.com
Date: Mon Sep 16 11:21:16 2013 +0300
hw/pci: partially handle pci master abort
introduced a
On Thu, 2013-11-07 at 12:27 -0800, Jordan Justen wrote:
On Sun, Nov 3, 2013 at 12:48 PM, Marcel Apfelbaum marce...@redhat.com wrote:
The commit:
Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
Author: Marcel Apfelbaum marce...@redhat.com
Date: Mon Sep 16 11:21:16 2013 +0300
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
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 reset
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
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 marce...@redhat.com 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
On Thu, 2013-11-07 at 21:51 +, Peter Maydell wrote:
On 7 November 2013 21:38, Marcel Apfelbaum marce...@redhat.com 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
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) vs
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
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 marce...@redhat.com wrote:
The problem appears when a root memory region within an
address space with size UINT64_MAX has
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 marce...@redhat.com wrote:
The problem appears when a
The commit:
Commit: a53ae8e934cd54686875b5bcfc2f434244ee55d6
Author: Marcel Apfelbaum marce...@redhat.com
Date: Mon Sep 16 11:21:16 2013 +0300
hw/pci: partially handle pci master abort
introduced a regression on make check:
qemu-system-mips64el: /home/andreas/QEMU/qemu-cpu/exec.c:802:
On 3 November 2013 20:48, Marcel Apfelbaum marce...@redhat.com 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
On Sun, Nov 03, 2013 at 09:26:06PM +, Peter Maydell wrote:
On 3 November 2013 20:48, Marcel Apfelbaum marce...@redhat.com 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
28 matches
Mail list logo
