> I'd prefer a generic address type since this makes it easier to
> share code: for example virtio devices can use different busses,
This is exactly why virtio devices should not be accessing memory. They should
be doing everything via a virtqueue, which can interface with the host
bindings appr
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 t
Anthony Liguori wrote:
> It's a statement of correctness really. Devices should never deal with
> target_phys_addr_t's.
Shouldn't they? On real hardware, 64-bit PCI devices switch to being
32-bit PCI when plugged into a 32-bit motherboard slot.
> The question is, should a pci_addr_t or a sysbu
Juan Quintela wrote:
> Blue Swirl 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)
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 n
> 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 litt
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?
Sacrific
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), and
> 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 rebuild
> 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 shoul
On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
> On 3/24/10, Michael S. Tsirkin wrote:
> > On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> > > On 3/24/10, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
> > > > > rtl8139
On 3/24/10, Michael S. Tsirkin wrote:
> On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
> > On 3/24/10, Michael S. Tsirkin wrote:
> > > On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> > > > On 3/24/10, Michael S. Tsirkin wrote:
> > > > > On Tue, Mar 23, 2010 at 11
On 03/24/2010 03:24 PM, Blue Swirl wrote:
On 3/24/10, Michael S. Tsirkin wrote:
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> On 3/24/10, Michael S. Tsirkin wrote:
> > On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
> > > rtl8139.c, e1000.c: need to
On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
> On 3/24/10, Michael S. Tsirkin wrote:
> > On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> > > On 3/24/10, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
> > > > > rtl8139
On 3/24/10, Michael S. Tsirkin wrote:
> On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> > On 3/24/10, Michael S. Tsirkin 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/wr
On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> On 3/24/10, Michael S. Tsirkin 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.
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];
> target_
On 3/24/10, Michael S. Tsirkin 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. Further, a ton
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. Further, a ton of devices do
cpu_register_physical_memory/qemu_registe
Blue Swirl wrote:
> On 3/24/10, Juan Quintela wrote:
>> Blue Swirl 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 f
On 3/24/10, 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
On 3/24/10, Juan Quintela wrote:
> Blue Swirl 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 co
> 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
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
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 b
> 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
> > off
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 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
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) e
Blue Swirl 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 jump through hops
30 matches
Mail list logo
