On Wed, Mar 24, 2010 at 06:07:35PM -0500, Anthony Liguori wrote:
On 03/24/2010 06:05 PM, Paul Brook wrote:
On 03/24/2010 05:33 PM, Paul Brook wrote:
But now there is a bigger problem, how to pass the property to the
device. It's not fair to require the user to remember to set it.
Blue Swirl blauwir...@gmail.com wrote:
Hi,
Here's some planning for getting most files compiled as few times as
possible. Comments and suggestions are welcome.
I took some thought about this at some point. Problems here start from
Recursive Makefile condered Harmful (tm).
Look at how we
The harder cases are those where the device code depends somehow on
the architecture. Some thoughts follow.
vl.c: a lot of work. Maybe the CPUState stuff should be separated to a new file.
dma.c: DMA_schedule needs access to CPUState.
Most users of CPUState (e.g. qemu-timer.c and hw/dma.c)
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets from the start of env affect the compactness of the code
generated
On 03/24/2010 12:19 PM, Richard Henderson wrote:
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets from the start of
On 03/24/2010 03:56 PM, Paul Brook wrote:
On 03/24/2010 12:19 PM, Richard Henderson wrote:
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite
On 03/24/2010 07:45 AM, Paolo Bonzini wrote:
On 03/24/2010 12:19 PM, Richard Henderson wrote:
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets from the start of env affect the compactness of the code
generated from TCG. We really really want the
On 3/24/10, Juan Quintela quint...@redhat.com wrote:
Blue Swirl blauwir...@gmail.com wrote:
Hi,
Here's some planning for getting most files compiled as few times as
possible. Comments and suggestions are welcome.
I took some thought about this at some point. Problems here start
On 3/24/10, Richard Henderson r...@twiddle.net wrote:
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets
Blue Swirl blauwir...@gmail.com wrote:
On 3/24/10, Juan Quintela quint...@redhat.com wrote:
Blue Swirl blauwir...@gmail.com wrote:
Hi,
Here's some planning for getting most files compiled as few times as
possible. Comments and suggestions are welcome.
I took some thought about
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
rtl8139.c, e1000.c: need to convert ldl/stl to
cpu_physical_memory_read/write.
I don't see how it would help. These still get target_phys_addr_t which
is per-target.
On 03/24/2010 10:07 AM, Richard Henderson wrote:
struct CPUSmallCommonState
{
// most of the stuff from CPU_COMMON.
// sorted for some thought of padding elimination. ;-)
};
struct CPULargeCommonState
{
CPUTLBEntry tlb_table[NB_MMU_MODES][CPU_TLB_SIZE];
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
rtl8139.c, e1000.c: need to convert ldl/stl to
cpu_physical_memory_read/write.
I don't see how it would
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
rtl8139.c, e1000.c: need to convert ldl/stl to
On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl
On 03/24/2010 03:24 PM, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkinm...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkinm...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl
But now there is a bigger problem, how to pass the property to the
device. It's not fair to require the user to remember to set it.
It should not be a property of the device. All devices have a native
endianness (for PCI this is little-endian), and the intermediate
busses/interconnects should
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?
On 03/24/2010 05:33 PM, Paul Brook wrote:
But now there is a bigger problem, how to pass the property to the
device. It's not fair to require the user to remember to set it.
It should not be a property of the device. All devices have a native
endianness (for PCI this is little-endian),
On 03/24/2010 06:05 PM, Paul Brook wrote:
On 03/24/2010 05:33 PM, Paul Brook wrote:
But now there is a bigger problem, how to pass the property to the
device. It's not fair to require the user to remember to set it.
It should not be a property of the device. All devices have a
Juan Quintela wrote:
Blue Swirl blauwir...@gmail.com wrote:
Hi,
Here's some planning for getting most files compiled as few times as
possible. Comments and suggestions are welcome.
I took some thought about this at some point. Problems here start from
Recursive Makefile condered
24 matches
Mail list logo
