[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] q35 chipset support
From: |
Jason Baron |
Subject: |
Re: [Qemu-devel] q35 chipset support |
Date: |
Mon, 18 Jun 2012 16:36:07 -0400 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
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<address@hidden> writes:
> >
> >>On 06/15/2012 02:04 AM, Markus Armbruster wrote:
> >>>Anthony Liguori<address@hidden> 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. So, it appears that the DMA controller is currently
used as an ISA dma controller. However, I don't see that hw/dma.c has explicit
ties to the ISA bus modeling. 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.
Thanks,
-Jason
- Re: [Qemu-devel] q35 chipset support, (continued)
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/14
- Re: [Qemu-devel] q35 chipset support, Markus Armbruster, 2012/06/15
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/15
- Re: [Qemu-devel] q35 chipset support, Michael S. Tsirkin, 2012/06/17
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Michael S. Tsirkin, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Jason Baron, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Markus Armbruster, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
- Re: [Qemu-devel] q35 chipset support,
Jason Baron <=
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Michael S. Tsirkin, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Michael S. Tsirkin, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Andreas Färber, 2012/06/18
- Re: [Qemu-devel] q35 chipset support, Anthony Liguori, 2012/06/18
Re: [Qemu-devel] q35 chipset support, Jason Baron, 2012/06/15