From: Halil Pasic <pasic@linux.ibm.com>
To: "Wang, Wei W" <wei.w.wang@intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mst@redhat.com" <mst@redhat.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: RE: [PATCH v1 0/2] Virtio: fix some vq allocation issues
Date: Tue, 1 Jan 2019 00:40:19 +0100 [thread overview]
Message-ID: <20190101004019.7f20aafa@oc2783563651> (raw)
In-Reply-To: <286AC319A985734F985F78AFA26841F73DEEC8DF@shsmsx102.ccr.corp.intel.com>
On Mon, 31 Dec 2018 06:03:51 +0000
"Wang, Wei W" <wei.w.wang@intel.com> wrote:
> On Sunday, December 30, 2018 2:06 PM, Halil Pasic wrote:
> >
> > I guess you are the first one trying to read virtio config from within interrupt
> > context. AFAICT this never worked.
>
> I'm not sure about "never worked". It seems to work well with virtio-pci.
> But looking forward to hearing a solid reason why reading config inside
> the handler is forbidden (if that's true).
By "never worked" I meant "never worked with virtio-ccw". Sorry
about the misunderstanding. Seems I've also failed to convey that I don't
know if reading config inside the handler is forbidden or not. So please
don't expect me providing the solid reasons you are looking forward to.
>
> > About what happens. The apidoc of ccw_device_start() says it needs to be
> > called with the ccw device lock held, so ccw_io_helper() tries to take it (since
> > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and
> > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel
> > lock. That means when one tries to get virtio config form within a cio
> > interrupt context we deadlock, because we try to take a lock we already have.
> >
> > That said, I don't think this limitation is by design (i.e. intended).
> > Maybe Connie can help us with that question. AFAIK we have nothing
> > documented regarding this (neither that can nor can't).
> >
> > Obviously, there are multiple ways around this problem, and at the moment
> > I can't tell which would be my preferred one.
>
> Yes, it's also not difficult to tweak the virtio-balloon code to avoid that issue.
> But if that's just an issue with ccw itself, I think it's better to tweak ccw and
> remain virtio-balloon unchanged.
>
As I said, at the moment I don't have a preference regarding the fix,
partly because I'm not sure if "reading config inside the handler" is OK
or not. Maybe Connie or Michael can help us here. I'm however sure that
commit 86a5597 "virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT"
breaks virtio-balloon with the ccw transport (i.e. effectively breaks
virtio-balloon on s390): it used to work before and does not work
after.
AFAICT tweaking the balloon code may be simpler than tweaking the
virtio-ccw (transport code). ccw_io_helper() relies on getting
an interrupt when the issued IO is done. If virtio-ccw is buggy, it
needs to be fixed, but I'm not sure it is.
Regards,
Halil
next prev parent reply other threads:[~2018-12-31 23:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-28 2:26 [PATCH v1 0/2] Virtio: fix some vq allocation issues Wei Wang
2018-12-28 2:26 ` [PATCH v1 1/2] virtio_pci: use queue idx instead of array idx to set up the vq Wei Wang
2019-01-03 9:57 ` Cornelia Huck
2019-01-09 16:29 ` Christian Borntraeger
2018-12-28 2:26 ` [PATCH v1 2/2] virtio: don't allocate vqs when names[i] = NULL Wei Wang
2019-01-03 9:59 ` Cornelia Huck
2019-01-09 16:30 ` Christian Borntraeger
2018-12-28 7:57 ` [PATCH v1 0/2] Virtio: fix some vq allocation issues Christian Borntraeger
2018-12-29 2:45 ` Wang, Wei W
2018-12-30 6:06 ` Halil Pasic
2018-12-31 6:03 ` Wang, Wei W
2018-12-31 23:40 ` Halil Pasic [this message]
2019-01-02 9:53 ` Cornelia Huck
2019-01-02 13:23 ` Cornelia Huck
2019-01-02 15:59 ` Halil Pasic
2019-01-02 18:02 ` Cornelia Huck
2019-01-02 19:13 ` Halil Pasic
2019-01-02 13:56 ` Halil Pasic
2019-01-03 6:18 ` Wei Wang
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=20190101004019.7f20aafa@oc2783563651 \
--to=pasic@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wei.w.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox