From: Richard Yao <ryao@gentoo.org>
To: Christopher Covington <cov@codeaurora.org>
Cc: kernel@gentoo.org, v9fs-developer@lists.sourceforge.net,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org
Subject: Re: QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Date: Tue, 26 Nov 2013 10:47:32 -0500 [thread overview]
Message-ID: <5294C294.9000004@gentoo.org> (raw)
In-Reply-To: <5294C05C.20802@gentoo.org>
[-- Attachment #1.1: Type: text/plain, Size: 2077 bytes --]
I have this bad habit of not reviewing emails until after I send them.
Anyway, Chris, thanks for your offer of help, but I can handle this on
my own. The previous email was mostly to give you an early version of
the patch and let you know what I plan to do to improve upon it before I
propose some version of this patch to the appropriate subsystem
maintainer(s).
On 11/26/2013 10:38 AM, Richard Yao wrote:
> Christopher,
>
> It sounds like you disabled zero-copy entirely, which is not necessary.
> As far as I recall, loading kernel modules is the only case in which
> valloc() allocated buffers are used. In the worst case, we only need to
> disable zero-copy on such buffers. I have been using a small patch to do
> precisely that since yesterday. I have attached it to this email since
> it sounds like the first version might be helpful to others while I take
> the time to explore a few loose ends.
>
> That being said, I would like to investigate a couple of things before I
> send either this patch or some variant of it to the appropriate
> subsystem maintainer. First, I need to review the valloc() routines to
> ensure that range checking against [VMALLOC_START, VMALLOC_END) is the
> correct way to identify valloc() generated buffers. Second, I want to
> explore the feasibility of a suggestion by Alexander Graf to instead
> rework the zero-copy to properly handle valloc() allocated buffers.
> Yours truly,
> Richard Yao
>
> On 11/26/2013 10:16 AM, Christopher Covington wrote:
>> Hi Richard,
>>
>> On 11/25/2013 04:50 PM, Richard Yao wrote:
>>> I figured out the problem. There is zerocopy IO is being done via DMA to
>>> a buffer allocated with valloc(). Right now, I am running a hack-fix
>>> locally so I can get some other stuff done first. I will propose a
>>> proper fix to the list in a few days.
>>
>> I've also encountered this issue on a non-QEMU simulator and have been
>> carrying a disable-zero-copy hack for a few months. Let me know if there's
>> anything I can help with.
>>
>> Christopher
>>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Richard Yao <ryao@gentoo.org>
To: Christopher Covington <cov@codeaurora.org>
Cc: kernel@gentoo.org, v9fs-developer@lists.sourceforge.net,
agraf@suse.de, qemu-devel@nongnu.org,
virtualization@lists.linux-foundation.org
Subject: Re: [Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Date: Tue, 26 Nov 2013 10:47:32 -0500 [thread overview]
Message-ID: <5294C294.9000004@gentoo.org> (raw)
In-Reply-To: <5294C05C.20802@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
I have this bad habit of not reviewing emails until after I send them.
Anyway, Chris, thanks for your offer of help, but I can handle this on
my own. The previous email was mostly to give you an early version of
the patch and let you know what I plan to do to improve upon it before I
propose some version of this patch to the appropriate subsystem
maintainer(s).
On 11/26/2013 10:38 AM, Richard Yao wrote:
> Christopher,
>
> It sounds like you disabled zero-copy entirely, which is not necessary.
> As far as I recall, loading kernel modules is the only case in which
> valloc() allocated buffers are used. In the worst case, we only need to
> disable zero-copy on such buffers. I have been using a small patch to do
> precisely that since yesterday. I have attached it to this email since
> it sounds like the first version might be helpful to others while I take
> the time to explore a few loose ends.
>
> That being said, I would like to investigate a couple of things before I
> send either this patch or some variant of it to the appropriate
> subsystem maintainer. First, I need to review the valloc() routines to
> ensure that range checking against [VMALLOC_START, VMALLOC_END) is the
> correct way to identify valloc() generated buffers. Second, I want to
> explore the feasibility of a suggestion by Alexander Graf to instead
> rework the zero-copy to properly handle valloc() allocated buffers.
> Yours truly,
> Richard Yao
>
> On 11/26/2013 10:16 AM, Christopher Covington wrote:
>> Hi Richard,
>>
>> On 11/25/2013 04:50 PM, Richard Yao wrote:
>>> I figured out the problem. There is zerocopy IO is being done via DMA to
>>> a buffer allocated with valloc(). Right now, I am running a hack-fix
>>> locally so I can get some other stuff done first. I will propose a
>>> proper fix to the list in a few days.
>>
>> I've also encountered this issue on a non-QEMU simulator and have been
>> carrying a disable-zero-copy hack for a few months. Let me know if there's
>> anything I can help with.
>>
>> Christopher
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2013-11-26 15:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 15:49 [Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs Richard Yao
2013-11-25 21:50 ` Richard Yao
2013-11-25 21:50 ` [Qemu-devel] " Richard Yao
2013-11-26 15:16 ` Christopher Covington
2013-11-26 15:16 ` [Qemu-devel] " Christopher Covington
2013-11-26 15:38 ` Richard Yao
2013-11-26 15:38 ` [Qemu-devel] " Richard Yao
2013-11-26 15:47 ` Richard Yao [this message]
2013-11-26 15:47 ` Richard Yao
2014-08-21 19:50 ` Christopher Covington
2014-08-21 19:50 ` Christopher Covington
2014-08-22 3:00 ` Richard Yao
2014-08-22 3:00 ` Richard Yao
2014-08-22 6:27 ` [Qemu-devel] [V9fs-developer] " Dominique Martinet
2014-08-22 12:37 ` [V9fs-developer] [Qemu-devel] " Christopher Covington
2014-08-22 12:37 ` [Qemu-devel] [V9fs-developer] " Christopher Covington
2014-08-22 12:49 ` Dominique Martinet
2014-08-22 17:54 ` [V9fs-developer] [Qemu-devel] " Christopher Covington
2014-08-22 17:54 ` [Qemu-devel] [V9fs-developer] " Christopher Covington
-- strict thread matches above, loose matches on Subject: below --
2013-11-25 15:49 Richard Yao
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=5294C294.9000004@gentoo.org \
--to=ryao@gentoo.org \
--cc=cov@codeaurora.org \
--cc=kernel@gentoo.org \
--cc=qemu-devel@nongnu.org \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=virtualization@lists.linux-foundation.org \
/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.