From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJgH1-0006IX-Cu for qemu-devel@nongnu.org; Fri, 18 May 2018 10:22:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fJgGy-0007lC-8v for qemu-devel@nongnu.org; Fri, 18 May 2018 10:22:23 -0400 Received: from smtp.eu.citrix.com ([185.25.65.24]:16185) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fJgGx-0007k1-UU for qemu-devel@nongnu.org; Fri, 18 May 2018 10:22:20 -0400 From: Paul Durrant Date: Fri, 18 May 2018 14:22:18 +0000 Message-ID: References: <1526648406-1746-1-git-send-email-paul.durrant@citrix.com> <5AFED64102000078001C4069@prv1-mh.provo.novell.com> <5AFEE01F02000078001C4100@prv1-mh.provo.novell.com> In-Reply-To: <5AFEE01F02000078001C4100@prv1-mh.provo.novell.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PCI config space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Jan Beulich' Cc: Anthony Perard , Roger Pau Monne , Stefano Stabellini , xen-devel , "qemu-devel@nongnu.org" , "ehabkost@redhat.com" , "marcel@redhat.com" , "mst@redhat.com" , Paolo Bonzini , Richard Henderson > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: 18 May 2018 15:16 > To: Paul Durrant > Cc: Anthony Perard ; Roger Pau Monne > ; Stefano Stabellini ; xen- > devel ; qemu-devel@nongnu.org; > ehabkost@redhat.com; marcel@redhat.com; mst@redhat.com; Paolo > Bonzini ; Richard Henderson > Subject: RE: [Xen-devel] [PATCH v2] xen-hvm: stop faking I/O to access PC= I > config space >=20 > >>> On 18.05.18 at 15:51, wrote: > >> Sent: 18 May 2018 14:34 > >> To: Paul Durrant > >> >>> On 18.05.18 at 15:00, wrote: > >> > + QLIST_FOREACH(xendev, &state->dev_list, entry) { > >> > + unsigned int i; > >> > + uint32_t tmp; > >> > + > >> > + if (xendev->sbdf !=3D sbdf) { > >> > + continue; > >> > + } > >> > + > >> > + if (!req->data_is_ptr) { > >> > + if (req->dir =3D=3D IOREQ_READ) { > >> > + for (i =3D 0; i < req->count; i++) { > >> > + rw_config_req_item(xendev, req, i, &tmp); > >> > + req->data =3D tmp; > >> > + } > >> > + } else if (req->dir =3D=3D IOREQ_WRITE) { > >> > + for (i =3D 0; i < req->count; i++) { > >> > + tmp =3D req->data; > >> > + rw_config_req_item(xendev, req, i, &tmp); > >> > + } > >> > + } > >> > >> Wouldn't it be more sensible to fail req->count !=3D 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. >=20 > For the data_is_ptr case - sure. But here? Or wait - are you thinking abo= ut > REP STOS (and the relatively useless REP LODS)? >=20 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 o= uts to cfc so just aborting on count > 1 is probably fine. Paul > Jan >=20