qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Updated >2G memory patch


From: Blue Swirl
Subject: Re: [Qemu-devel] Updated >2G memory patch
Date: Sun, 30 Sep 2007 18:30:23 +0300

On 9/30/07, J. Mayer <address@hidden> wrote:
> About the design, my opinion is:
> - to support wider physical address spaces:
> * full 32 bits targets (ie 32 bits virtual & physical address spaces)
> should stay 32 bits.
> * for 32 bits targets with a few more bits for their physical address
> space (like the ppcemb target, which has 36 bits of physical address
> space and I guess x86 with PAE extension), it seems acceptable to only
> adjust the L1_BITS constants.

Thanks for the comments, I updated the patch to reflect these. Can the
ppcemb target be detected somehow so that the address space can be
adjusted?

> * for 64 bits targets, a multiple level table has to be used to avoid
> the need of huge l1_xxx tables. This includes the alpha target (42 bits
> of physical address space), for which I recognize the quick hack I did
> commit is not really acceptable.

IIRC HP's PA CPU used a hash table based TLB or MMU, maybe similar
could be used so that we avoid tables after tables?

> - to support more than 2 GB of RAM:
> I still think you should have to use a consistent type here, not just
> unsigned long.
> Do you really need another new type ? It seems to me that  one of
> physical_addr_t or ram_addr_t could be used ?

In my opinion target_phys_addr_t is specific to target, what we want
should be fixed to the host. Maybe ram_addr_t is OK, I have to check
where it's used.

Attachment: qemu_ram_patch.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]