Re: [Xen-devel] [PATCH v6 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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