Re: [virtio-dev] KVM_SET_USER_MEMORY_REGION after VM has booted?

On Fri, Oct 14, 2022 at 6:44 AM Srivatsa Vaddagiri wrote: > I have been checking in what scenario we may see KVM_SET_USER_MEMORY_REGION > being > invoked to modify memory mapping (add or remove region of memory from VM) > *after* VM has booted. Memory hotplug may be one? Any other scenario?

Re: [virtio-dev] How to register virtio MMIO device registers with KVM

On 07/03/21 21:57, Peter Okelmann wrote: Hi, i'm looking into virtio over MMIO. How does KVM know which guest memory region contains MMIO device registers? As i understand KVM exits the VM with KVM_EXIT_MMIO when MMIO memory is accessed and for that it should know where it is. Anything that

Re: [virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 19/11/20 02:41, Jie Deng wrote: No, the kick is only an advice.  The device is allowed to poll on the ring and ignore kicks completely, for example. Paolo Understood. But I saw your proposal can only group two segments "write-read". What if we have segments more than two ? for example,

Re: [virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 18/11/20 03:06, Jie Deng wrote: Can the "kick" be used for grouping ? I mean when a write and a read are sent by one kick at a time, they will be treated as one transaction by default if the host has such a feature bit. No, the kick is only an advice. The device is allowed to poll on the

[virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 17/11/20 09:23, Gerd Hoffmann wrote: That is not enough. You also need that for the transactions. If the driver sends a write and a read message the device needs to know whenever that is one or two transactions. So if you want continue with the i2c_msg list idea you need some way to group

[virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 16/11/20 03:12, Jie Deng wrote: Fore example, the frontend may kick the sequence "write read read ..." to the backend at a time. The segments can be aggregated into "i2c_msg list" and sent to the hardware at a time by the backend. The host native drivers will finally send these segments

[virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 10/11/20 11:33, Michael S. Tsirkin wrote: Sorry I didn't reply last week, but I really would prefer if virtio-i2c supported write-read transactions. And I think an easier way is to allow multi-segment transactions probably using the stop flag. You cannot always be sure that the host would

[virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

On 10/11/20 08:31, Jie Deng wrote: virtio-i2c is a virtual I2C adapter device. It provides a way to flexibly communicate with the I2C slave devices from the guest. This patch adds the specification for this device. Sorry I didn't reply last week, but I really would prefer if virtio-i2c

Re: [virtio-dev] Re: [PATCH v2] virtio-i2c: add the device specification

It'd always be a write followed by a read. Usually the write provides the number of a register to be read. The opposite order does not make much sense. Paolo Il gio 5 nov 2020, 07:35 Jie Deng ha scritto: > > On 2020/10/31 21:58, Paolo Bonzini wrote: > > On 27/10/20 12:20, Michae

Re: [virtio-dev] Re: [PATCH v2] virtio-i2c: add the device specification

On 27/10/20 12:20, Michael S. Tsirkin wrote: >> The I2C doesn't support segments numbering and sorting. >> So if one creates a multi-segment transaction, then he/she should keep the >> segments in order. >> >> Thanks. > Fine, but I see no flags to signal start/end of such a transaction. > In

[virtio-dev] Re: [virtio-comment] [PATCH v3] virtio-i2c: add the device specification

On 27/10/20 07:00, Jie Deng wrote: > +The driver queues requests to the virtqueue, and they are used by the > +device. The request is the representation of one segment of an I2C > +transaction. Each request is of form: > + > +\begin{lstlisting} > +struct virtio_i2c_req { > +le16 addr; > +

Re: [virtio-dev] Dirty Page Tracking (DPT)

The sentence below refers to emulated device DMA. When emulated devices inside QEMU perform DMA goes through functions that keep the dirty page bitmap up to date. Likewise for CPU emulation performed by QEMU, which is not an issue if you are using KVM or other hypervisors supported by QEMU.

Re: [virtio-dev] VIRTIO adoption in other hypervisors

On 28/02/20 12:18, Alex Bennée wrote: >> OS X Hypervisor.framework just uses QEMU, so it can use virtio devices >> too. VirtualBox also supports virtio devices. > I guess these don't do any sort of vhost support so all virtio devices > are handled directly in QEMU? OS X can use vhost-user.

Re: [virtio-dev] VIRTIO adoption in other hypervisors

On 28/02/20 11:16, Alex Bennée wrote: > - How about HyperV and the OSX equivalent? OS X Hypervisor.framework just uses QEMU, so it can use virtio devices too. VirtualBox also supports virtio devices. Paolo - To unsubscribe,

[virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

On 29/07/19 09:48, Huang Yang wrote: > > But virtualization software like Qemu doesn't provide eMMC/UFS/NVMe > RPMB emulation. It blocks the OS like Trusty or OP-TEE running in a > virtualization environment. For instance, Google right now uses another > way to work around RPMB emulation issue

Re: [virtio-dev] [RFC] Add polling mode feature bit

On 25/06/19 21:17, Conghui Chen wrote: > On Tue 25.Jun'19 at  9:32:13 +0200, Paolo Bonzini wrote: >> On 25/06/19 17:15, Conghui Chen wrote: >>> Hi, >>> >>> We are working on enable VIRTIO on RTVMs. For RT requirements and some >>> security reasons, th

Re: [virtio-dev] [RFC] Add polling mode feature bit

On 25/06/19 17:15, Conghui Chen wrote: > Hi, > > We are working on enable VIRTIO on RTVMs. For RT requirements and some > security reasons, the VIRTIO interrupts are not allowed to inject to > guest OS, and the notify flow may bring some uncertain delay, so the > polling mode for VIRTIO device is

Re: [virtio-dev] Would there be virtio-audio spec in future for clean audio interface

On 26/03/19 01:48, vlse wrote: > On Mon, Mar 25, 2019 at 02:13:51PM +0100, Paolo Bonzini wrote: > Hi, > > No I don't have a contact with Project ACRN. > > ACRN is a Linux Foundation Project. Initially it was by Intel. > It is a hypervisor for embedded device

Re: [virtio-dev] Would there be virtio-audio spec in future for clean audio interface

On 24/03/19 05:51, vlse wrote: > Would there be virtio-audio spec in future for clean audio interface? > > Projectacrn.github.io provides one virtio-audio interface for automotive > sytems. That's interesting to know. It would probably be up to projectacrn to submit virtio-audio to the

Re: [virtio-dev] virtio-blk: the nature of discard_sector_alignment

On 22/02/19 10:41, Jakub Jermar wrote: > Hi Paolo! > > On 2/22/19 10:21 AM, Paolo Bonzini wrote: >> On 21/02/19 17:38, Jakub Jermar wrote: >>> >>> my device enforces the discard_sector_alignment on the request (both >>> sector and num_sectors),

Re: [virtio-dev] virtio-blk: the nature of discard_sector_alignment

On 21/02/19 17:38, Jakub Jermar wrote: > > my device enforces the discard_sector_alignment on the request (both > sector and num_sectors), but for some reason the blkdiscard command and > Linux driver issue requests that do not honor this alignment. > > Does discard_sector_alignment represent a

Re: [virtio-dev] [PATCH v2 2/2] virtio-fs: add DAX window

On 13/02/19 07:33, Stefan Hajnoczi wrote: > Describe how shared memory region ID 0 is the DAX window and how > FUSE_SETUPMAPPING maps file ranges into the window. > > Signed-off-by: Stefan Hajnoczi > --- > virtio-fs.tex | 25 + > 1 file changed, 25 insertions(+) > >

Re: [virtio-dev] [PATCH v2 1/2] content: add virtio file system device

On 13/02/19 07:33, Stefan Hajnoczi wrote: > +Notifications are different from normal requests because they only contain > +device writable fields. The driver sends notification replies on one of the > +request queues. The format of notification requests is as follows: > + > +\begin{lstlisting} >

Re: [virtio-dev] Clarifications for the new DISCARD and WRITE ZEROES commands

On 15/08/2018 17:12, Jakub Jermar wrote: > In the absence of such a conforming patch, I would kindly ask someone to > clarify the relationship between the virtio_blk_discard_write_zeroes > structures and the virtio descriptor. [1] seems to indicate that there > is always one struct

[virtio-dev] Re: [RFC] VIRTIO_F_IO_BARRIER: use I/O barriers in driver

On 25/04/2018 16:29, Michael S. Tsirkin wrote: >> Unfortunately this doesn't work as mentioned earlier. Virtio live >> migration assumes that features are safe if you have them on the >> destination but not on the source; this feature however works the >> opposite way. > > That's a qemu code

[virtio-dev] Re: [RFC] VIRTIO_F_IO_BARRIER: use I/O barriers in driver

On 25/04/2018 10:23, Tiwei Bie wrote: > There will be hardware virtio devices in the future, which > require drivers to use the barriers suitable for I/O device, > compared with software virtio devices which just require > drivers to use the barriers suitable for CPU core. > > To fix the ordering

[virtio-dev] Re: [virtio] [PATCH 4/5] packed-ring: reposition drivernormative on driver notifications

On 10/04/2018 16:59, Halil Pasic wrote: >> I agree with that - but IMO you're now separating two related paragraphs. > > I'm not separating them they were separated, but I get your point. Yeah, I meant separating them with a heading. >> The driver MUST ensure the write to the \field{flags} field

Re: [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 19:27, Michael S. Tsirkin wrote: > > That CONFIG_SMP here is clearly wrong but I don't really know what > to set it to. Also, we probably should switch virtio_wmb to dma_XX > barriers. > > That's actually easy. Will try to do. Should it be dma_wmb() before updating the indices,

Re: [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 18:52, Liang, Cunming wrote: >>> Oh you are right. >>> >>> So it's only needed for non-intel platforms or when packets are >>> in WC memory then. And I don't know whether dpdk ever puts >>> packets in WC memory. >>> >>> I guess we'll cross this bridge when we get to it. >> Non-TSO

Re: [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 17:59, Michael S. Tsirkin wrote: > On Thu, Apr 19, 2018 at 05:51:51PM +0200, Paolo Bonzini wrote: >> On 19/04/2018 17:19, Michael S. Tsirkin wrote: >>>> - if we make it 1 when weak barriers are needed, the device also needs >>>> to nack featu

[virtio-dev] Re: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 17:42, Michael S. Tsirkin wrote: >> A compiler barrier is enough on strongly-ordered memory platform. >> As it doesn't re-order store, PCI device won't see a stale index >> value. But a weakly-ordered memory needs sfence. > > Oh you are right. > > So it's only needed for non-intel

Re: [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 17:19, Michael S. Tsirkin wrote: >> - if we make it 1 when weak barriers are needed, the device also needs >> to nack feature negotiation (not allow setting the FEATURES_OK) if the >> bit is not set by the driver. >> However, that is not enough. Live >> migration assumes that it is

Re: [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers

On 19/04/2018 14:43, Liang, Cunming wrote: >> 2. Memory barriers. Right now after updating the avail idx, >> virtio does smp_wmb() and then the MMIO write. Normal hardware >> drivers do wmb() which is an sfence. Can a PCI device read bypass >> index write and see a stale index value? > > A

Re: [virtio-dev] Re: [virtio] [RFC PATCH 1/3] notifications: unify notifications wording in core

On 11/04/2018 14:55, Cornelia Huck wrote: >>> Nice, I think the cleanup is worthwhile. >> I agree. I wondered if we should use the term "used buffer interrupt" >> and "available buffer notification". In the common case I think it >> would be clearer, though there are cases such as vhost-pci

Re: [virtio-dev] Re: [virtio] [RFC PATCH 1/3] notifications: unify notifications wording in core

On 11/04/2018 04:19, Stefan Hajnoczi wrote: > On Wed, Apr 11, 2018 at 12:11:25AM +0200, Halil Pasic wrote: >> Let us unify the wording when talking about notifications. This change >> establishes the terms available buffer notification for what was usually >> simply called notification or

[virtio-dev] Re: [virtio] [PATCH 4/5] packed-ring: reposition drivernormative on driver notifications

On 10/04/2018 12:25, Halil Pasic wrote: > All I did was to move the device normative to a better place. IMHO > it's current place is obviously wrong. I agree with that - but IMO you're now separating two related paragraphs. > So, I read your comment as > there should be a patch on top that

Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend

On 10/04/2018 06:57, Tiwei Bie wrote: >> So you just move the abstraction layer from qemu to kernel, and you still >> need different drivers in kernel for different device interfaces of >> accelerators. This looks even more complex than leaving it in qemu. As you >> said, another idea is to

[virtio-dev] Re: [virtio] [PATCH 4/5] packed-ring: reposition drivernormative on driver notifications

On 09/04/2018 20:58, Halil Pasic wrote: > The driver has to be careful to expose the new \field{flags} > value before checking if notifications are suppressed. This paragraph should also be reworked to be part of the normative text below, I think? The memory barrier must be "between two

Re: [virtio-dev] Dynamic assignment of vhost-user to a VM

On 09/04/2018 08:33, Avi Cohen (A) wrote: > Hello All, > Is it possible to assign a vhost-user frontend to a VM *after* the VM was > launched ? > Best Regards > Avi If you're referring to QEMU then yes, you can dynamically create all of character devices (to connect to the vhost-user server),

[virtio-dev] Re: [virtio-comment] [PATCH v3] virtio-blk: add discard and write zeroes features to specification

On 12/03/2018 17:19, Laszlo Ersek wrote: > virtio-scsi already supports discard and write zeroes, and virtio-scsi > can be backed by SSDs. Can you please describe the use case in the > commit message (in a few words) that needs discard / write zeroes but is > ill-served by virtio-scsi? > > I

Re: [virtio-dev] [PATCH v3] virtio-blk: add discard and write zeroes features to specification

On 08/03/2018 02:01, Liu, Changpeng wrote: > > >> -Original Message- >> From: virtio-dev@lists.oasis-open.org >> [mailto:virtio-dev@lists.oasis-open.org] On >> Behalf Of Stefan Hajnoczi >> Sent: Wednesday, March 7, 2018 7:29 PM >> To: Liu, Changpeng >> Cc:

[virtio-dev] Re: [RFC v2] virtio-blk: add discard and write zeroes features to specification

; +zeroes. This is true independent of whether \field{unmap} was set or clear. > + > +The device SHOULD clear the \field{write_zeroes_may_unmap} field of the > +virtio configuration space if and only if a write zeroes request cannot > +result in deallocating one or more sectors. The device

Re: [virtio-dev] Re: [RFC] virtio-blk: add discard and write zeroes features to specification

On 27/02/2018 06:45, Liu, Changpeng wrote: >> Perhaps we can put a bit here saying whether write_zeroes will ever look >> at the \field{unmap} bit? Like: >> >> u8 write_zeroes_may_unmap; > > I do take this into consideration, if write zeroes is supported and discard > is not supported, >

[virtio-dev] Re: [RFC] virtio-blk: add discard and write zeroes features to specification

On 26/02/2018 09:16, Changpeng Liu wrote: > Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES support, > this will impact the performance when using SSD backend over file systems. > > Here is the proposal to extend existing virtio-blk protocol to support > DISCARD/WRITE ZEROES

Re: [virtio-dev] [PATCH v1 6/6] vhost-user: add VFIO based accelerators support

On 06/02/2018 05:40, Tiwei Bie wrote: > In our case, the accelerator for > each VM is a PCI VF device and the PCI card has vswitch > logic (the VFs are the ports of switch to connect VMs). Ok, this makes a lot more sense now. :) Paolo > So the card is a vswitch accelerator which will be shared

Re: [virtio-dev] [PATCH v1 6/6] vhost-user: add VFIO based accelerators support

On 25/01/2018 05:03, Tiwei Bie wrote: > The key difference with PCI passthru is that, in this case only > the data path of the device (e.g. DMA ring, notify region and > queue interrupt) is pass-throughed to the VM, the device control > path (e.g. PCI configuration space and MMIO regions) is still

Re: [virtio-dev] Re: [virtio] [PATCH v7 08/11] packed virtqueues: more efficient virtqueue layout

On 05/02/2018 17:57, Halil Pasic wrote: >> This is certainly not how we did it for v1.0, and not how >> oasis process works generally. Implementations are required >> to move to an oasis standard change. We are working on >> a committee standard deliverables. >> >> I don't yet plan to work on an

Re: [virtio-dev] RE: virtq configuration over PCI

On 19/07/2017 19:56, Lior Narkis wrote: >>> I would like to understand if I captured it right, and if so, >>> understand how it is guaranteed today with a SW implementation of a >>> device. BAR writes are never pipelined or reordered. This is probably not helpful for HW implementations, sorry.

Re: [virtio-dev] [PATCH] virtio-blk: add DISCARD support to virtio-blk driver

On 28/03/2017 10:39, Changpeng Liu wrote: > + if (virtio_has_feature(vdev, VIRTIO_BLK_F_DISCARD)) { > + q->limits.discard_zeroes_data = 0; Maybe you could use another feature bit to populate discard_zeroes_data. Paolo > + q->limits.discard_alignment = blk_size; > +

Re: [virtio-dev] packed ring layout proposal v2

On 09/02/2017 19:24, Michael S. Tsirkin wrote: >> I don't know. Power of 2 ring size is pretty standard, I'd rather avoid >> the complication and the gratuitous difference with 1.0. > > I thought originally there's a reason 1.0 rings had to be powers of two > but now I don't see why. OK, we can

Re: [virtio-dev] packed ring layout proposal v2

On 08/02/2017 20:59, Michael S. Tsirkin wrote: > We couldn't decide what's better for everyone in 1.0 days and I doubt > we'll be able to now, but yes, benchmarking is needed to make > sire it's required. Very easy to remove or not to use/support in > drivers/devices though. Fair enough, but of

Re: [virtio-dev] packed ring layout proposal v2

On 08/02/2017 04:20, Michael S. Tsirkin wrote: > * Scatter/gather support > > We can use 1 bit to chain s/g entries in a request, same as virtio 1.0: > > /* This marks a buffer as continuing via the next field. */ > #define VRING_DESC_F_NEXT 1 > > Unlike virtio 1.0, all descriptors must

Re: [virtio-dev] Re: Virtio Spec clarification

On 31/01/2017 19:27, Michael S. Tsirkin wrote: > On Tue, Jan 31, 2017 at 01:13:37PM -0500, Karandeep Chahal wrote: >> Hello Virtio Developers, >> >> I need some clarification about the virtio spec, and I was wondering if you >> can help me with that. >> >> If VIRTIO_F_EVENT_IDX feature is

[virtio-dev] Re: [PATCH 1/3] virtio: Basic implementation of virtio pstore driver

On 15/11/2016 15:36, Namhyung Kim wrote: > Hi, > > On Tue, Nov 15, 2016 at 10:57:29AM +0100, Paolo Bonzini wrote: >> >> >> On 15/11/2016 06:06, Michael S. Tsirkin wrote: >>> On Tue, Nov 15, 2016 at 01:50:21PM +0900, Namhyung Kim wrote: >>>> Hi

Re: [virtio-dev] packed ring layout proposal

On 20/09/2016 10:38, Pierre Pfister (ppfister) wrote: > More inline, but first I want to propose something. > > One of the expensive operation in device workload is to map physical address > found in the descriptor to > the virtual address. The reason being that there are multiple memory

Re: [virtio-dev] packed ring layout proposal

On 19/09/2016 21:14, Michael S. Tsirkin wrote: > > But I prefer all these tricks to be hidden within the driver. It seems > > a good idea in the beginning to rig the device to second-guess what a > > driver could do, but then it makes things awkward. (This is also why > > I'd rather get rid of

Re: [virtio-dev] packed ring layout proposal

On 19/09/2016 18:48, Michael S. Tsirkin wrote: > > > > > > #define BATCH_NOT_FIRST 0x0010 > > > #define BATCH_NOT_LAST 0x0020 > > > > > > In other words only descriptor in batch is . > > > > > > Batch does not have to be processed together, so > > > !first/!last flags can be changed when

Re: [virtio-dev] packed ring layout proposal

On 16/09/2016 11:46, Stefan Hajnoczi wrote: >> > The idea is to have a r/w descriptor in a ring structure, >> > replacing the used and available ring, index and descriptor >> > buffer. > This is probably obvious but: > > Why is the desc.index field needed? > > The index field would be needed

Re: [virtio-dev] packed ring layout proposal

On 16/09/2016 00:39, Michael S. Tsirkin wrote: > #define DESC_HW 0x0080 0x8000 seems easier to spot when looking at dumps. > virtio 1.0 allows passing a batch of descriptors in both directions, by > incrementing the used/avail index by values > 1. We can support this by > tagging

[virtio-dev] Re: [PATCH v2 00/15] virtio-crypto: introduce framework and device emulation

On 13/09/2016 11:54, Daniel P. Berrange wrote: > > OK, I agree with you :) But if we support multiple backends, can > > we keep cryptodev-linux module as one option? > > I'm personally against any support for out of tree kernel modules > in QEMU, regardless of whether QEMU also implements

[virtio-dev] Re: [PATCH v2 02/15] crypto: introduce crypto queue handler

On 13/09/2016 11:20, Daniel P. Berrange wrote: >> > +typedef struct CryptoPacket CryptoPacket; >> > +typedef struct CryptoQueue CryptoQueue; >> > +typedef struct CryptoPacketBuf CryptoPacketBuf; >> > + >> > +typedef void (CryptoPacketSent) (CryptoClientState *, int); > As previously, I'd expect

[virtio-dev] Re: [PATCH v2 01/15] crypto: introduce cryptodev backend and crypto legacy hardware

On 13/09/2016 11:13, Daniel P. Berrange wrote: > > + * Permission is hereby granted, free of charge, to any person obtaining a > > copy > > + * of this software and associated documentation files (the "Software"), > > to deal > > + * in the Software without restriction, including without