Re: [Xen-devel] [PATCH v2 02/11] ioreq: terminate cf8 handling at hypervisor level

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Sep 03, 2019 at 06:13:59PM +0100, Andrew Cooper wrote:
> On 03/09/2019 17:14, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> > index 692b710b02..69652e1080 100644
> > --- a/xen/arch/x86/hvm/ioreq.c
> > +++ b/xen/arch/x86/hvm/ioreq.c
> > @@ -1015,6 +1015,12 @@ int hvm_map_io_range_to_ioreq_server(struct domain 
> > *d, ioservid_t id,
> >      switch ( type )
> >      {
> >      case XEN_DMOP_IO_RANGE_PORT:
> > +        rc = -EINVAL;
> > +        /* PCI config space accesses are handled internally. */
> > +        if ( start <= 0xcf8 + 8 && 0xcf8 <= end )
> > +            goto out;
> > +        else
> > +            /* fallthrough. */
> 
> You need to drop the else, or it may still trigger warnings.

Yes, my mistake. The else branch is not needed.

> Furthermore, qemu registers cf8-cff so I think you need some fix-ups
> there first before throwing errors back here.

The version of QEMU I have doesn't seem to register 0xcf8 or 0xcfc,
there are no errors on the log and QEMU seems to work just fine.

I always assumed QEMU was getting accesses to cf8/cfc forwarded
because it was the default device model, and everything not trapped by
Xen would be forwarded to it. This default device model behaviour was
removed by Paul some time ago, and now QEMU registers explicitly which
IO accesses it wants to trap.

> Finally, this prohibits registering cf9 which may legitimately not be
> terminated in Xen.

Yes, that should be cf8 - 7 not 8, thanks for catching it! Will update
on the next version.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel