On 11 September 2013 09:56, Gerd Hoffmann <kra...@redhat.com> 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
