qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to acce


From: Paul Durrant
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PCI config space
Date: Fri, 18 May 2018 14:22:18 +0000

> -----Original Message-----
> From: Jan Beulich [mailto:address@hidden
> Sent: 18 May 2018 15:16
> To: Paul Durrant <address@hidden>
> Cc: Anthony Perard <address@hidden>; Roger Pau Monne
> <address@hidden>; Stefano Stabellini <address@hidden>; xen-
> devel <address@hidden>; address@hidden;
> address@hidden; address@hidden; address@hidden; Paolo
> Bonzini <address@hidden>; Richard Henderson <address@hidden>
> Subject: RE: [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PCI
> config space
> 
> >>> On 18.05.18 at 15:51, <address@hidden> wrote:
> >> Sent: 18 May 2018 14:34
> >> To: Paul Durrant <address@hidden>
> >> >>> On 18.05.18 at 15:00, <address@hidden> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]