> -----Original Message----- > From: Roger Pau Monne [mailto:roger....@citrix.com] > Sent: 20 April 2017 16:18 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > <roger....@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Wei Liu > <wei.l...@citrix.com>; Jan Beulich <jbeul...@suse.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Paul Durrant <paul.durr...@citrix.com> > Subject: [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses > to the PCI config space > > This functionality is going to reside in vpci.c (and the corresponding vpci.h > header), and should be arch-agnostic. The handlers introduced in this patch > setup the basic functionality required in order to trap accesses to the PCI > config space, and allow decoding the address and finding the corresponding > handler that should handle the access (although no handlers are > implemented). > > Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are setup > inside of a x86 HVM file, since that's not shared with other arches. > > A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen > whether > a domain should use the newly introduced vPCI handlers, this is only enabled > for PVH Dom0 at the moment. > > A very simple user-space test is also provided, so that the basic > functionality > of the vPCI traps can be asserted. This has been proven quite helpful during > development, since the logic to handle partial accesses or accesses that > expand > across multiple registers is not trivial. > > The handlers for the registers are added to a red-black tree, that indexes > them > based on their offset. Since Xen needs to handle partial accesses to the > registers and access that expand across multiple registers the logic in > xen_vpci_{read/write} is kind of convoluted, I've tried to properly comment > it > in order to make it easier to understand. >
Since config space is not exactly huge, I'm wondering why you used an r-b tree rather than a direct map from register to handler? Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel