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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
