qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/6] [RFC] Emulation of GRLIB IRQMP as defined i


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 2/6] [RFC] Emulation of GRLIB IRQMP as defined in GRLIB IP Core User's Manual.
Date: Mon, 13 Dec 2010 18:13:03 +0000

On Mon, Dec 13, 2010 at 4:23 PM, Fabien Chouteau <address@hidden> wrote:
> On 12/11/2010 11:31 AM, Blue Swirl wrote:
>>
>> On Tue, Dec 7, 2010 at 10:43 AM, Fabien Chouteau<address@hidden>
>>  wrote:
>>>
>>> On 12/06/2010 06:25 PM, Blue Swirl wrote:
>>>>
>>>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteau<address@hidden>
>>>>  wrote:
>>>>>
>>>>> Signed-off-by: Fabien Chouteau<address@hidden>
>>>>> ---
>>>>>  hw/grlib_irqmp.c |  416
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  1 files changed, 416 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/hw/grlib_irqmp.c b/hw/grlib_irqmp.c
>>>>> new file mode 100644
>>>>> index 0000000..69e1553
>>>>> --- /dev/null
>>>>> +++ b/hw/grlib_irqmp.c
>>>>> @@ -0,0 +1,416 @@
>>>>> +/*
>>>>> + * QEMU GRLIB IRQMP Emulator
>>>>> + *
>>>>> + * (Multiprocessor and extended interrupt not supported)
>>>>> + *
>>>>> + * Copyright (c) 2010 AdaCore
>>>>> + *
>>>>> + * Permission is hereby granted, free of charge, to any person
>>>>> obtaining
>>>>> a copy
>>>>> + * of this software and associated documentation files (the
>>>>> "Software"),
>>>>> to deal
>>>>> + * in the Software without restriction, including without limitation
>>>>> the
>>>>> rights
>>>>> + * to use, copy, modify, merge, publish, distribute, sublicense,
>>>>> and/or
>>>>> sell
>>>>> + * copies of the Software, and to permit persons to whom the Software
>>>>> is
>>>>> + * furnished to do so, subject to the following conditions:
>>>>> + *
>>>>> + * The above copyright notice and this permission notice shall be
>>>>> included in
>>>>> + * all copies or substantial portions of the Software.
>>>>> + *
>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>>>> EXPRESS OR
>>>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>>>> MERCHANTABILITY,
>>>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
>>>>> SHALL
>>>>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>>>>> OR
>>>>> OTHER
>>>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>>>> ARISING FROM,
>>>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>>>>> DEALINGS IN
>>>>> + * THE SOFTWARE.
>>>>> + */
>>>>> +
>>>>> +#include "sysbus.h"
>>>>> +#include "cpu.h"
>>>>> +
>>>>> +#include "grlib.h"
>>>>> +
>>>>> +/* #define DEBUG_IRQ */
>>>>> +
>>>>> +#ifdef DEBUG_IRQ
>>>>> +#define DPRINTF(fmt, ...)                                       \
>>>>> +    do { printf("IRQMP: " fmt , ## __VA_ARGS__); } while (0)
>>>>> +#else
>>>>> +#define DPRINTF(fmt, ...)
>>>>> +#endif
>>>>> +
>>>>> +#define IRQMP_MAX_CPU 16
>>>>> +#define IRQMP_REG_SIZE 256      /* Size of memory mapped registers */
>>>>> +
>>>>> +/* Memory mapped register offsets */
>>>>> +#define LEVEL_OFFSET     0x00
>>>>> +#define PENDING_OFFSET   0x04
>>>>> +#define FORCE0_OFFSET    0x08
>>>>> +#define CLEAR_OFFSET     0x0C
>>>>> +#define MP_STATUS_OFFSET 0x10
>>>>> +#define BROADCAST_OFFSET 0x14
>>>>> +#define MASK_OFFSET      0x40
>>>>> +#define FORCE_OFFSET     0x80
>>>>> +#define EXTENDED_OFFSET  0xC0
>>>>> +
>>>>> +typedef struct IRQMP
>>>>> +{
>>>>> +    SysBusDevice busdev;
>>>>> +
>>>>> +    CPUSPARCState *env;
>>>>
>>>> Devices should never access CPUState directly. Instead, board level
>>>> should create CPU irqs and these should then be passed here.
>>>>
>>>
>>> This case is special, Leon3 is a System-On-Chip and some of the
>>> components
>>> are very close to the processor.
>>> IRQMP is not really a peripheral nor a part of the CPU, it's both...
>>
>> It's not a special case, it could be easily implemented separately.
>> MMUs, FPUs or co-processors could be special even if they have been
>> implemented as separate chips with real hardware. But we are actually
>> not looking at the (historical or current) chip boundaries but more
>> like what makes sense from QEMU architecture point of view.
>
> OK then, let's go back to your first comment, why a device can't access
> CPUState directly? And why Leon3.c would be better to do that.

Devices should mind their own business, not other devices' or
especially CPUs' businesses. The signals between devices should be
made with qemu_irq or bus style interfaces. Board case is different
because there we interface with QEMU host. Not all devices are very
clean yet.

This has been discussed a few times earlier, please see the list
archives if you really are interested.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]