[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-module
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules |
Date: |
Wed, 11 Sep 2013 11:03:07 +0100 |
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
- Re: [Qemu-devel] [RFC PATCH v5 4/6] module: implement module loading function, (continued)
- [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Fam Zheng, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Paolo Bonzini, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Paolo Bonzini, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Gerd Hoffmann, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Fam Zheng, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Peter Maydell, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Gerd Hoffmann, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules,
Peter Maydell <=
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Gerd Hoffmann, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Peter Maydell, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Fam Zheng, 2013/09/11
- Re: [Qemu-devel] [RFC PATCH v5 5/6] configure: introduce --enable-modules, Paolo Bonzini, 2013/09/11
[Qemu-devel] [RFC PATCH v5 6/6] block: build qed and curl as shared library, Fam Zheng, 2013/09/11