Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PCI config space

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 18 May 2018 15:16
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Anthony Perard <anthony.perard@citrix.com>; Roger Pau Monne
> <roger.pau@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; xen-
> devel <xen-devel@lists.xenproject.org>; qemu-devel@nongnu.org;
> ehabkost@redhat.com; marcel@redhat.com; mst@redhat.com; Paolo
> Bonzini <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>
> Subject: RE: [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PCI
> config space
> 
> >>> On 18.05.18 at 15:51, <Paul.Durrant@citrix.com> wrote:
> >> Sent: 18 May 2018 14:34
> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> >>> On 18.05.18 at 15:00, <paul.durrant@citrix.com> wrote:
> >> > +    QLIST_FOREACH(xendev, &state->dev_list, entry) {
> >> > +        unsigned int i;
> >> > +        uint32_t tmp;
> >> > +
> >> > +        if (xendev->sbdf != sbdf) {
> >> > +            continue;
> >> > +        }
> >> > +
> >> > +        if (!req->data_is_ptr) {
> >> > +            if (req->dir == IOREQ_READ) {
> >> > +                for (i = 0; i < req->count; i++) {
> >> > +                    rw_config_req_item(xendev, req, i, &tmp);
> >> > +                    req->data = tmp;
> >> > +                }
> >> > +            } else if (req->dir == IOREQ_WRITE) {
> >> > +                for (i = 0; i < req->count; i++) {
> >> > +                    tmp = req->data;
> >> > +                    rw_config_req_item(xendev, req, i, &tmp);
> >> > +                }
> >> > +            }
> >>
> >> Wouldn't it be more sensible to fail req->count != 1 requests here?
> >>
> >
> > I'm wondering whether we'd want to handle count > 1 once we allow
> MMCONFIG
> > accesses though. I guess it would be easier just to defer that.
> 
> For the data_is_ptr case - sure. But here? Or wait - are you thinking about
> REP STOS (and the relatively useless REP LODS)?
> 

Yes. We'd need to cope with a rep stos if we had memory mapped access, but we don't need to worry about it until then I think.

In the meantime I doubt any well behaved OS is going to do rep ins or rep outs to cfc so just aborting on count > 1 is probably fine.

  Paul

> Jan
>