similar to: Setting up VHost without QEMU?

On Tue, 7 Jul 2015 10:52:01 +0900 Ganis Zulfa Santoso <ganis.zulfa at gmail.com> wrote: > Hi Linux Virtualization Mailing List Members, > > I am trying to develop a driver for virtio blk device in guest. Why don't you simply use the driver that is already available in the kernel? > I can safely mount the virtual blk device with: mount /dev/vda /mnt/ > in /mnt/ I can

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 51ce50c54895044f949129e595ed9a37e4d6c13a commit: 51ce50c54895044f949129e595ed9a37e4d6c13a [14/14] vhost: new device IOTLB API config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 51ce50c54895044f949129e595ed9a37e4d6c13a commit: 51ce50c54895044f949129e595ed9a37e4d6c13a [14/14] vhost: new device IOTLB API config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget

Hi,I am looking to experiment the vhost-blk stack. Can some one point me to the latest code version and the corresponding qemu version location.I am on centos 7 (3.10 ) kernel. I am hoping using the vhost-blk.ko and corresponding qemu version will get me started to measure some numbers. RegardsMohan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi,I am looking to experiment the vhost-blk stack. Can some one point me to the latest code version and the corresponding qemu version location.I am on centos 7 (3.10 ) kernel. I am hoping using the vhost-blk.ko and corresponding qemu version will get me started to measure some numbers. RegardsMohan -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 2014/11/5 16:43, Eric Auger wrote: > On 10/27/2014 12:23 PM, Li Liu wrote: >> >> >> On 2014/10/27 17:37, Peter Maydell wrote: >>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>>> features I add a new register offset VIRTIO_MMIO_ISRMEM which

On 2014/11/5 16:43, Eric Auger wrote: > On 10/27/2014 12:23 PM, Li Liu wrote: >> >> >> On 2014/10/27 17:37, Peter Maydell wrote: >>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>>> features I add a new register offset VIRTIO_MMIO_ISRMEM which

On 2014/11/6 9:59, Shannon Zhao wrote: > > > On 2014/11/5 16:43, Eric Auger wrote: >> On 10/27/2014 12:23 PM, Li Liu wrote: >>> >>> >>> On 2014/10/27 17:37, Peter Maydell wrote: >>>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS

Hi Michael, When you talk about VFIO in guest, is it with a purely emulated IOMMU in Qemu? Also, I am not clear on the following points: 1. How transient memory would be mapped using BAR in the backend VM 2. How would the backend VM update the dirty page bitmap for the frontend VM Regards Varun > -----Original Message----- > From: qemu-devel-bounces+varun.sethi=freescale.com at nongnu.org

Hi Michael, When you talk about VFIO in guest, is it with a purely emulated IOMMU in Qemu? Also, I am not clear on the following points: 1. How transient memory would be mapped using BAR in the backend VM 2. How would the backend VM update the dirty page bitmap for the frontend VM Regards Varun > -----Original Message----- > From: qemu-devel-bounces+varun.sethi=freescale.com at nongnu.org

On Wed, May 22, 2019 at 03:02:38PM +0200, Johannes Berg wrote: > Hi, > > While my main interest is mostly in UML right now [1] I've CC'ed the > qemu and virtualization lists because something similar might actually > apply to other types of virtualization. > > I'm thinking about adding virt-io support to UML, but the tricky part is > that while I want to use

On 10/27/2014 12:23 PM, Li Liu wrote: > > > On 2014/10/27 17:37, Peter Maydell wrote: >> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>> features I add a new register offset VIRTIO_MMIO_ISRMEM which >>> will help to establish a shared memory region

On 10/27/2014 12:23 PM, Li Liu wrote: > > > On 2014/10/27 17:37, Peter Maydell wrote: >> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>> features I add a new register offset VIRTIO_MMIO_ISRMEM which >>> will help to establish a shared memory region

Hi Linux Virtualization Mailing List Members, I am trying to develop a driver for virtio blk device in guest. I can safely mount the virtual blk device with: mount /dev/vda /mnt/ in /mnt/ I can read & write the device. But when I run a simple hello world program in /mnt/root/, this error happens: root at linux_guest:/mnt/root# ./helloworld_static [ 23.003459] CPU: 0 PID: 491 Comm:

Hi Linux Virtualization Mailing List Members, I am trying to develop a driver for virtio blk device in guest. I can safely mount the virtual blk device with: mount /dev/vda /mnt/ in /mnt/ I can read & write the device. But when I run a simple hello world program in /mnt/root/, this error happens: root at linux_guest:/mnt/root# ./helloworld_static [ 23.003459] CPU: 0 PID: 491 Comm:

DMA support in FW CFG had to be pushed out as it caused ltp failures - likely a compatibility issue, and could be a hypervisor bug, but we need to figure it out first. There's still a small chance it'll happen shortly, then I might do another pull request just for that. The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: Linux 4.14 (2017-11-12 10:46:13 -0800)

DMA support in FW CFG had to be pushed out as it caused ltp failures - likely a compatibility issue, and could be a hypervisor bug, but we need to figure it out first. There's still a small chance it'll happen shortly, then I might do another pull request just for that. The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: Linux 4.14 (2017-11-12 10:46:13 -0800)

On 01/12/2015 00:20, Ming Lin wrote: > qemu-nvme: 148MB/s > vhost-nvme + google-ext: 230MB/s > qemu-nvme + google-ext + eventfd: 294MB/s > virtio-scsi: 296MB/s > virtio-blk: 344MB/s > > "vhost-nvme + google-ext" didn't get good enough performance. I'd expect it to be on par of qemu-nvme with ioeventfd but the question is: why should it be better? For

On Tue, 2015-12-01 at 17:02 +0100, Paolo Bonzini wrote: > > On 01/12/2015 00:20, Ming Lin wrote: > > qemu-nvme: 148MB/s > > vhost-nvme + google-ext: 230MB/s > > qemu-nvme + google-ext + eventfd: 294MB/s > > virtio-scsi: 296MB/s > > virtio-blk: 344MB/s > > > > "vhost-nvme + google-ext" didn't get good enough performance. > >

On 01/12/2015 00:20, Ming Lin wrote: > qemu-nvme: 148MB/s > vhost-nvme + google-ext: 230MB/s > qemu-nvme + google-ext + eventfd: 294MB/s > virtio-scsi: 296MB/s > virtio-blk: 344MB/s > > "vhost-nvme + google-ext" didn't get good enough performance. I'd expect it to be on par of qemu-nvme with ioeventfd but the question is: why should it be better? For