This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] domU guest for xcp 0.1.1

To: Ritu kaur <ritu.kaur.us@xxxxxxxxx>
Subject: Re: [Xen-devel] domU guest for xcp 0.1.1
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 18 Mar 2010 14:27:04 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Mar 2010 07:27:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <29b32d341003180723l652adb4bvb3b3aba3d8f3a529@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <29b32d341003141329v3c6a73c0y8030cf3c6736634c@xxxxxxxxxxxxxx> <29b32d341003150646o4d215dfel1c2a2bc6d287edc@xxxxxxxxxxxxxx> <29b32d341003151904m2a992be5s74697d6047b864c6@xxxxxxxxxxxxxx> <1268725069.8652.4179.camel@xxxxxxxxxxxxxxxxxxxxx> <20100316152259.GO1878@xxxxxxxxxxx> <29b32d341003161625w2969f2daib3408561920793d3@xxxxxxxxxxxxxx> <29b32d341003171144k628a7741x17b6658731f96e4b@xxxxxxxxxxxxxx> <1268903824.10129.38718.camel@xxxxxxxxxxxxxxxxxxxxxx> <29b32d341003180643o326f7f43h97c25bd104f3b658@xxxxxxxxxxxxxx> <1268921503.10129.39640.camel@xxxxxxxxxxxxxxxxxxxxxx> <29b32d341003180723l652adb4bvb3b3aba3d8f3a529@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2010-03-18 at 14:23 +0000, Ritu kaur wrote:
> Thanks Ian, could you please clarify me how are interrupts handled for
> pci passthrough device. I thought it is delivered via evtchn from
> pciback to pcifront i.e
> InterruptDescTable->Hypervisor->pciback->pcifront->actual_device is
> this correct?

Yes, but not on the event channel you found previously, there is a
separate one for each device IRQ.

> IRQ is 11 in dom0 for nic device but after driver for nic is loaded in
> domU IRQ is changed to 17.

That's expected, there isn't really any relationship between the IRQ
assignment in the guest and domain 0.

>  When you say try with another device should I try with another nic
> device or someother device?

Any device which doesn't share an IRQ with another, it doesn't really
matter what sort of device it is. NICs are often a convenient choice
since they are relatively easy to confirm they are working.


> Thanks
> On Thu, Mar 18, 2010 at 7:11 AM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxx> wrote:
>         On Thu, 2010-03-18 at 13:43 +0000, Ritu kaur wrote:
>         > Hi Ian.
>         >
>         >  pcifront_handler_aer is the callback function.
>         This is not the same interrupt/evtchn as your device's
>         interrupt though.
>         This is the PCI error handling notification interrupt (PCI AER
>         is PCI
>         Advanced Error Reporting).
>         [...]
>         > Yes my nic device is sharing interrupts(IRQ17) with usb and
>         ide
>         > devices in dom0.
>         This may be your problem, I don't know if this is expected to
>         work or
>         not.
>         You could experiment with another device which doesn't share
>         an
>         interrupt, just to check that the basic mechanism is working.
>         Ian.

Xen-devel mailing list