From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH qemu-trad] HVM: atomically access pointers in bufioreq handling Date: Mon, 22 Jun 2015 12:50:25 +0100 Message-ID: <558812A1020000780008778E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDDE90291.1__=" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z70FD-000294-Eq for xen-devel@lists.xenproject.org; Mon, 22 Jun 2015 11:50:31 +0000 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel Cc: Ian Jackson List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDDE90291.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The number of slots per page being 511 (i.e. not a power of two) means that the (32-bit) read and write indexes going beyond 2^32 will likely disturb operation. The hypervisor side gets I/O req server creation extended so we can indicate that we're using suitable atomic accesses where needed (not all accesses to the two pointers really need to be atomic), allowing it to atomically canonicalize both pointers when both have gone through at least one cycle. The Xen side counterpart (which is not a functional prereq to this change, albeit the intention is for Xen to assume default servers always use suitable atomic accesses) can be found at e.g. http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02996.html= =20 Signed-off-by: Jan Beulich --- a/i386-dm/helper2.c +++ b/i386-dm/helper2.c @@ -493,10 +493,19 @@ static int __handle_buffered_iopage(CPUS =20 memset(&req, 0x00, sizeof(req)); =20 - while (buffered_io_page->read_pointer !=3D - buffered_io_page->write_pointer) { - buf_req =3D &buffered_io_page->buf_ioreq[ - buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM]; + for (;;) { + uint32_t rdptr =3D buffered_io_page->read_pointer, wrptr; + + xen_rmb(); + wrptr =3D buffered_io_page->write_pointer; + xen_rmb(); + if (rdptr !=3D buffered_io_page->read_pointer) { + continue; + } + if (rdptr =3D=3D wrptr) { + break; + } + buf_req =3D &buffered_io_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT= _NUM]; req.size =3D 1UL << buf_req->size; req.count =3D 1; req.addr =3D buf_req->addr; @@ -508,15 +517,14 @@ static int __handle_buffered_iopage(CPUS req.data_is_ptr =3D 0; qw =3D (req.size =3D=3D 8); if (qw) { - buf_req =3D &buffered_io_page->buf_ioreq[ - (buffered_io_page->read_pointer+1) % IOREQ_BUFFER_SLOT_NUM= ]; + buf_req =3D &buffered_io_page->buf_ioreq[(rdptr + 1) % + IOREQ_BUFFER_SLOT_NUM];= req.data |=3D ((uint64_t)buf_req->data) << 32; } =20 __handle_ioreq(env, &req); =20 - xen_mb(); - buffered_io_page->read_pointer +=3D qw ? 2 : 1; + __sync_fetch_and_add(&buffered_io_page->read_pointer, qw + 1); } =20 return req.count; --=__PartDDE90291.1__= Content-Type: text/plain; name="qemut-bufioreq-atomic-add.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemut-bufioreq-atomic-add.patch" HVM: atomically access pointers in bufioreq handling=0A=0AThe number of = slots per page being 511 (i.e. not a power of two) means=0Athat the = (32-bit) read and write indexes going beyond 2^32 will likely=0Adisturb = operation. The hypervisor side gets I/O req server creation=0Aextended so = we can indicate that we're using suitable atomic accesses=0Awhere needed = (not all accesses to the two pointers really need to be=0Aatomic), = allowing it to atomically canonicalize both pointers when both=0Ahave gone = through at least one cycle.=0A=0AThe Xen side counterpart (which is not a = functional prereq to this=0Achange, albeit the intention is for Xen to = assume default servers=0Aalways use suitable atomic accesses) can be found = at e.g.=0Ahttp://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02= 996.html=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/i386-dm/helper2.c=0A+++ b/i386-dm/helper2.c=0A@@ -493,10 +493,19 @@ = static int __handle_buffered_iopage(CPUS=0A =0A memset(&req, 0x00, = sizeof(req));=0A =0A- while (buffered_io_page->read_pointer !=3D=0A- = buffered_io_page->write_pointer) {=0A- buf_req =3D &buffered_= io_page->buf_ioreq[=0A- buffered_io_page->read_pointer % = IOREQ_BUFFER_SLOT_NUM];=0A+ for (;;) {=0A+ uint32_t rdptr =3D = buffered_io_page->read_pointer, wrptr;=0A+=0A+ xen_rmb();=0A+ = wrptr =3D buffered_io_page->write_pointer;=0A+ xen_rmb();=0A+ = if (rdptr !=3D buffered_io_page->read_pointer) {=0A+ = continue;=0A+ }=0A+ if (rdptr =3D=3D wrptr) {=0A+ = break;=0A+ }=0A+ buf_req =3D &buffered_io_page->buf_ioreq[rdp= tr % IOREQ_BUFFER_SLOT_NUM];=0A req.size =3D 1UL << buf_req->size;= =0A req.count =3D 1;=0A req.addr =3D buf_req->addr;=0A@@ = -508,15 +517,14 @@ static int __handle_buffered_iopage(CPUS=0A = req.data_is_ptr =3D 0;=0A qw =3D (req.size =3D=3D 8);=0A = if (qw) {=0A- buf_req =3D &buffered_io_page->buf_ioreq[=0A- = (buffered_io_page->read_pointer+1) % IOREQ_BUFFER_SLOT_NUM];=0A+= buf_req =3D &buffered_io_page->buf_ioreq[(rdptr + 1) %=0A+ = IOREQ_BUFFER_SLOT_NUM];=0A = req.data |=3D ((uint64_t)buf_req->data) << 32;=0A }=0A = =0A __handle_ioreq(env, &req);=0A =0A- xen_mb();=0A- = buffered_io_page->read_pointer +=3D qw ? 2 : 1;=0A+ __sync_fetch_and= _add(&buffered_io_page->read_pointer, qw + 1);=0A }=0A =0A return = req.count;=0A --=__PartDDE90291.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartDDE90291.1__=--