[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 4 Jul 2023 09:48:53 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rVM7JbmkIJt65OkIbFHrsl4m6lh9mPKw/yEp9eXztFk=; b=AB0QPEZOIOoitfUMG51E3o99wMRWIdODrQYEiE8jaOL2KccFefkurpviTs9Xv1rfTJr4RvKGTwNPrZZW3+yPlsc3a+CYJ33zLDOBz4dq0jamQKQgxQDfV4uHxbx3fImonMJqZ+5NzuJhHoPTpLLgfvZYMumnLi6D7hNfTYrhXa3ZGFnAKQeiVW2r3mQvqhCRC9txLDrCMd0x4CvPrlg21mbtCuACAHFthJsOl/LgzUWV8GUVovvXtrYqPajikUMQJ5lhnKcT/sJjMs9bB2SPDTR+mJp25OVyA5nqX4oDKFSZeYeLgVRPUeDo4g0rCTp6vd04+R37KY/FDgsvb7JcZQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=noPbFuZq2gBGRC6Kwlu74kZYUK6JMkcvfl4XZlikXNlpbL+tMFhEy1tiQuTCIj/ZJhAFwxfEY7zqE5hVN/KHHtcIDfWWbdCnhfhi3nbr0lcbjRLcbnKEDWJ9bhNvIVdL3xQNmQ/Snam26G0Bx9avzd949kv0KP1+jJyPlX3oprx8eUJCUDVYRUYBShcLl98xlX/NNFbBtbsr6RJ2RgWQLl5NhqZN3kUITZhapA04zxKfSfnUgUqoaSWTR3uxU2D4jh157PGvYQEhVZ6vxDdyT/piOZnKAUA1IpyXPl8gKS8i3rab6kSOJpCke3i6swZSnH9qN2+Py0Aet6wvODhAFw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Petr Pavlu <petr.pavlu@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "jgross@xxxxxxxx" <jgross@xxxxxxxx>, vikram.garhwal@xxxxxxx
  • Delivery-date: Tue, 04 Jul 2023 07:49:22 +0000
  • Ironport-data: A9a23:lj+2NasM3pi0McIvwrKA+V1hZ+fnVMRfMUV32f8akzHdYApBsoF/q tZmKTjTO/iCamD2e4txPYjnpB8H68Pcx4RiQVdsqyg1EH4U+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVKiffHg3HVQ+IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4rKq4Vv0gnRkPaoQ5ACGyyFPZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwKDsKfjaEvseMkaOBEq5jgu4Bc+u2BdZK0p1g5Wmx4fcOZ7nmGv2PwOACmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osjf60aIG9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAd5JRODorKACbFu71mhNIQw5anKBv+SGmFPhacoPL BU49X97xUQ13AnxJjXnZDWju2KNtBMYX9tWEsU55RuLx66S5ByWbkAjSjNCc9UguNUBeS0x1 lSJktXqAhRiqLSQD3ma89+8tT6uI24NJHEGeAcfUBAIpdLkpekbnh/JC9puDqOxptn0Ai3rh SCHqjAkgLcehtJN0L+0lXjDgjSxtt3KQxQz6wH/QG2o9EV6aZSjaoju7kLUhd5CI5yeVUKpp 2Uflo6V6+VmJY+MlzaERaMCFaup+P+BGDTZjRhkGJxJyti203uqfIQV5S4kIk5sa54AYWWwO BSVvh5N7phOOnfsdbVwf4+6F8Uty+7nCMjhUffXKNFJZ/CdaTO6wc2nXmbIt0iFraTmufhX1 UuzGSp0MUsnNA==
  • Ironport-hdrordr: A9a23:GbkrGaB4LG68f0XlHenP55DYdb4zR+YMi2TDtnoQdfUxSKelfq +V8cjzuSWftN9zYhAdcK67V5VoKEm0naKdirN8AV7NZmfbhFc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.