qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PC


From: Bhushan Bharat-R65777
Subject: Re: [Qemu-devel] [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PCI controller (Root Complex)
Date: Mon, 11 Jun 2012 05:05:26 +0000


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Saturday, June 09, 2012 12:27 AM
> To: Bhushan Bharat-R65777
> Cc: address@hidden; address@hidden; Wood Scott-B07421; Yoder
> Stuart-B08248
> Subject: Re: [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PCI 
> controller
> (Root Complex)
> 
> On 06/08/2012 04:03 AM, Bhushan Bharat-R65777 wrote:
> > Hi All,
> >
> > When Freescale PCI controller configured in Root Complex mode then,
> > its configuration header (type 1) have one inbound BAR (BAR0, called
> > as CCSRBAR).
> 
> It maps to CCSRBAR, but it's called PCICSRBAR/PEXCSRBAR.
> 
> > And rest of BARs (inbound and outbound) are supported by ATMU
> > registers, which are outside the Type 1 configuration header.
> > This BAR0 of Type 1 configuration header always translate to CCSR
> > space and is of the size of CCSR. This BAR0 (inbound window) is
> > required for MSI interrupts support.
> 
> Some sort of inbound mapping is required for MSIs.  It's typically this one or
> PEXMSIBAR (which is a similar concept but more full-featured, and not in 
> config
> space), but doesn't have to be (e.g. we use normal inbound windows for MSI on
> Topaz, because of PAMU limitations that prevent us from using the CCSR address
> as the guest physical MSI destination).

When guest access BAR0 of configuration space or it accesses PEXMSIBAR, a 
common inbound mapping will translate the address to CCSR (Now the translated 
address may be further translated to real physical by IOMMU translation layer 
if configured in QEMU).

> 
> > As far as I know, as of now no emulated PCI controller supports this
> > BAR0 in type 1 configuration header. But probably (I think so) that
> > supporting this is not of big concern, but the point is that this
> > window (BAR0) translate to mmio-regs (CCSR) and not to DDR memory.
> >
> > So I have couple of concerns here:
> >
> > 1. Whenever PCI device does need DMA then these windows (inbound and
> > outbound ATMUs registers) need to used to translate pci address to
> > system physical address (Sometime we also call this as cpu address
> > space). This will probably be done by : [Qemu-devel] [PATCH 00/12]
> > IOMMU Infrastructure : patch-set ( I am trying to understand these
> > patches :-))
> >
> > 2. Hook up this inbound BAR0 in the above patch-set to translate to
> > mmio-regs. As this would be controller specific, a callback will be
> > registered for translation. Now it will be upto the controller
> > specific code on how it translates. As this is needed only for MSI
> > interrupt, maybe, initially we do not do anything initially, till we
> > want MSI emulation in QEMU.
> 
> MSIs may be the only thing that we plan to use it for, but if you want to
> properly emulate the chip you need to fully implement all the translation
> windows.

Do you mean address translation using ATMU inbound/outbound windows? Or 
complete translation support of CCSR space?

The former, I think, not sure, should get supported by "IOMMU Infrastructure" 
patch set.

The later is not supported. And if I understood correctly then, I think the I 
agree with you on emulating complete CCSR space. Do you think that we can start 
with supporting the MSI region mapping (MPIC mmio regs) and design it in way 
that later if needed it can be extended for rest of CCSR space.

If in kernel MPIC is there, then the QEMU will use the in-kernel MPIC to 
generate MSI interrupt or it will use QEMU emulated MPIC to generate MSI 
interrupt.

> 
> We also want the BAR itself to be properly emulated, as otherwise software can
> get confused when it reads it and sees zero as the location of the PCI DMA
> memory hole.
> 

Probably I did not understood clearly. Can you please elaborate of what type of 
confusion.

Thanks
-Bharat




reply via email to

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