All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>,
	Petr Pavlu <petr.pavlu@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jgross@suse.com" <jgross@suse.com>,
	vikram.garhwal@amd.com
Subject: Re: [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0
Date: Tue, 4 Jul 2023 09:48:53 +0200	[thread overview]
Message-ID: <ZKPO5WbFGblXU5hX@MacBook-Air-de-Roger.local> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2306291502150.3936094@ubuntu-linux-20-04-desktop>

On Thu, Jun 29, 2023 at 03:44:04PM -0700, Stefano Stabellini wrote:
> On Thu, 29 Jun 2023, Oleksandr Tyshchenko wrote:
> > On 29.06.23 04:00, Stefano Stabellini wrote:
> > > I think we need to add a second way? It could be anything that can help
> > > us distinguish between a non-grants-capable virtio backend and a
> > > grants-capable virtio backend, such as:
> > > - a string on xenstore
> > > - a xen param
> > > - a special PCI configuration register value
> > > - something in the ACPI tables
> > > - the QEMU machine type
> > 
> > 
> > Yes, I remember there was a discussion regarding that. The point is to 
> > choose a solution to be functional for both PV and HVM *and* to be able 
> > to support a hotplug. IIRC, the xenstore could be a possible candidate.
> 
> xenstore would be among the easiest to make work. The only downside is
> the dependency on xenstore which otherwise virtio+grants doesn't have.

I would avoid introducing a dependency on xenstore, if nothing else we
know it's a performance bottleneck.

We would also need to map the virtio device topology into xenstore, so
that we can pass different options for each device.

> Vikram is working on virtio with grants support in QEMU as we speak.
> Maybe we could find a way to add a flag in QEMU so that we can detect at
> runtime if a given virtio device support grants or not.

Isn't there a way for the device to expose capabilities already?  For
example how does a virtio-blk backend expose support for indirect
descriptors?

Thanks, Roger.

  parent reply	other threads:[~2023-07-04  7:49 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21 13:12 [PATCH 0/2] Fix Linux dom0 boot on a QEMU/KVM virtual machine Petr Pavlu
2023-06-21 13:12 ` [PATCH 1/2] xen/virtio: Fix NULL deref when a bridge of PCI root bus has no parent Petr Pavlu
2023-06-21 16:22   ` Oleksandr Tyshchenko
2023-06-29  0:37     ` Stefano Stabellini
2023-06-21 13:12 ` [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0 Petr Pavlu
2023-06-21 17:58   ` Oleksandr Tyshchenko
2023-06-26 13:17     ` Petr Pavlu
2023-07-07  7:46       ` Juergen Gross
2023-07-07 21:02         ` Stefano Stabellini
2023-07-08 10:54           ` Juergen Gross
2023-07-08 18:13             ` Stefano Stabellini
2023-06-29  1:00     ` Stefano Stabellini
2023-06-29 20:29       ` Oleksandr Tyshchenko
2023-06-29 22:44         ` Stefano Stabellini
2023-07-04  6:25           ` Juergen Gross
2023-07-04  7:48           ` Roger Pau Monné [this message]
2023-07-04 10:39             ` Juergen Gross
2023-07-04 11:43               ` Marek Marczykowski-Górecki
2023-07-04 14:49                 ` Roger Pau Monné
2023-07-04 17:14                   ` Oleksandr Tyshchenko
2023-07-05  4:46                     ` Juergen Gross
2023-07-05  8:32                     ` Roger Pau Monné
2023-07-05 22:41                       ` Stefano Stabellini
2023-07-06  8:17                         ` Roger Pau Monné
2023-07-06 21:49                           ` Stefano Stabellini
2023-07-07  4:38                             ` Juergen Gross
2023-07-07  9:50                               ` Roger Pau Monné
2023-07-07 14:10                                 ` Juergen Gross
2023-07-07 14:27                                   ` Juergen Gross
2023-07-07 14:48                                     ` Roger Pau Monné
2023-07-07 15:14                                       ` Juergen Gross
2023-07-07 14:42                                   ` Roger Pau Monné
2023-07-07 15:01                                     ` Juergen Gross
2023-07-07 15:14                                       ` Roger Pau Monné
2023-07-07 15:15                                         ` Juergen Gross
2023-07-07  7:04       ` Juergen Gross
2023-07-07  8:00         ` Oleksandr Tyshchenko
2023-07-07  8:11           ` Juergen Gross
2023-07-07  8:23             ` Oleksandr Tyshchenko
     [not found] <100177f8fec144ac96d91de226f76ebe@posteo.net>
2023-07-07 20:51 ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZKPO5WbFGblXU5hX@MacBook-Air-de-Roger.local \
    --to=roger.pau@citrix.com \
    --cc=Oleksandr_Tyshchenko@epam.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=vikram.garhwal@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.