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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 18 May 2018 15:16
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; Roger Pau Monne
> <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; qemu-devel@xxxxxxxxxx;
> ehabkost@xxxxxxxxxx; marcel@xxxxxxxxxx; mst@xxxxxxxxxx; Paolo
> Bonzini <pbonzini@xxxxxxxxxx>; Richard Henderson <rth@xxxxxxxxxxx>
> 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@xxxxxxxxxx> wrote:
> >> Sent: 18 May 2018 14:34
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> >>> On 18.05.18 at 15:00, <paul.durrant@xxxxxxxxxx> 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
> 


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