> 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 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 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, 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
> 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
20 matches
Mail list logo
