[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space
On Wed, Oct 04, 2017 at 09:54:18AM +0000, Jan Beulich wrote: > >>> On 04.10.17 at 11:24, <roger.pau@xxxxxxxxxx> wrote: > > On Wed, Oct 04, 2017 at 08:30:38AM +0000, Jan Beulich wrote: > >> >>> On 19.09.17 at 17:29, <roger.pau@xxxxxxxxxx> wrote: > >> > +static int vpci_portio_read(const struct hvm_io_handler *handler, > >> > + uint64_t addr, uint32_t size, uint64_t > >> > *data) > >> > +{ > >> > + struct domain *d = current->domain; > >> > + unsigned int reg; > >> > + pci_sbdf_t sbdf; > >> > + uint32_t cf8; > >> > + > >> > + *data = ~(uint64_t)0; > >> > + > >> > + if ( addr == 0xcf8 ) > >> > + { > >> > + ASSERT(size == 4); > >> > + *data = d->arch.hvm_domain.pci_cf8; > >> > + return X86EMUL_OKAY; > >> > + } > >> > + > >> > + cf8 = ACCESS_ONCE(d->arch.hvm_domain.pci_cf8); > >> > + if ( !CF8_ENABLED(cf8) ) > >> > + return X86EMUL_OKAY; > >> > >> Why is this OKAY instead of UNHANDLEABLE? The access is supposed to be > >> forwarded to qemu if it's not a config space one. Same in the write path > >> then. > > > > No, I don't think this should be forwarded to QEMU. It is a config > > space access (because vpci_portio_accept returned true). But the value > > in CF8 doesn't have the enabled bit set, hence the access is > > discarded. > > With the enable bit clear it is my understanding that this is then > _not_ a config space access. vpci_portio_accept() simply doesn't > have enough information to tell. OK, it was my understanding that accesses to cf8/cfc where only used by the PCI config space. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |