Re: [Query] Flow of PCI device dedicated to a domU

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3203 bytes --]

On 22/07/14 11:13, Xenbegn developer wrote:
>
>
>
> On Tue, Jul 22, 2014 at 3:26 PM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
>     On 22/07/14 10:50, Xenbegn developer wrote:
>>
>>
>>
>>     On Wed, Jul 16, 2014 at 3:20 PM, Andrew Cooper
>>     <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>>
>>         On 16/07/14 07:12, Xenbegn developer wrote:
>>>         Hi,
>>>         I am trying to understand the flow of how a PCI device
>>>         driver in domU works after a PCI device is is assigned to a
>>>         domU.
>>>
>>>         a) If a PCI device is assigned to a domU, this device has to
>>>         be on a PCI bus. So as per my view xen would have to somehow
>>>         provide a PCI Controller on which this device is attached.
>>>         => Is my assumption correct ? If yes how it is done, No then
>>>         also How enumeration of this device happens in domU kernel
>>
>>         No.
>>
>>         PV guests have no PCI root ports/bridges; they use devices as
>>         single entities knowing that Xen/dom0 takes care of the other
>>         bits. HVM guests have their PCI devices attached to the
>>         virtual southbridge which is all emulated by Qemu.
>>
>>
>>>
>>>         b) Is the Configuration space of the PCI device directly
>>>         accessible to the domU (assuming the kernel accesses it
>>>         using memory map) ? If not then it is trapped by xen
>>
>>         All configuration space is trap+emulate in Xen, although
>>         almost all operations permitted.
>>
>>
>>>
>>>         c) Who assigns the MSI (addr + value) in the PCI device. If
>>>         Xen then how Xen does a translation from Physical MSI to
>>>         guest MSI (where in code)
>>
>>         Xen controls all interrupts on the system, which is why it
>>         needs to trap all config accesses to notice when a domain is
>>         attempting to change the interrupt information.  In that
>>         case, Xen fixes up its delivery of interrupts to the guest,
>>         but leaves the underlying interrupt information intact.
>>
>>         ~Andrew
>>
>>
>>     Linux kernel pci code has a function called __write_msi_msg. This
>>     method writes to config space for MSI/MSIX
>>     pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_LO,
>>                            msg->address_lo);
>>
>>     Now as per (b) and (c) it has to be trapped in xen. But in
>>     x86/traps.c (guest_io_write) I dont see any MSI handling.
>>     Can you please explain (point to the code) where domain is
>>     attempting to change the interrupt information.
>>        
>>
>
>     PV guests are expected to use PHYSOP hypercalls for interrupt
>     management.  Xen does not provide transparent emulation support
>     for them.
>
>     HVM guests do get transparent emulation support, as from the point
>     of view of an HVM guest, they are talking to a real PCI device.
>
> Can you please point to a device driver code which is calling PHYSOP
> calls for setting an MSI Addr + MSI number

No.  Partly because I don't know exactly, and mainly because this is
something you should trivially be able to search for.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 10921 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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