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?
Turn
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 is
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,
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
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 y
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 u
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
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
support
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, M
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 theo
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;
> +
On 10/04/20 05:41, Alexander Duyck wrote:
> From: Alexander Duyck
>
> According to the documentation in memory.h a ROM memory region will be
> backed by RAM for reads, but is supposed to go through a callback for
> writes. Currently we were not checking for the existence of the rom_device
> flag
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.
When
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.
Paolo
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,
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 wh
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 reason
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
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 d
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 committe
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), but
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 s
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(+)
>
> diff
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}
>
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_blk_disca
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 prope
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
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
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, and
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 a
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 feature n
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 p
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
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 compile
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 whe
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 virtqueue
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 furthe
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 impleme
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 things"
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), ne
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 belie
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@lists.oasis-open.or
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 MAY change t
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,
> e
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 command
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
>
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
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 im
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. :)
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;
> +
- Original Message -
> From: "Michael S. Tsirkin"
> To: "Paolo Bonzini"
> Cc: virtio-dev@lists.oasis-open.org, virtualizat...@lists.linux-foundation.org
> Sent: Friday, February 10, 2017 4:20:17 PM
> Subject: Re: [virtio-dev] packed ring layout propo
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
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
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
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 negotia
On 18/11/2016 05:07, Michael S. Tsirkin wrote:
> On Fri, Nov 18, 2016 at 12:32:06PM +0900, Namhyung Kim wrote:
>> Btw I prefer using the kvmtool for my kernel work since it's much more
>> simpler..
>
> Up to you but then you should extend that to support 1.0 spec.
> I strongly object to adding t
On 18/11/2016 04:32, Namhyung Kim wrote:
>> In addition, the firmware will need to reserve a few KB of RAM for the error
>> log
>> address range (I checked a real system and it reserves 8KB). The first eight
>> bytes are needed for the record identifier interface, because there's no such
>> thi
> Not sure how independent ERST is from ACPI and other specs. It looks
> like referencing UEFI spec at least.
It is just the format of error records that comes from the UEFI spec
(include/linux/cper.h) but you can ignore it, I think. It should be
handled by tools on the host side. For you, the
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
On 26/10/2016 12:14, Yuanhan Liu wrote:
> On Wed, Oct 26, 2016 at 11:49:17AM +0200, Maxime Coquelin wrote:
>>
>>
>> On 09/16/2016 08:51 PM, Michael S. Tsirkin wrote:
>>> On Fri, Sep 16, 2016 at 10:28:19AM +0100, Stefan Hajnoczi wrote:
On Fri, Sep 16, 2016 at 01:39:15AM +0300, Michael S. Tsir
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 region
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
On 19/09/2016 19:15, Michael S. Tsirkin wrote:
> On Mon, Sep 19, 2016 at 02:01:57PM +0200, Paolo Bonzini wrote:
>> The main issue with VRING_DESC_F_INDIRECT, at least as it is implemented
>> in Linux, is the cost of allocating and freeing the indirect descriptor.
>> But
On 19/09/2016 19:03, Stephen Hemminger wrote:
> Ideally, the DPDK driver should use the best algorithm it can negotiate.
> Be sure and test with old RHEL6 type systems, modern enterprise (RHEL/SLES)
> and also Google Compute which has there own virtio. Not sure what virtual
> box is doing??
RH
On 19/09/2016 19:22, Michael S. Tsirkin wrote:
> No but you do need to make sure that when get_buf returns
> the first buffer, all buffers are available.
Is that not the case already? But anyway I now agree it's better to put
it in the descriptor, thanks for clarifying.
> And from the achitect
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
On 19/09/2016 09:37, Pierre Pfister (ppfister) wrote:
> Paolo proposed in a later mail to drop VRING_DESC_F_NEXT altogether,
> and I think he is right at least in the sense that having two solutions
> for doing almost the same thing is not necessary (IMHO, even harmful).
>
> But, VRING_DESC_F_IN
> Without indirect the usable ring size is cut in half on older kernels that
> don't support any layout. That limit on qemu ends up being 128 packets
Hi Stephen,
note that here we were talking about limiting direct descriptors to
requests with a single buffer.
Paolo
---
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 if
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 first/middle/
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 altern
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 n
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 limita
> > > I am studying the virtio spec 1.0 and trying to write a virtio blk
> > > driver.
> > >
> > > Is there anywhere a simple example virtio blk driver can be found,
> > > which may be written with conformance to virtio spec 1.0?
> > > I would like to understand a simple virtio blk driver, how it i
74 matches
Mail list logo
