From: Anthony Liguori <anthony@codemonkey.ws>
To: Paul Brook <paul@codesourcery.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Re: Compile files only once: some planning
Date: Wed, 24 Mar 2010 17:57:17 -0500 [thread overview]
Message-ID: <4BAA98CD.4090900@codemonkey.ws> (raw)
In-Reply-To: <201003242247.53346.paul@codesourcery.com>
On 03/24/2010 05:47 PM, Paul Brook wrote:
>> Actually, Anthony suggested at some point to just use 64 bits for
>> TARGET_PHYS_ADDR_BITS and remove the need for hw32/64.
>>
>> I think that people emulationg 32bits on 32bits would suffer, but have
>> no clue how much. Anthony, what was the idea?
>>
> Sacrificing runtime performance to avoid rebuilding a few files is not
> acceptable. I consider the fact that TARGET_PHYS_ADDR_BITS is always 64 on 64-
> bit hosts is a bug. It's just hard to fix, and probably even less of a
> performance hit, so I haven't bothered yet.
>
It's a statement of correctness really. Devices should never deal with
target_phys_addr_t's.
The question is, should a pci_addr_t or a sysbus_addr_t be 64 bit or
should it be 32-bit on 32-bit platforms. Honestly, I am extremely
sceptical that there would be any measurable performance difference.
Regards,
Anthony Liguori
> Paul
>
>
>
next prev parent reply other threads:[~2010-03-24 22:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 21:43 [Qemu-devel] Compile files only once: some planning Blue Swirl
2010-03-24 9:17 ` [Qemu-devel] " Juan Quintela
2010-03-24 17:56 ` Blue Swirl
2010-03-24 19:28 ` Juan Quintela
2010-03-24 22:47 ` Paul Brook
2010-03-24 22:57 ` Anthony Liguori [this message]
2010-03-25 3:08 ` Jamie Lokier
2010-03-25 2:54 ` Jamie Lokier
2010-03-24 9:47 ` Paolo Bonzini
2010-03-24 11:19 ` Richard Henderson
2010-03-24 14:45 ` Paolo Bonzini
2010-03-24 14:56 ` Paul Brook
2010-03-24 16:18 ` Paolo Bonzini
2010-03-24 17:27 ` Paul Brook
2010-03-24 17:07 ` Richard Henderson
2010-03-24 20:12 ` Richard Henderson
2010-03-24 18:00 ` Blue Swirl
2010-03-24 19:39 ` Michael S. Tsirkin
2010-03-24 20:05 ` Blue Swirl
2010-03-24 20:08 ` Michael S. Tsirkin
2010-03-24 20:24 ` Blue Swirl
2010-03-24 20:24 ` Michael S. Tsirkin
2010-03-24 20:32 ` Blue Swirl
2010-03-24 20:28 ` Anthony Liguori
2010-03-24 21:00 ` Aurelien Jarno
2010-03-24 22:33 ` Paul Brook
2010-03-24 22:50 ` Anthony Liguori
2010-03-24 23:05 ` Paul Brook
2010-03-24 23:07 ` Anthony Liguori
2010-03-25 8:21 ` Michael S. Tsirkin
2010-03-25 12:01 ` Paul Brook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BAA98CD.4090900@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.