Re: [Qemu-devel] [RFC] Memory API

[Anthony Liguori]

On 05/18/2011 02:27 PM, Jan Kiszka wrote:
> On 2011-05-18 21:10, Anthony Liguori wrote:
> > On 05/18/2011 10:30 AM, Jan Kiszka wrote:
> > You really don't need to register 90% of the time.  In the case of a PC
> > with i440fx, it's really quite simple:
> >
> > if an I/O is to the APIC page,
> >     it's handled by the APIC
>
> That's not that simple. We need to tell apart:
>   - if a cpu issued the request, and which one =>  forward to APIC

Right, but what I'm saying is that this logic lives in 
kvm-all.c:kvm_run():case EXIT_MMIO.

Obviously for TCG, it's a bit more complicated but this should be 
handled way before there's any kind of general dispatch.

>   - if the range was addressed by a device (PCI or other system bus
>     devices) =>  forward to MSI or other MMIO handlers

The same is true for MSI.  Other MMIO handlers can be handled as 
appropriate.  For instance, once an I/O is sent to the PCI bus, you can 
walk each PCI device's BAR list to figure out which device owns the I/O 
event.

For ISA, it's a little trickier since ISA doesn't do positive decoding. 
 You need each ISA device to declare what I/O addresses it handles.

> > elif the I/O is in ROM regions:
> >     if PAM RE or WE
> >        redirect to RAM appropriately
> >     else:
> >        send to ROMs
> > elif the I/O is in the PCI windows:
> >     send to the PCI bus
> > else:
> >     send to the PIIX3
> >
> > For x86, you could easily completely skip the explicit registration and
> > just have a direct dispatch to the i440fx and implement something
> > slightly more fancy than the above.
> >
> > And I think this is true for most other types of boards too.
>
> This all melts down that we need to stop accepting memory region
> mappings from everywhere at core level, but properly dispatch them up
> the device tree. A device should register against its bus which can then
> forward or handle the mapping directly. And that handling requires a
> central tool box to avoid reinventing wheels.
>
> That's a worthwhile change, though a much bigger one than I was
> originally hoping to get away with.

Agreed and as long as we've got the right long term vision in mind, we 
don't have to do everything up front.

Regards,

Anthony Liguori

> Jan