Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules

[Peter Maydell]

On 11 September 2013 09:56, Gerd Hoffmann <address@hidden> wrote:
> On Mi, 2013-09-11 at 09:20 +0100, Peter Maydell wrote:
>> Does this mean that the code was previously wrong for targets
>> which didn't have 4K pages, or would we just have been a bit
>> inefficient? I ask because ARM's TARGET_PAGE_SIZE is 1K...
>
> Hmm.  There are three places where TARGET_PAGE_SIZE is used.
>
>  (1) Dirtying.  The page dirtying would be just a bit inefficient
>      (range is larger than it needs to be).
>  (2) rom_size.  Just needs be cleaned up, is hard-coded to 8192 anyway,
>      no need at all to look at the page size.
>  (3) rom->num_pages field.  That one will change for arm.  The linux
>      kernel qxl kms driver seems not to care at all.  Not surprising,
>      it is more convenient to use the offsets in the rom to figure how
>      the qxl memory layout looks like.

Note that the ARM Linux *kernel* will (probably) be using 4K pages
anyway. It's just that QEMU's TARGET_PAGE_SIZE means "smallest
page size this CPU family could possibly support", which for ARM
is 1K, even if 99.9% of guests won't use 1K pages. This is one
of the reasons it's not very useful for devices -- it's almost just
an internal implementation detail of QEMU's TLB/memory system.

What is the num_pages field supposed to mean, given that
"page size" isn't a well defined platform independent value
(for hardware or for QEMU)?

> I still think it is better to go for a fixed page size.  Real hardware
> doesn't adapt to the target page size too.  ehci for example operates on
> 4k pages no matter what, and arm then has to care to allocate 4 1k pages
> in a row for usb xfers.

I agree that devices should not (in general) be using
TARGET_PAGE_SIZE, not least because it has an odd and
not entirely obvious meaning (see above).

-- PMM