Re: [PATCH v4 13/14] arm/libxl: Emulated PCI device tree node in libxl

[Rahul Singh <Rahul.Singh@xxxxxxx>]

Hi Ian

> On 7 Oct 2021, at 11:50 am, Ian Jackson <iwj@xxxxxxxxxxxxxx> wrote:
> 
> Rahul Singh writes ("Re: [PATCH v4 13/14] arm/libxl: Emulated PCI device tree 
> node in libxl"):
>> On 6 Oct 2021, at 12:33 pm, Ian Jackson <iwj@xxxxxxxxxxxxxx> wrote:
>>> We try
>>> to make the libxl API "do the right thing" by default.  In this case I
>>> think that means to enable VPCI (i) on platforms where it's available
>>> (ii) if the guest has PCI passthrough devices.  Is that right ?
>> 
>> Yes you are right VPCI will be enabled for guest when guest has PCI 
>> passthrough device 
>> assigned and VPCI support is available.  
>>> 
>>> Sorry to ask these question now, and please forgive my ignorance:
>>> 
>>> Is VPCI inherently an ARM-specific ABI or protocol ?
>> 
>> As of now VPCI for DOMU guests is only implemented  for ARM.
> 
> I'm sorry.  It appears that the thrust of my questions wasn't
> sufficiently clear.  Your replies about details are fine but they
> don't seem to address my underlying concerns.
> 
> "as of now ... only implemented for ARM" suggests to me that it is
> VPCI *not* inherently ARM-specific.  Ie, it is a thing that x86 (or
> riscv or whatever) might support in future.  Is that right ?

Sorry for the confusion VPCI is not ARM inherently specific. x86 or RISC might 
support 
VPCI in the future for DOMU guests.

> 
> How does VPCI fit into the whole system architecture ?  Is it
> *required* for PCI passthrough on ARM ?  If not, what happens if it is
> not enabled ?

VPCI implements the virtual PCI bus topology through IO emulation in XEN. 
Emulated device tree 
node will be created for the DOMU guests and all the access to the config space 
will be a trap to 
XEN.I/O memory regions for the device will be mapped to the guest and MSI/MSIX 
interrupts will 
be redirected to the guest.
 
Yes VPCI is mandatory for PCI passthrough on ARM. If it is not enabled we will 
not be
 able to pass through any PCI device to the guest.

> 
> If VPCI *is* ARM-specific, how do x86 systems (say) achieve the goals
> met on ARM by VPCI ?

On the x86 system, QEMU emulates the PCI bus topology and PV drivers used for 
communication.
> 
> On the other hand if VPCI is not inherently ARM-specific it should not
> be in the ARM part of the libxl IDL.
> 
>>> When might an
>>> admin want to turn it on explicitly ?
>> 
>> It will be enabled dynamically when admin assign any PCI device to guest.
> 
> What about hotplug ?

As of now hotplug is not implemented and tested. We might implement 
the hotplug in future..

> 
>>> How does this all relate to the (non-arch-specific) "passthrough"
>>> option ?
>> 
>> VPCI will be enabled only when there is any PCI device assigned to
>> guest therefore I used "d_config->num_pcidevsïżœ to enable VPCI.
> 
> The purpose of the "passthrough" option is to allow the guest admin to
> specify that a guest is expected to gain hotplugged PCI devices in
> future.  That way, domain features that are required for PCI
> passthrough are automatically enabled.

Once we implement the hotplug feature we will use the "passthrough=“ options.
> 
> Perhaps this isn't explained clearly enough in the documentation,
> which talks about iommu mappings.
> 
> Does PCI passthrugh work on ARM without VPCI ?

VPCI is required on ARM for PCI passthrough.

Regards,
Rahul
> 
> I think it likely that VPCI should be controlled (or at least, its
> default set) from the "passthrough" option.  But I don't understand
> enough of the relationship between the pieces.
> 
> Ian.