Well, i don't think that your patch will work for all of the cases, as
some platforms boot with non multi-function devices using interrupt
pin other than INTA... i myself encountered 2 such Lenovo platforms.
So, i think we will need to use both patches together. What do u say?
On Tue, Dec 29, 2009 at 4:01 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> On Tue, Dec 29, 2009 at 08:22:35AM +0800, Zhai, Edwin wrote:
>> Your patch can also fix this issue, as using physical pin info for
>> both guest and xen.
>> Only potential issue is that guest will see a single function device
>> is not linked to INTA, say assign 00:1a.7 to guest as 00:4.0. It
>> should work, but seems doesn't comply with PCI spec.
>
> I had a vague memory that was the case,
> I have been meaning to check the spec.
>
>> We have 2 options here:
>> 1. always use INTA
>> 2. Use INTA for virtual function 0, and physical value for others.
>> Options 2 is more friendly to multiple-function device assignment,
>> and is current used.
>
> 2 seems to be a much better solution to me.
>
> Tom, could you see if Edwin's patch, without your patch, resolves
> the problem that you were seeing?
>
>> Tom Rotenberg wrote:
>> >Hi,
>> >
>> >I ran into similar problems last week, and i tried the following fix,
>> >which looks like it kind-of fixed it, does this do the same fix as
>> >your patch?
>> >
>> >Here is the patch i used:
>> >
>> >--- a/tools/ioemu/hw/pass-through.c Sun Dec 27 11:56:08 2009 +0200
>> >+++ b/tools/ioemu/hw/pass-through.c Sun Dec 27 11:56:08 2009 +0200
>> >@@ -4209,8 +4209,14 @@
>> > */
>> > uint8_t pci_intx(struct pt_dev *ptdev)
>> > {
>> > +#if 0 /* FIX */
>> > if (!PCI_FUNC(ptdev->dev.devfn))
>> > return 0;
>> > +#endif /* FIX */
>> > +
>> > return pci_read_intx(ptdev);
>> >}
>> >
>> >Tom
>> >
>> >On Mon, Dec 28, 2009 at 9:04 AM, Zhai, Edwin <edwin.zhai@xxxxxxxxx> wrote:
>> >>Simon,
>> >>For the pass-through device's INTx emulation, we follow the policy: if
>> >>virtual function 0, use INTA#, otherwise use hardware value. However, this
>> >>policy only apply when bind_pt_pci_irq to xen, and always use physical
>> >>value
>> >>when exporting to guest. This discrepancy cause different INTx, thus
>> >>different GSI in xen and guest, so that interrupts never got injected to
>> >>guest. E.g. when assigning a USB controller with non-zero function(00:1d.2)
>> >>to guest as 00:4.0, xen will see INTA#, while guest see INTC#.
>> >>
>> >>This simple patch can fix it. Could you pls. review it?
>> >>
>> >>Thanks,
>> >>
>> >>--
>> >>best rgds,
>> >>edwin
>> >>
>> >>
>> >>Signed-Off-By: Zhai Edwin <edwin.zhai@xxxxxxxxx>
>> >>
>> >>diff --git a/hw/pass-through.c b/hw/pass-through.c
>> >>index e7bd386..a08c0bf 100644
>> >>--- a/hw/pass-through.c
>> >>+++ b/hw/pass-through.c
>> >>@@ -2710,7 +2710,8 @@ static uint32_t pt_status_reg_init(struct pt_dev
>> >>*ptdev,
>> >> static uint32_t pt_irqpin_reg_init(struct pt_dev *ptdev,
>> >> struct pt_reg_info_tbl *reg, uint32_t real_offset)
>> >> {
>> >>- return ptdev->dev.config[real_offset];
>> >>+ /* Translate xen INTx value to hw */
>> >>+ return pci_intx(ptdev) + 1;
>> >> }
>> >>
>> >> /* initialize BAR */
>> >>
>> >>_______________________________________________
>> >>Xen-devel mailing list
>> >>Xen-devel@xxxxxxxxxxxxxxxxxxx
>> >>http://lists.xensource.com/xen-devel
>> >>
>> >>
>> >
>>
>> --
>> best rgds,
>> edwin
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home