On 03/17/2010 04:48 AM, Riku Voipio wrote:
>>> page_check_range:
>>>
>>> -if (start + len < start)
>>> -/* we've wrapped around */
>>> ...
>>> +if (start + len - 1 < start) {
>>> +/* We've wrapped around. */
>>>
>>> This now blows up with len = 0;
>
>> Confirmed. A quick t
On Mon, Mar 15, 2010 at 04:08:46PM +0100, Jan-Simon Möller wrote:
> Am Montag, 15. März 2010 15:48:03 schrieb Riku Voipio:
> > On Mon, Mar 15, 2010 at 01:46:10PM +0100, Jan-Simon Möller wrote:
> > > r...@frodo:/# qemu-arm -strace /sbin/ldconfig.real
> > > 16359 uname(0x403fef78) = 0
> > > 16359 brk
Am Montag, 15. März 2010 15:48:03 schrieb Riku Voipio:
> On Mon, Mar 15, 2010 at 01:46:10PM +0100, Jan-Simon Möller wrote:
> > We're still investigating the topic. So far, we tracked one failure down
> > to ldconfig.real which is a static arm binary executed after the chroot
> > got the basic packa
On Mon, Mar 15, 2010 at 01:46:10PM +0100, Jan-Simon Möller wrote:
> We're still investigating the topic. So far, we tracked one failure down to
> ldconfig.real which is a static arm binary executed after the chroot got the
> basic packages installed. If we setup a chroot with an older qemu-arm and
> > I had QEMU working on PowerPC and ARM in chroots from the Linux versions:
> >
> > - Fedora 11 / 12
> > - Ubuntu 9.04, 9.10, 10.04
> > - Debian 4, 5 and Sid
> >
> > for ARM and PowerPC. My host OS is openSUSE 11.2 using a 2.6.31 kernel,
> > or openSUSE 11.1. All machines are 64 Bit machines.
> >
On Sat, Mar 13, 2010 at 03:00:52PM +0100, Martin Mohring wrote:
> I am sorry to bring us all down to earth, we all had wished that this stuff
> gets finally fixed, but it seems that those patches applied to QEMU master
> have killed QEMU user mode.
sid and maemo userlands work for me like befor
I am sorry to bring us all down to earth, we all had wished that this stuff
gets finally fixed, but it seems that those patches applied to QEMU master have
killed QEMU user mode.
I am referring to the user mode fixes after commit
0aef4261ac0ec9089ade0e3a92f986cb4ba7317e
I had QEMU working on P
On Fri, Mar 12, 2010 at 06:51:41PM +, Paul Brook wrote:
> > Richard Henderson (6):
> > Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> > Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> > linux-user: Use h2g_valid in qemu_vmalloc.
> > linux-user: Fix mmap_find_vma returning invalid
> /src/qemu/exec.c: In function `page_set_flags':
> /src/qemu/exec.c:2336: warning: comparison is always true due to
> limited range of data type
Should be fixed by b480d9b74dfd1efd29026b7dc6438364a633ee99
Paul
On 3/12/10, Paul Brook wrote:
> > Richard Henderson (6):
> > Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> > Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> > linux-user: Use h2g_valid in qemu_vmalloc.
> > linux-user: Fix mmap_find_vma returning invalid addresses.
> > Implem
> Richard Henderson (6):
> Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> linux-user: Use h2g_valid in qemu_vmalloc.
> linux-user: Fix mmap_find_vma returning invalid addresses.
> Implement multi-level page tables.
> Fix last page e
Changes since v2:
* Fix two errors pointed out by pbrook: l1_map size in system mode,
and h2g_valid definition for 64-on-32-bit.
* Assertions that addresses are not outside the bounds of the
guest address space.
* Re-base vs master, after l1_map_phys changes.
r~
Richard Henderson
> Which brings us to the problem of exec.c and the address spaces therein.
> First, there was the fact that TARGET_PHYS_ADDR_SPACE_BITS was constrained
> to be no larger than 32 (with a partial hack for Alpha to extend this to
> 42 bits). Second, that this physical address space value was applied
I have previously posted a variant of part 6, to address the problem
of the host returning mmap results that are not page aligned for the
guest. That, however, led me to the fact that we could also return
addresses that are outside the guest's virtual address space.
Which raises the question of w
14 matches
Mail list logo
