Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

On Fri, Feb 27, 2015 at 6:52 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> On Fri, 2015-02-27 at 10:38 +0000, Ian Campbell wrote:
>> On Fri, 2015-02-27 at 15:41 +0530, Pranavkumar Sawargaonkar wrote:
>> > Hi Julien,
>> >
>> > On Thu, Feb 26, 2015 at 8:47 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>> > wrote:
>> > > On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
>> > >> Hi
>> > >
>> > > Hi Pranavkumar,
>> > >
>> > >> Also if we just show only one vITS (or only one Virtual v2m frame)
>> > >> instead of two vITS
>> > >> then actual hardware interrupt number and virtual interrupt number
>> > >> which guest will see will become different
>> > >> This will hamper direct irq routing to guest.
>> > >
>> > > The IRQ injection should not consider a 1:1 mapping between pIRQ and 
>> > > vIRQ.
>> >
>> > Yes, but in case of GICv2m( I am not sure about ITS) in register
>> > MSI_SETSPI_NS device has to write the interrupt ID (which is pirq) to
>> > generate an interrupt.
>> > If you write virq which is different that pirq (associated with the
>> > actual GICv2m frame ) then it will not trigger any interrupt.

vITS driver can assign pirq for each device as it requires and
programs ITT table
accordingly. The mapping pirq to virq is managed and virq is injected
to respective
domain

>> >
>> > Now there is case which I am not sure how it can be solvable with one
>> > vITS/vGICv2m  -
>> >
>> > . Suppose we have two GICv2m frames and say oneis  having an address
>> > 0x1000 for MSI_SETSPI_NS register and other 0x2000 for it's
>> > MSI_SETSPI_NS register
>> > . Assume first frame has SPI's (physical) 0x64 - 0x72 associated and
>> > second has 0x80-0x88 associated.
>> > . Now there are two PCIe hosts, first using first GICv2m frame as a
>> > MSI parent and another using second frame.
>> > . Device on first host uses MSI_SETSPI_NS (0x1000) address along with
>> > a data (i.e. intr number say 0x64) and device on second host uses
>> > 0x2000 and data 0x80
>> >
>> > Now if we show one vGICv2m frame in guest for both the devices then
>> > what address I will program in each device's config space for MSI and
>> > also what will the data value.
>> > Secondly device's write for these addresses will be transparent to cpu
>> > so how can we trap them while device wants to trigger any interrupt ?
>> >
>> > Please correct me if I misunderstood anything.
>>
>> Is what you are suggesting a v2m specific issue?
>>
>> I thought the whole point of the ITS stuff in GICv3 was that one could
>> program such virt-phys mappings into the hardware ITS and it would do
>> the translation (the T in ITS) such that the host got the pIRQ it was
>> expecting when the guest wrote the virtualised vIRQ information to the
>> device.
>
> Or perhaps I'm confusing interrupt translation here with the SMMU
> translation of the device's DMA writes to the MSI doorbell address?

True,  MSI physical address (GITS_TRANSLATOR register address) is
programmed by Domain when the device is initialized by writing to its
configuration
address space.

The MSIx interrupt is routed through SMMU and hence vITS driver maps
this physical GITS_TRANSLATOR physical address space to every
domain. So that SMMU can translate MSIx write generate by device and there
by raises MSIx interrupt.

So We don't trap when interrupt is triggered by device. it is
translated using SMMU
quietly and interrupt is routed to cpu.

Regards
Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel