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] Re: APIC rework

To: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: APIC rework
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Thu, 3 Dec 2009 09:38:14 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, "Keir@xxxxxxxxxxxxxxxxxxxx" <Keir@xxxxxxxxxxxxxxxxxxxx>, Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 03 Dec 2009 06:44:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <706158FABBBA044BAD4FE898A02E4BC201CF56AAA9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <C72970BC.C323%keir.fraser@xxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091124194401.GA29566@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A08EB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091125134144.GA2586@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD419316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091125180031.GA5531@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD419656@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091130143419.GB19527@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CF56AAA9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
> I am also confusing about how to assign a device to a PV guest. Originally  I 
> thought the logic should be it should be hidden first through pciback in 
> dom0, and pv guest uses its pci subsystem (pcifront end) to require pciback 
> to mapping this device.  In the first step, once pciback.hide logic is called 
> in dom0,  this device should be released by dom0 and avaliable for PV guests 
> at this time. And the in subsequent step, pciback or dom0's pci system should 
> help PV guests to do the irq mapping, otherwise I can't see how the irqs from 
> the assigned device are delivered to PV guests.   

That is correct. Here is an URL of the correct steps:

>From the unprivileged side (domU), when it makes a call to
pci_enable_device, it gets routed to pcifront_bus_write.
On the privileged side (dom0), pciback picks up the write
and routes it to 'command_write' (conf_space_header.c). It
does the pci_enable_device in the dom0 side. The pci_enable_device
ends up calling xen_allocate_pirq which gets the IRQ from
PHYSDEVOP_alloc_irq_vector. That IRQ is saved in dev->irq and
is visible to the DomU.

Also during the pci_enable_device (in the DomU side), pcibios_enable_device
gets called - which in domU is called 'xen_pcifront_enable_irq'.
The xen_pcifront_enable_irq allocates an irq_desc with xen_pirq_chip
structure. The GSI it requests is actually the IRQ number from dev->irq.

To summarize, dom0 on behalf of domU, calls PHYSDEVOP_alloc_irq_vector
for the device in question. Saves the GSI in dev->irq which is visible to
the DomU. DomU sets up a xen_pirq_chip structure for the device and
starts/stop/etc through that function structure. Please note that 
there is nothing in PHYSDEVOP_alloc..  about which domain owns the device.
That is only done with PHYSDEVOP_map_pirq calls.

With your patch instead of PHYSDEVOP_alloc_irq_vector, it would be

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>