On Fri, Nov 20, 2020 at 06:51:07PM +, John Levon wrote:
> If we find a queue with an inconsistent guest index value, explicitly mark the
> device as needing a reset - and broken - via virtio_error().
>
> There's at least one driver implementation - the virtio-win N
and successfully
restore the device to a working state. Other implementations do not correctly
handle this, but as the VQ is not in a functional state anyway, this is still
worth doing.
Signed-off-by: John Levon
---
hw/virtio/virtio.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff
and successfully
restore the device to a working state. Other implementations do not correctly
handle this, but as the VQ is not in a functional state anyway, this is still
worth doing.
Signed-off-by: John Levon
---
hw/virtio/virtio.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff
On Thu, Nov 05, 2020 at 05:50:27PM -0800, John G Johnson wrote:
> The idea behind the version IDs is to identify incompatible protocol
> changes as major versions, and compatible changes as minor versions. What
> would be the purpose of the third version type?
Well, like any patch
On Wed, Oct 28, 2020 at 04:41:31PM +, Thanos Makatos wrote:
> FYI here's v5 of the vfio-user protocol, my --cc in git send-email got messed
> up somehow
Hi Thanos, this looks great, I just had some minor questions below.
> Command Concurrency
> ---
> A client may pipeline
On Mon, Nov 02, 2020 at 11:29:23AM +, Thanos Makatos wrote:
> > +==++=
> > ==+
> > > | version | object | ``{"major": , "minor": }``
> > > |
> > > | ||
Hi, please take a look. For context, this addition is against the current
https://github.com/nutanix/libvfio-user/blob/master/docs/vfio-user.rst
specification.
kvm@ readers: Stefan suggested this may be of interest from a VFIO point of
view, in case there is any potential cross-over in defining
On Mon, May 10, 2021 at 05:57:37PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 14, 2021 at 04:41:22AM -0700, Thanos Makatos wrote:
>
> Elena A: I CCed you in case you want to review the
Sorry, we should have included Elena already.
> > +VFIO sparse mmap
> > +
> > +
> >
On Tue, May 11, 2021 at 11:09:53AM +0100, Stefan Hajnoczi wrote:
> > > > +* *sub-regions* is the array of Sub-Region IO FD info structures
> > > > +
> > > > +The reply message will additionally include at least one file
> > > > descriptor in the
> > > > +ancillary data. Note that more than one
On Wed, May 19, 2021 at 03:08:17PM -0600, Alex Williamson wrote:
> > +VFIO_USER_DMA_MAP
> > +-
> > +
> > +Message Format
> > +^^
> > +
> > ++--++
> > +| Name | Value |
> >
On Tue, May 04, 2021 at 02:51:45PM +0100, Stefan Hajnoczi wrote:
> > +While passing of file descriptors is desirable for performance reasons, it
> > is
> > +not necessary neither for the client nor for the server to support it in
> > order
>
> Double negative. "not" can be removed.
Done. I
On Tue, May 04, 2021 at 02:51:45PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 14, 2021 at 04:41:22AM -0700, Thanos Makatos wrote:
> > This patch introduces the vfio-user protocol specification (formerly
> > known as VFIO-over-socket), which is designed to allow devices to be
Thanks for your
On Tue, Jan 26, 2021 at 11:01:04AM +, Stefan Hajnoczi wrote:
> > 4) (ioregionfd issue) region_id is 4 bytes, which seems a little awkward
> > from
> > the server side: this has to encode both the region ID as well as the
> > offset of
> > the sub-region within that region. Can this be 64
On Fri, Aug 13, 2021 at 02:51:53PM +, Jag Raman wrote:
> Thanks for the information about the Blocking and Non-Blocking mode.
>
> I’d like to explain why we are using a separate thread presently and
> check with you if it’s possible to poll on multiple vfu contexts at the
> same time
On Thu, Sep 09, 2021 at 06:00:36AM +, John Johnson wrote:
> > On Sep 7, 2021, at 10:24 AM, John Levon wrote:
> >
> > On Mon, Aug 16, 2021 at 09:42:42AM -0700, Elena Ufimtseva wrote:
> >
> >> +int vfio_user_region_write(VFI
On Fri, Sep 10, 2021 at 06:07:56AM +, John Johnson wrote:
> >>> On Mon, Aug 16, 2021 at 09:42:42AM -0700, Elena Ufimtseva wrote:
> >>>
> +int vfio_user_region_write(VFIODevice *vbasedev, uint32_t index,
> + uint64_t offset, uint32_t count, void *data)
>
On Mon, Aug 16, 2021 at 09:42:42AM -0700, Elena Ufimtseva wrote:
> +int vfio_user_region_write(VFIODevice *vbasedev, uint32_t index,
> + uint64_t offset, uint32_t count, void *data)
> +{
> +g_autofree VFIOUserRegionRW *msgp = NULL;
> +int size = sizeof(*msgp) +
On Wed, Sep 08, 2021 at 10:51:11AM +0100, Stefan Hajnoczi wrote:
> > +
> > +buf = g_malloc0(size);
> > +memcpy(buf, msg, sizeof(*msg));
> > +
> > +pci_dma_read(pdev, msg->offset, buf + sizeof(*msg), msg->count);
>
> The vfio-user spec doesn't go into errors but pci_dma_read() can
On Wed, Sep 08, 2021 at 01:58:46PM +0100, Stefan Hajnoczi wrote:
> > +static void *vfu_object_attach_ctx(void *opaque)
> > +{
> > +VfuObject *o = opaque;
> > +int ret;
> > +
> > +retry_attach:
> > +ret = vfu_attach_ctx(o->vfu_ctx);
> > +if (ret < 0 && (errno == EAGAIN || errno ==
On Wed, Sep 08, 2021 at 04:02:22PM +0100, Stefan Hajnoczi wrote:
> > We'd have to have a whole separate API to do that, so a separate thread
> > seems a
> > better approach?
>
> Whether to support non-blocking properly in libvfio-user is a decision
> for you. If libvfio-user doesn't support
On Fri, Sep 10, 2021 at 05:20:09PM +0200, Philippe Mathieu-Daudé wrote:
> On 8/27/21 7:53 PM, Jagannathan Raman wrote:
> > add the libvfio-user library as a submodule. build it as a cmake
> > subproject.
> >
> > Signed-off-by: Elena Ufimtseva
> > Signed-off-by: John G Johnson
> >
On Wed, Oct 27, 2021 at 05:21:30PM +0100, Stefan Hajnoczi wrote:
> > +static void vfu_object_ctx_run(void *opaque)
> > +{
> > +VfuObject *o = opaque;
> > +int ret = -1;
> > +
> > +while (ret != 0) {
> > +ret = vfu_run_ctx(o->vfu_ctx);
> > +if (ret < 0) {
> > +
On Mon, Oct 25, 2021 at 08:21:22AM -0700, Elena wrote:
> > I'm curious what approach you want to propose for QEMU integration. A
> > while back I thought about the QEMU API. It's possible to implement it
> > along the lines of the memory_region_add_eventfd() API where each
> > ioregionfd is
On Wed, Oct 27, 2021 at 11:15:35AM +0100, Stefan Hajnoczi wrote:
> > > I like this approach as well.
> > > As you have mentioned, the device emulation code with first approach
> > > does have to how to handle the region accesses. The second approach will
> > > make things more transparent. Let me
On Thu, Dec 16, 2021 at 11:30:20AM +, Stefan Hajnoczi wrote:
> > +ret = vfu_setup_region(o->vfu_ctx, VFU_PCI_DEV_CFG_REGION_IDX,
> > + pci_config_size(o->pci_dev),
> > _object_cfg_access,
> > + VFU_REGION_FLAG_RW |
On Tue, Jul 20, 2021 at 04:20:13PM +0400, Marc-André Lureau wrote:
> > >> + libvfiouser = static_library('vfiouser',
> > >> + build_by_default: false,
> > >> + sources: vfiouser_files,
> > >> +
On Mon, Jul 19, 2021 at 04:00:03PM -0400, Jagannathan Raman wrote:
> add the libvfio-user library as a submodule. build it as part of QEMU
>
> diff --git a/meson.build b/meson.build
> index 6e4d2d8..f2f9f86 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1894,6 +1894,41 @@ if
On Mon, Jul 19, 2021 at 04:00:06PM -0400, Jagannathan Raman wrote:
> +vfu_pci_set_id(o->vfu_ctx,
> + pci_get_word(o->pci_dev->config + PCI_VENDOR_ID),
> + pci_get_word(o->pci_dev->config + PCI_DEVICE_ID),
> +
On Mon, Jul 19, 2021 at 04:00:08PM -0400, Jagannathan Raman wrote:
> Define and register handlers for PCI config space accesses
>
> Signed-off-by: Elena Ufimtseva
> Signed-off-by: John G Johnson
> Signed-off-by: Jagannathan Raman
> ---
> hw/remote/vfio-user-obj.c | 41
On Thu, Jan 06, 2022 at 01:35:32PM +, Stefan Hajnoczi wrote:
> > > >> +static void vfu_object_attach_ctx(void *opaque)
> > > >> +{
> > > >> +VfuObject *o = opaque;
> > > >> +GPollFD pfds[1];
> > > >> +int ret;
> > > >> +
> > > >> +qemu_set_fd_handler(o->vfu_poll_fd, NULL,
On Wed, Mar 09, 2022 at 03:34:53PM -0700, Alex Williamson wrote:
> > +The only device-specific region type and subtype supported by vfio-user is
> > +``VFIO_REGION_TYPE_MIGRATION`` (3) and ``VFIO_REGION_SUBTYPE_MIGRATION``
> > (1).
>
> These should be considered deprecated from the kernel
Observed with base of qemu 6.2.0, but from code inspection it looks to me like
it's still current in upstream master. Apologies if I have missed a fix in this
area.
Symptom: run a UEFI-booted SATA CD Windows installer. When it hits "Loading
files.." screen, run an eject e.g.
virsh
On Tue, Sep 19, 2023 at 12:54:59PM +0200, Kevin Wolf wrote:
> > In the meantime, we start processing the blk_drain() code, so by the time
> > this
> > blk_pread() actually gets handled, quiesce is set, and we get stuck in the
> > blk_wait_while_drained().
> >
> > I don't know the qemu block
On Wed, Aug 23, 2023 at 10:04:00AM +, William Henderson wrote:
> +* *argsz* is the size of the above structure.
As we discussed offline, this isn't right for any of these. They have the same
->argsz semantics as discussed here:
On Thu, Jun 09, 2022 at 07:27:57PM +0200, Klaus Jensen wrote:
> > It's not just unnecessary, but enabling shadow doorbells on admin queues
> > will
> > actively break device implementations (such as SPDK), which have had to
> > presume
> > that driver implementations don't use shadow doorbells
On Wed, Jun 15, 2022 at 07:22:22PM +0800, Jinhao Fan wrote:
> >>> Isn't this racy against the driver? Compare
> >>> https://github.com/spdk/spdk/blob/master/lib/nvmf/vfio_user.c#L1317
> >>
> >> QEMU has full memory barriers on dma read/write, so I believe this is
> >> safe?
> >
> > But don't
On Wed, Jun 15, 2022 at 11:33:02AM +0200, Klaus Jensen wrote:
> > BTW I'm surprised that this patch has just this:
> >
> > +static void nvme_update_sq_eventidx(const NvmeSQueue *sq)
> > +{
> > +pci_dma_write(>ctrl->parent_obj, sq->ei_addr, >tail,
> > + sizeof(sq->tail));
> >
On Wed, Jun 15, 2022 at 10:48:26AM +0200, Klaus Jensen wrote:
> > By the way, I noticed that the patch never updates the cq's ei_addr value.
> > Is
> > that on purpose?
>
> Yeah, I also mentioned this previously[1] and I still think we need to
> update the event index. Otherwise (and my testing
On Thu, Jun 09, 2022 at 08:29:30AM -0600, Keith Busch wrote:
> On Wed, Jun 08, 2022 at 10:55:30PM +0200, Klaus Jensen wrote:
> >
> > Keith, is this a bug in the kernel? If the code here would expect the
> > doorbell buffer to be updated for the admin queue as well, would we
> > break?
>
> The
On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
> > > For the RFC QEMU user space eBPF support,
> > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zh...@intel.com/T/
> > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is
> > > more
On Tue, Nov 08, 2022 at 03:13:24PM -0800, John Johnson wrote:
> Add an abstract base class both the kernel driver
> and user socket implementations can use to share code.
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:26PM -0800, John Johnson wrote:
> cache VFIO_DEVICE_GET_REGION_INFO results to reduce
> memory alloc/free cycles and as prep work for vfio-user
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:25PM -0800, John Johnson wrote:
> Used for communication with VFIO driver
> (prep work for vfio-user, which will communicate over a socket)
> index e573f5a..6fd40f1 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> +
> +extern
On Tue, Nov 08, 2022 at 03:13:27PM -0800, John Johnson wrote:
> Used for communication with VFIO driver
> (prep work for vfio-user, which will communicate over a socket)
>
> @@ -1166,12 +1178,13 @@ uint32_t vfio_pci_read_config(PCIDevice *pdev,
> uint32_t addr, int len)
> if (~emu_bits &
On Mon, Dec 12, 2022 at 10:01:33AM +0100, Cédric Le Goater wrote:
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index 80b03a2..dc19869 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -19,6 +19,7 @@
> >*/
> > #include "qemu/osdep.h"
> > +#include CONFIG_DEVICES
> >
On Tue, Nov 08, 2022 at 03:13:33PM -0800, John Johnson wrote:
> Add per-region FD to support mmap() of remote device regions
>
> +/*
> + * VFIO_USER_DEVICE_GET_REGION_INFO
> + * imported from struct_vfio_region_info
s/struct_vfio_region_info/struct vfio_region_info/
regards
john
On Tue, Nov 08, 2022 at 03:13:36PM -0800, John Johnson wrote:
> +static int vfio_user_io_get_irq_info(VFIODevice *vbasedev,
> + struct vfio_irq_info *irq)
> +{
> +int ret;
> +
> +ret = vfio_user_get_irq_info(vbasedev->proxy, irq);
> +if (ret) {
> +
On Tue, Nov 08, 2022 at 03:13:31PM -0800, John Johnson wrote:
> Also negotiate protocol version with remote server
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:34PM -0800, John Johnson wrote:
> Add support for posted writes on remote devices
LGTM
Reviewed-by: John Levon
regards
john
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:45PM -0800, John Johnson wrote:
> Add new message to send multiple writes to server
LGTM - but maybe commit message could have some context as to why this is
useful?
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:32PM -0800, John Johnson wrote:
> +/*
> + * VFIO_USER_DEVICE_GET_INFO
> + * imported from struct_device_info
> + */
> +typedef struct {
> +VFIOUserHdr hdr;
> +uint32_t argsz;
> +uint32_t flags;
> +uint32_t num_regions;
> +uint32_t num_irqs;
> +
On Tue, Nov 08, 2022 at 03:13:35PM -0800, John Johnson wrote:
> PCI BARs read from remote device
> PCI config reads/writes sent to remote server
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:37PM -0800, John Johnson wrote:
> Server holds device current device pending state
> Use irq masking commands in socket case
As far as I'm able to tell, this looks good to me
regards
john
On Tue, Nov 08, 2022 at 03:13:42PM -0800, John Johnson wrote:
> static void vfio_user_pci_process_req(void *opaque, VFIOUserMsg *msg)
> {
> +VFIOPCIDevice *vdev = opaque;
> +VFIOUserHdr *hdr = msg->hdr;
> +
> +/* no incoming PCI requests pass FDs */
> +if (msg->fds != NULL) {
>
On Tue, Nov 08, 2022 at 03:13:43PM -0800, John Johnson wrote:
> Message to tell the server to reset the device.
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:38PM -0800, John Johnson wrote:
> +/*
> + * The proxy uses a SW IOMMU in lieu of the HW one
> + * used in the ioctl() version. Mascarade as TYPE1
> + * for maximum capatibility
> + */
capability
> @@ -3692,12 +3698,18 @@ static void
On Tue, Nov 08, 2022 at 03:13:40PM -0800, John Johnson wrote:
> Signed-off-by: John G Johnson
> Signed-off-by: Elena Ufimtseva
> Signed-off-by: Jagannathan Raman
> ---
> +static int vfio_user_io_dirty_bitmap(VFIOContainer *container,
> +struct
On Tue, Nov 08, 2022 at 03:13:28PM -0800, John Johnson wrote:
> New class for vfio-user with its class and instance
> constructors and destructors, and its pci ops.
LGTM
Reviewed-by: John Levon
regards
john
On Tue, Nov 08, 2022 at 03:13:41PM -0800, John Johnson wrote:
> Secure DMA forces the remote process to use DMA r/w messages
> instead of directly mapping guest memeory.
I don't really get why this is called "secure" - shouldn't have an option name
more closely resembling what it actually does?
On Tue, Nov 08, 2022 at 03:13:30PM -0800, John Johnson wrote:
> Add infrastructure needed to receive incoming messages
>
> +static void vfio_user_process(VFIOProxy *proxy, VFIOUserMsg *msg, bool
> isreply)
> +{
> +
> +/*
> + * Replies signal a waiter, if none just check for errors
> +
On Tue, Nov 08, 2022 at 03:13:29PM -0800, John Johnson wrote:
> add user.c & user.h files for vfio-user code
> add proxy struct to handle comms with remote server
LGTM
Reviewed-by: John Levon
regards
john
On Fri, Nov 04, 2022 at 07:32:12AM +0100, Klaus Jensen wrote:
> On Nov 3 21:19, Jinhao Fan wrote:
> > On 11/3/2022 8:10 PM, Klaus Jensen wrote:
> > > I agree that the spec is a little unclear on this point. In any case, in
> > > Linux, when the driver has decided that the sq tail must be
On Wed, Nov 01, 2023 at 06:16:06AM -0700, Mattias Nissler wrote:
> This series adds basic support for message-based DMA in qemu's vfio-user
Now qemu 9.0 is out, any reason not to get this series merged?
thanks
john
64 matches
Mail list logo
