[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 0/9] vpci: PCI config space emulation



>>> On 27.04.17 at 16:35, <roger.pau@xxxxxxxxxx> wrote:
> The following series contain an implementation of handlers for the PCI
> configuration space inside of Xen. This allows Xen to detect accesses to the
> PCI configuration space and react accordingly.
> 
> Although there hasn't been a lot of review on the previous version, I send 
> this
> new version because I will be away for > 1 week, and I would rather have 
> review
> on this version than the old one. As usual, each patch contains a changeset
> summary between versions.
> 
> Patch 1 implements the generic handlers for accesses to the PCI configuration
> space together with a minimal user-space test harness that I've used during
> development. Currently a per-device red-back tree is used in order to store 
> the
> list of handlers, and they are indexed based on their offset inside of the
> configuration space. Patch 1 also adds the x86 port IO traps and wires them
> into the newly introduced vPCI dispatchers. Patch 2 adds handlers for the ECAM
> areas (as found on the MMCFG ACPI table). Patches 3 and 4 are mostly code
> moment/refactoring in order to implement support for BAR mapping in patch 5.
> Patch 6 allows Xen to mask certain PCI capabilities on-demand, which is used 
> in
> order to mask MSI and MSI-X.
> 
> Finally patches 8 and 9 implement support in order to emulate the MSI/MSI-X
> capabilities inside of Xen, so that the interrupts are transparently routed to
> the guest.

While the code looks reasonable for this early stage, it's still quite
large a chunk of new logic. Therefore I think that if already there
was no prior design discussion, some reasoning behind the decisions
you've taken should be provided here. In particular I'm quite
unhappy about this huge amount of intercepting and emulation,
none of which we require for PV Dom0. IOW I continue to be
unconvinced that putting all the burden on Xen while not para-
virtualizing any of this in the Dom0 kernel is the right choice. It
certainly would be if we were talking about HVM Dom0, but this is
PVH, and the "PV" part is first there for a reason.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.