> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 May 2018 15:16 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Anthony Perard <anthony.per...@citrix.com>; Roger Pau Monne > <roger....@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; xen- > devel <xen-de...@lists.xenproject.org>; qemu-devel@nongnu.org; > ehabk...@redhat.com; mar...@redhat.com; m...@redhat.com; Paolo > Bonzini <pbonz...@redhat.com>; Richard Henderson <r...@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.durr...@citrix.com> wrote: > >> Sent: 18 May 2018 14:34 > >> To: Paul Durrant <paul.durr...@citrix.com> > >> >>> On 18.05.18 at 15:00, <paul.durr...@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 >
