On Wed, May 2, 2012 at 3:15 PM, Bob Breuer wrote:
> On 5/1/2012 1:48 PM, Mark Cave-Ayland wrote:
>> On 01/05/12 07:57, Blue Swirl wrote:
>>
Therefore I can't change it to my (modified) sbus_mmio_map() function
because it would break other non-SPARC platforms, and AIUI there is
nothi
On Tue, May 1, 2012 at 6:48 PM, Mark Cave-Ayland
wrote:
> On 01/05/12 07:57, Blue Swirl wrote:
>
>>> Therefore I can't change it to my (modified) sbus_mmio_map() function
>>> because it would break other non-SPARC platforms, and AIUI there is
>>> nothing
>>> in the memory API that allows me to mov
On 5/1/2012 1:48 PM, Mark Cave-Ayland wrote:
> On 01/05/12 07:57, Blue Swirl wrote:
>
>>> Therefore I can't change it to my (modified) sbus_mmio_map() function
>>> because it would break other non-SPARC platforms, and AIUI there is
>>> nothing
>>> in the memory API that allows me to move a subregi
Am 01.05.2012 20:50, schrieb Mark Cave-Ayland:
> On 01/05/12 08:10, Blue Swirl wrote:
>> The signal dma_enabled should be eventually replaced by a Pin.
>
> And this is a sysbus concept, yes?
No, it'll be a general DeviceState concept.
SysBus is supposed to die out gradually.
Andreas
--
SUSE LI
On 01/05/12 08:10, Blue Swirl wrote:
In your view, would a suitable fix be to change dma_memory_read,
dma_memory_write, dma_opaque, it_shift and dma_enabled to be qdev properties
and modify esp_init() to return the qdev reference so they can be set by the
caller?
There's an ongoing work to int
On 1 May 2012 19:57, Mark Cave-Ayland wrote:
> On 01/05/12 16:20, Peter Maydell wrote:
>
>>> Correctness is more important to me than brevity.
>>>
>>> And really, we should focus on killing things like i8259_init().
>>
>>
>> Functions like i8259_init() exist precisely because
>> QOM/qdev don't pro
On 01/05/12 16:20, Peter Maydell wrote:
Correctness is more important to me than brevity.
And really, we should focus on killing things like i8259_init().
Functions like i8259_init() exist precisely because
QOM/qdev don't provide brevity and people trying to
use these devices do in fact value
On 01/05/12 07:57, Blue Swirl wrote:
Therefore I can't change it to my (modified) sbus_mmio_map() function
because it would break other non-SPARC platforms, and AIUI there is nothing
in the memory API that allows me to move a subregion to a different
MemoryRegion parent, even if I can get a refe
On May 1, 2012 10:37 AM, "Peter Maydell" wrote:
>
> On 1 May 2012 16:26, Anthony Liguori wrote:
> > On 05/01/2012 10:20 AM, Peter Maydell wrote:
> >> The assumption is that failure to connect is a fatal error,
> >> and we can happily just assert()/hw_error()/etc.
> >
> > So that means that we hav
On 1 May 2012 16:26, Anthony Liguori wrote:
> On 05/01/2012 10:20 AM, Peter Maydell wrote:
>> The assumption is that failure to connect is a fatal error,
>> and we can happily just assert()/hw_error()/etc.
>
> So that means that we have a bug from someone miss-typing, instead of your
> hotplug att
On 05/01/2012 10:20 AM, Peter Maydell wrote:
On 1 May 2012 16:09, Anthony Liguori wrote:
On 05/01/2012 09:20 AM, Peter Maydell wrote:
This is a bit verbose. Something more like
pin_connect(s, "int_out[0]", self, "int_set[2]");
This is incorrect, it would have to be:
Error *err = NULL;
if
On 1 May 2012 16:09, Anthony Liguori wrote:
> On 05/01/2012 09:20 AM, Peter Maydell wrote:
>> This is a bit verbose. Something more like
>> pin_connect(s, "int_out[0]", self, "int_set[2]");
>
> This is incorrect, it would have to be:
>
> Error *err = NULL;
>
> if (pin_connect(s, "in_out[0]", self
On 05/01/2012 09:26 AM, Avi Kivity wrote:
On 05/01/2012 05:15 PM, Anthony Liguori wrote:
I think a nice fix would be to make it_shift as memory region mutator
and allow it to be set after initialization.
Indeed I wanted to make it_shift as part of the memory core. But a
mutator? It doesn't c
On 05/01/2012 09:20 AM, Peter Maydell wrote:
On 1 May 2012 15:06, Anthony Liguori wrote:
Do you mean:
-qdev_connect_gpio_out(&dev->qdev, 0, irq_set[2]);
+pin_connect_qemu_irq(&s->int_out[0], irq_set[2]);
There are three ways to do this:
1) pin_connect_qemu_irq(i8259_get_int_out(s), i
On 05/01/2012 05:15 PM, Anthony Liguori wrote:
>>> I think a nice fix would be to make it_shift as memory region mutator
>>> and allow it to be set after initialization.
>>
>> Indeed I wanted to make it_shift as part of the memory core. But a
>> mutator? It doesn't change in real hardware, so thi
On 1 May 2012 15:06, Anthony Liguori wrote:
> Do you mean:
>
> - qdev_connect_gpio_out(&dev->qdev, 0, irq_set[2]);
> + pin_connect_qemu_irq(&s->int_out[0], irq_set[2]);
>
> There are three ways to do this:
>
> 1) pin_connect_qemu_irq(i8259_get_int_out(s), irq_set[2]);
No good unless you're
On 05/01/2012 09:09 AM, Avi Kivity wrote:
On 05/01/2012 04:50 PM, Anthony Liguori wrote:
On 05/01/2012 08:01 AM, Avi Kivity wrote:
On 05/01/2012 03:49 PM, Peter Maydell wrote:
On 1 May 2012 13:48, Avi Kivity wrote:
On 05/01/2012 03:43 PM, Peter Maydell wrote:
On 1 May 2012 13:42, Avi Kivit
On 05/01/2012 04:50 PM, Anthony Liguori wrote:
> On 05/01/2012 08:01 AM, Avi Kivity wrote:
>> On 05/01/2012 03:49 PM, Peter Maydell wrote:
>>> On 1 May 2012 13:48, Avi Kivity wrote:
On 05/01/2012 03:43 PM, Peter Maydell wrote:
> On 1 May 2012 13:42, Avi Kivity wrote:
>> sysbus should
On 05/01/2012 09:00 AM, Peter Maydell wrote:
On 1 May 2012 14:50, Anthony Liguori wrote:
On 05/01/2012 03:49 PM, Peter Maydell wrote:
When QOM supports (1) exporting gpio signals and
This is trivial. It'll come in as soon as 1.2 opens up.
You need to get it through code review first...
On 1 May 2012 14:50, Anthony Liguori wrote:
>> On 05/01/2012 03:49 PM, Peter Maydell wrote:
>>> When QOM supports (1) exporting gpio signals and
>
> This is trivial. It'll come in as soon as 1.2 opens up.
You need to get it through code review first...
(just as a random example, this commit:
ht
On 05/01/2012 01:57 AM, Blue Swirl wrote:
On Mon, Apr 30, 2012 at 13:52, Mark Cave-Ayland
wrote:
On 30/04/12 14:27, Peter Maydell wrote:
Hi Peter,
IMO the best fix is to unsysbus the device and qomify it instead. This
way we're 100% flexible in how we can attach it.
You don't need to w
On 05/01/2012 08:01 AM, Avi Kivity wrote:
On 05/01/2012 03:49 PM, Peter Maydell wrote:
On 1 May 2012 13:48, Avi Kivity wrote:
On 05/01/2012 03:43 PM, Peter Maydell wrote:
On 1 May 2012 13:42, Avi Kivity wrote:
sysbus should just die.
Totally agreed. It's not going to go quietly though...
On 05/01/2012 03:49 PM, Peter Maydell wrote:
> On 1 May 2012 13:48, Avi Kivity wrote:
> > On 05/01/2012 03:43 PM, Peter Maydell wrote:
> >> On 1 May 2012 13:42, Avi Kivity wrote:
> >> > sysbus should just die.
> >>
> >> Totally agreed. It's not going to go quietly though...
> >
> > Not if you kee
On 1 May 2012 13:48, Avi Kivity wrote:
> On 05/01/2012 03:43 PM, Peter Maydell wrote:
>> On 1 May 2012 13:42, Avi Kivity wrote:
>> > sysbus should just die.
>>
>> Totally agreed. It's not going to go quietly though...
>
> Not if you keep suggesting workarounds when I tell unsuspecting
> developer
On 05/01/2012 03:43 PM, Peter Maydell wrote:
> On 1 May 2012 13:42, Avi Kivity wrote:
> > sysbus should just die.
>
> Totally agreed. It's not going to go quietly though...
Not if you keep suggesting workarounds when I tell unsuspecting
developers to qomify their devices.
--
error compiling com
On 04/30/2012 04:40 PM, Mark Cave-Ayland wrote:
> On 30/04/12 14:23, Avi Kivity wrote:
>
> Hi Avi,
>
>>> My understanding based upon this is that it would be impossible to
>>> register a different parent MemoryRegion without duplicating the init
>>> function for all shared devices which seems undes
On 1 May 2012 13:42, Avi Kivity wrote:
> sysbus should just die.
Totally agreed. It's not going to go quietly though...
-- PMM
On 05/01/2012 03:41 PM, Peter Maydell wrote:
> On 1 May 2012 13:39, Avi Kivity wrote:
> > On 04/30/2012 04:40 PM, Peter Maydell wrote:
> >> I wrote it for essentially the purpose described above :-)
> >> If you're the owner of the sysbus device in question then it's
> >> entirely fine as you are t
On 04/30/2012 04:43 PM, Anthony Liguori wrote:
> On 04/30/2012 08:36 AM, Avi Kivity wrote:
>> On 04/30/2012 04:27 PM, Peter Maydell wrote:
>>> On 30 April 2012 14:23, Avi Kivity wrote:
IMO the best fix is to unsysbus the device and qomify it instead.
This
way we're 100% flexible in
On 1 May 2012 13:39, Avi Kivity wrote:
> On 04/30/2012 04:40 PM, Peter Maydell wrote:
>> I wrote it for essentially the purpose described above :-)
>> If you're the owner of the sysbus device in question then it's
>> entirely fine as you are the one deciding whether to use the
>> traditional map f
On 04/30/2012 04:40 PM, Peter Maydell wrote:
> On 30 April 2012 14:36, Avi Kivity wrote:
> > On 04/30/2012 04:27 PM, Peter Maydell wrote:
> >> On 30 April 2012 14:23, Avi Kivity wrote:
> >> > IMO the best fix is to unsysbus the device and qomify it instead. This
> >> > way we're 100% flexible in
On Mon, Apr 30, 2012 at 14:33, Mark Cave-Ayland
wrote:
> On 30/04/12 15:03, Peter Maydell wrote:
>
>>> Therefore I can't change it to my (modified) sbus_mmio_map() function
>>> because it would break other non-SPARC platforms, and AIUI there is
>>> nothing
>>> in the memory API that allows me to m
On Mon, Apr 30, 2012 at 13:52, Mark Cave-Ayland
wrote:
> On 30/04/12 14:27, Peter Maydell wrote:
>
> Hi Peter,
>
>
>>> IMO the best fix is to unsysbus the device and qomify it instead. This
>>> way we're 100% flexible in how we can attach it.
>>
>>
>> You don't need to wait for QOM to grow enough
Am 30.04.2012 16:55, schrieb Mark Cave-Ayland:
> Note that if properties can't be set by the caller after construction,
> then I'm effectively going to have to copy the entire esp_init()
> function;
The idea would be to use the QOM way of creating the object, using QOM
and/or custom ways to set pr
On 30 April 2012 15:55, Mark Cave-Ayland wrote:
> I
> might as well just keep a copy in sun4m.c with my local modifications as
> sun4_esp_init() and be done with it. Slightly frustrating, but I think
> that's going to be the easiest solution for the moment.
You will need to address the properties
On 30 April 2012 15:55, Mark Cave-Ayland wrote:
> Note that if properties can't be set by the caller after construction, then
> I'm effectively going to have to copy the entire esp_init() function
Yes. As I say, these init functions are purely convenience functions
for the simple case. (My opinio
On 30/04/12 15:39, Peter Maydell wrote:
Right I think I'm starting to understand this now - in which case it becomes
a matter of just copying a handful of lines within sun4m which is more
bearable.
In your view, would a suitable fix be to change dma_memory_read,
dma_memory_write, dma_opaque, it
On 30 April 2012 15:33, Mark Cave-Ayland wrote:
> On 30/04/12 15:03, Peter Maydell wrote:
> Right I think I'm starting to understand this now - in which case it becomes
> a matter of just copying a handful of lines within sun4m which is more
> bearable.
>
> In your view, would a suitable fix be to
On 30/04/12 15:03, Peter Maydell wrote:
Therefore I can't change it to my (modified) sbus_mmio_map() function
because it would break other non-SPARC platforms, and AIUI there is nothing
in the memory API that allows me to move a subregion to a different
MemoryRegion parent, even if I can get a r
On 30 April 2012 14:52, Mark Cave-Ayland wrote:
> The key problem is that this doesn't worked with shared peripherals, such as
> the ESP device which is also used on various PPC Mac models as well as
> SPARC. That's because its init function looks like this:
>
>
>
> void esp_init(target_phys_addr_
On 30/04/12 14:27, Peter Maydell wrote:
Hi Peter,
IMO the best fix is to unsysbus the device and qomify it instead. This
way we're 100% flexible in how we can attach it.
You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, y
On 04/30/2012 08:36 AM, Avi Kivity wrote:
On 04/30/2012 04:27 PM, Peter Maydell wrote:
On 30 April 2012 14:23, Avi Kivity wrote:
IMO the best fix is to unsysbus the device and qomify it instead. This
way we're 100% flexible in how we can attach it.
You don't need to wait for QOM to grow eno
On 30 April 2012 14:36, Avi Kivity wrote:
> On 04/30/2012 04:27 PM, Peter Maydell wrote:
>> On 30 April 2012 14:23, Avi Kivity wrote:
>> > IMO the best fix is to unsysbus the device and qomify it instead. This
>> > way we're 100% flexible in how we can attach it.
>>
>> You don't need to wait for
On 30/04/12 14:23, Avi Kivity wrote:
Hi Avi,
My understanding based upon this is that it would be impossible to
register a different parent MemoryRegion without duplicating the init
function for all shared devices which seems undesirable :(
What are the requirements? You need a different cat
On 04/30/2012 04:27 PM, Peter Maydell wrote:
> On 30 April 2012 14:23, Avi Kivity wrote:
> > IMO the best fix is to unsysbus the device and qomify it instead. This
> > way we're 100% flexible in how we can attach it.
>
> You don't need to wait for QOM to grow enough features to
> replace sysbus.
On 30 April 2012 14:23, Avi Kivity wrote:
> IMO the best fix is to unsysbus the device and qomify it instead. This
> way we're 100% flexible in how we can attach it.
You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, you
can a
On 04/30/2012 03:17 PM, Mark Cave-Ayland wrote:
> On 30/04/12 09:41, Avi Kivity wrote:
>
>> Yes. I think it's even possible to do this now, you can create an mmio
>> region for the bus and add subregions to it. All subregions
>> automatically overlap the container region.
>>
>> Simply replace
>>
On 30/04/12 09:41, Avi Kivity wrote:
Yes. I think it's even possible to do this now, you can create an mmio
region for the bus and add subregions to it. All subregions
automatically overlap the container region.
Simply replace
memory_region_init(&bus->address_space, ...)
memory_region_
On 04/29/2012 10:35 PM, Anthony Liguori wrote:
> On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I've been having a look at handling SBUS probes within
>> qemu-system-sparc when I
>> came across a very simple crash bug with git master trying to access
>> unassigned
>> physical addr
On 04/29/2012 03:09 PM, Blue Swirl wrote:
On Sun, Apr 29, 2012 at 19:35, Anthony Liguori wrote:
On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:
Hi all,
I've been having a look at handling SBUS probes within qemu-system-sparc
when I
came across a very simple crash bug with git master trying t
On Sun, Apr 29, 2012 at 19:35, Anthony Liguori wrote:
> On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:
>>
>> Hi all,
>>
>> I've been having a look at handling SBUS probes within qemu-system-sparc
>> when I
>> came across a very simple crash bug with git master trying to access
>> unassigned
>> ph
On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:
Hi all,
I've been having a look at handling SBUS probes within qemu-system-sparc when I
came across a very simple crash bug with git master trying to access unassigned
physical addresses:
(qemu) info mtree
memory
-7ffe
Hi all,
I've been having a look at handling SBUS probes within qemu-system-sparc
when I came across a very simple crash bug with git master trying to
access unassigned physical addresses:
(qemu) info mtree
memory
-7ffe (prio 0, RW): system
-00
53 matches
Mail list logo
