qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alex Williamson
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Wed, 18 May 2011 14:13:53 -0600

On Wed, 2011-05-18 at 22:11 +0200, Jan Kiszka wrote:
> On 2011-05-18 22:02, Alex Williamson wrote:
> > On Wed, 2011-05-18 at 14:34 -0500, Anthony Liguori wrote:
> >> 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.
> > 
> > Do we only need to handle CPU based I/O with this API?  I would think we
> > would be layering memory regions and implementing them as a hierarchy
> > that reflects the actual hardware layout we're emulating.  An access
> > from an I/O device may get a different translation to memory than a CPU
> > (IOMMU).  We also might have a system with two VGA devices that both
> > register 0xa0000 with a switch in the chipset that decides which one
> > sees the accesses, just as real hardware does. ISTR a presentation at
> > one of the first KVM forums from you that talked about this type of
> > model.  Thanks,
> 
> IIUC, that switch is present in every PCI bridge. It can forward legacy
> VGA I/O request to its devices or ignore them.

Right, I just thought it was a good example of how we both need to have
decode done in a hierarchy that reflects actual hardware and how we need
to support overlapping ranges.  Thanks,

Alex





reply via email to

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