Re: [Qemu-devel] q35 chipset support

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/18/2012 03:36 PM, Jason Baron wrote:
> On Mon, Jun 18, 2012 at 09:05:17AM -0500, Anthony Liguori wrote:
>> On 06/18/2012 08:51 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>
>>>> On 06/15/2012 02:04 AM, Markus Armbruster wrote:
>>>>> Anthony Liguori<anthony@codemonkey.ws>    writes:
>>>>>
>>>>>> On 06/14/2012 02:54 PM, Jason Baron wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I recently updated Isaku Yamahata's q35 patches to work on the latest qemu and
>>>>>>> seabios trees. On the qemu side, most of the changes revolved around updating
>>>>>>> to use QOM and updates to the memory API. I was also able to drop quite a few
>>>>>>> patches that had already been resolved by the current qemu tree.
>>>>>>>
>>>>>>> The trees seem pretty stable and can be found here:
>>>>>>>
>>>>>>> git://github.com/jibaron/q35-qemu.git
>>>>>>> git://github.com/jibaron/q35-seabios.git
>>>>>>
>>>>>> I'm got the beginnings of a feature page started:
>>>>>>
>>>>>> http://wiki.qemu.org/Features/Q35
>>>>>>
>>>>>> The approach above will not work in a QOM world unfortunately.  We
>>>>>> need to do quite a bit of ground work before adding another chipset.
>>>>>> The biggest task is converting devices to not require an ISA bus since
>>>>>> ICH9 simply doesn't have an ISA bus.
>>>>>
>>>>> Could you explain briefly why use of a software ISA bus construct
>>>>> matters for device models and/or guests?
>>>>
>>>> No, but I can provide a long explanation :-)
>>>
>>> Thanks!
>>>
>>>> The I440FX has a very basic device topology.  The PCI host is the
>>>> memory controller and there's a PCI device that happens to have the
>>>> SuperI/O chip + a PCI-ISA bridge.  There's no IOMMU and interrupt
>>>> routing is simple.
>>>
>>> PC interrupt routing is hardly ever "simple", but I get what you mean ;)
>>>
>>>> The Q35 is much more sophisticated.  The PCI-e complex itself can
>>>> present interesting topologies and the legacy PCI bus sits within the
>>>> PCI-e complex. You can still have a PCI-ISA bridge but the SuperI/O
>>>> chip is not part of it. Rather that's off of a separate bus (the LPC)
>>>> which does not logically reside within the PCI-e complex.
>>>
>>> Let's whether I understand.
>>>
>>> The platform devices do *not* sit behind a PCI-ISA bridge (in fact, no
>>> such bridge exists normally).  Instead, they're connected via LPC.
>>
>> No, *some* platform devices are connected via LPC.  Some are not.
>>
>> To give you an example: both LPC and ISA provide a bus-level DMA
>> interface. When you think of IOMMU modeling, it looks something like
>> this:
>>
>> Floppy controller:
>>    isa_memory_read(isa_dev, ...)
>>     ->  talks to DMA controller
>>
>> DMA controller:
>>    Implemented in PIIX4 for I440FX, within ICH9 for q35
>>    Uses cpu_physical_memory_rw() which takes the get_system() MemoryRegion
>>
>> So we cannot have the DMA controller be a ISA/LPC device as we do
>> today because the ISA bus should only use isa_memory_read() which is
>> implemented by the DMA controller.  We have an infinite modeling
>> loop today :-)
>>
>
> I'd like to understand this example better.
>
> I see that DMA_init() is called by pc_basic_device_init(), and used by devices
> such as fdc.c and cs4231a.c.

Correct.  It also is not modeled as a device at all (yikes!).

I've got a patch that converts dma.c to QOM actually/

> So, it appears that the DMA controller is currently
> used as an ISA dma controller.

Yes.

> However, I don't see that hw/dma.c has explicit
> ties to the ISA bus modeling.

But there should be.  DMA is a fundamental part of the ISA specification.  The 
ISA DMA interface is the only way that an ISA device can read from physical memory.

> The current code in hw/fdc.c does:
>
> DMA_read_memory (nchan, fdctrl->fifo + rel_pos,
> 		 fdctrl->data_pos, len);
>
> And the rest of interfaces to DMA in isa.h are:
>
> /* dma.c */
> int DMA_get_channel_mode (int nchan);
> int DMA_read_memory (int nchan, void *buf, int pos, int size);
> int DMA_write_memory (int nchan, void *buf, int pos, int size);
> void DMA_hold_DREQ (int nchan);
> void DMA_release_DREQ (int nchan);
> void DMA_schedule(int nchan);
>
> So I don't see a requirement that forces things to be an ISA device to
> make use of the DMA controller.

The only way an ISA device can read memory is by using a DMA controller.  We 
cheat in QEMU today but when trying to model an IOMMU, we cannot get away with 
cheating anymore.

Regards,

Anthony Liguori

>
> Thanks,
>
> -Jason