All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] pc-bios/s390-ccw: Use memory barriers in virtio code
Date: Tue, 16 Feb 2021 15:49:57 +0100	[thread overview]
Message-ID: <20210216154957.1cc0afdf.cohuck@redhat.com> (raw)
In-Reply-To: <CAFEAcA8H=ixwj6PtGSDtEuiADY775o68gk8DZ5PrwOjftqtWtg@mail.gmail.com>

On Tue, 16 Feb 2021 14:37:22 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Tue, 16 Feb 2021 at 14:35, Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 16/02/2021 15.32, Peter Maydell wrote:  
> > > On Tue, 16 Feb 2021 at 14:30, Cornelia Huck <cohuck@redhat.com> wrote:  
> > >> Step 4 in "2.7.13 Supplying Buffers to The Device":
> > >>
> > >> "The driver performs a suitable memory barrier to ensure the device
> > >> sees the updated descriptor table and available ring before the next
> > >> step."  
> > >
> > > I thought that my first time through the spec as well, but
> > > I think the whole of section 2.7 is dealing with "packed virtqueues",
> > > which have to be explicitly negotiated and which I don't think
> > > the s390-ccw code is doing.  

2.7 is split, 2.8 packed (at least in my built-from-git version; maybe
I should have mentioned that :)

> >
> > Right. I think the s390-ccw code is still based on virtio v1.0, that's why I
> > also only looked at that version of the spec.  

Yes, the bios code is using split.

> I think the ideal would be to find somebody who's really well
> acquainted with the virtio spec (MST?) and ask them to have
> a quick look-over the s390-ccw code to say where it needs
> changes... The fact that this patch doesn't completely fix
> the bug leaves me suspicious that we're missing something in
> our readings of the spec.

Unfortunately, the bios virtio code is not that easy to follow :/



  reply	other threads:[~2021-02-16 14:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 11:00 [PATCH] pc-bios/s390-ccw: Use memory barriers in virtio code Thomas Huth
2021-02-16 11:43 ` Peter Maydell
2021-02-16 11:47   ` Thomas Huth
2021-02-16 11:47 ` Cornelia Huck
2021-02-16 14:21   ` Thomas Huth
2021-02-16 14:30     ` Cornelia Huck
2021-02-16 14:32       ` Peter Maydell
2021-02-16 14:35         ` Thomas Huth
2021-02-16 14:37           ` Peter Maydell
2021-02-16 14:49             ` Cornelia Huck [this message]
2021-02-16 14:40 ` Halil Pasic
2021-02-16 15:17   ` Cornelia Huck
2021-02-16 16:15   ` Thomas Huth
2021-02-16 16:44     ` Peter Maydell
2021-02-16 17:11     ` Halil Pasic
2021-02-17  4:31     ` Richard Henderson
2021-02-17 11:15       ` Peter Maydell
2021-02-17 15:11         ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210216154957.1cc0afdf.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.