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: Scott Wood
Subject: Re: [Qemu-devel] [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PCI controller (Root Complex)
Date: Mon, 11 Jun 2012 14:15:43 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 06/11/2012 12:05 AM, Bhushan Bharat-R65777 wrote:
>>> 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'm not sure what you mean by the latter.  It should support accessing
anything in CCSR that QEMU emulates, but I don't see QEMU emulating
everything in CCSR any time soon.

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

>From what Ben said, it would be a problem to use that for both this and
the PAMU at the same time.

> 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.

That's something that would need to be sorted out when this stuff is
implemented.

>> 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.

PCICSRBAR hides memory at the same address, thus swiotlb has to be used.
 If QEMU always returns zero for the BAR, Linux will see PCICSRBAR as
taking up all 4 GiB.

-Scott




reply via email to

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