Re: [Qemu-devel] [PATCH 2/2] m48t59: add mem_base value to m48t59_init_isa()

[Artyom Tarasenko <atar4qemu@gmail.com>]

On Mon, Jan 19, 2015 at 9:03 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 19.01.2015 um 16:22 schrieb Artyom Tarasenko:
>> On Mon, Jan 19, 2015 at 4:01 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 19.01.2015 um 13:57 schrieb Artyom Tarasenko:
>>>> On Mon, Jan 19, 2015 at 1:45 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>> On 19/01/2015 12:35, Mark Cave-Ayland wrote:
>>>>>> Similar to m48t59_init(), add a mem_base value so that NVRAM can be mapped via
>>>>>> MMIO rather than ioport if required.
>>>>>>
>>>>>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>>>>>> ---
>>>>>
>>>>> Is it really ISA if it's MMIO?  In other words, why can't this be a
>>>>> sysbus device?
>>>>
>>>> On physical machines it's EBus, which is pretty much like 8-bit ISA.
>>>> So, I think modelling it as ISA is closer to to the reality.
>>>> But out of curiosity, would it be possible to have a sysbus device
>>>> somewhere in a middle of PCI space? [...]
>>>
>>> Why would you want to use a SysBusDevice in the first place?
>>
>> Ask Paolo. :-) For me it's only important to have a MMIO device in the
>> proper address range.
>>
>>> I previously discussed with Mark that it should be an EBusDevice, not an
>>> ISADevice or SysBusDevice.
>>
>> Interesting. I can't find this discussion in the list archive.
>
> Hm, am I mixing that up with SBus then? There were some helper functions
> related to ROM loading being added as context to my suggestion that I
> thought could become class fields.

Yes, for SBus it totally makes sense.

>> Do you suggest to
>> create EBusDevices for all ISA devices (serial, parallel, keyboard,
>> floppy) used in sun4u, or only for m48t59?
>> What would be the advantage of using EBusDevice over ISADevice?
>
> For all devices that are in fact EBus devices. The general idea is
> encapsulation and abstraction - hiding the implementation detail of
> whether it is internally an ISADevice or something else. Such a patch
> should be quite trivial. Similarly it gives helper functions and
> potential class methods a natural place to live.

Yes, the patch is trivial. But EBus is nothing else but an ISA bus
with 8 data lines.
To me it looks like the bus width is an implementation detail we can
hide. (It's not documented what should happen if an EBus device is
accessed with a non 8-bit width. I tried 16 bit access on a physical
machine and it seemed to work).

Currently we can just use all the ISA devices unmodified if we like.
With EBus we would only be able to use a subset of ISA devices, no?

Artyom



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu