| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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:
http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module
>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
PHYSDEVOP_map_pirq.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home