From: Juergen Gross <jgross@suse.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
viresh.kumar@linaro.org,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH v2] xen: don't require virtio with grants for non-PV guests
Date: Thu, 16 Jun 2022 08:15:16 +0200 [thread overview]
Message-ID: <50b72415-2e7d-b25e-0022-539d9fe91d41@suse.com> (raw)
In-Reply-To: <YqrHlNOiRxxc8xcq@infradead.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1539 bytes --]
On 16.06.22 08:03, Christoph Hellwig wrote:
> On Thu, Jun 16, 2022 at 07:37:15AM +0200, Juergen Gross wrote:
>> Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
>> Xen grant mappings") introduced a new requirement for using virtio
>> devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
>> feature.
>>
>> This is an undue requirement for non-PV guests, as those can be operated
>> with existing backends without any problem, as long as those backends
>> are running in dom0.
>>
>> Per default allow virtio devices without grant support for non-PV
>> guests.
>>
>> Add a new config item to always force use of grants for virtio.
>
> What Í'd really expect here is to only set the limitations for the
> actual grant-based devic. Unfortunately
> PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS is global instead of per-device,
I think the global setting is fine, as it serves a specific purpose:
don't allow ANY virtio devices without the special handling (like the
/390 PV case, SEV, TDX, or Xen PV-guests). Those cases can't sensibly
work without the special DMA ops.
In case the special DMA ops are just a "nice to have" like for Xen HVM
guests, PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS won't be set.
And if someone wants a guest only to use grant based virtio devices,
the guest kernel can be built with CONFIG_XEN_VIRTIO_FORCE_GRANT (e.g.
in case the backends are running in some less privileged environment
and thus can't map arbitrary guest memory pages).
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2022-06-16 6:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 5:37 Juergen Gross
2022-06-16 6:03 ` Christoph Hellwig
2022-06-16 6:15 ` Juergen Gross [this message]
2022-06-16 7:31 ` Oleksandr
2022-06-16 8:56 ` Juergen Gross
2022-06-16 20:33 ` Oleksandr
2022-06-17 0:03 ` Stefano Stabellini
2022-06-17 5:49 ` Juergen Gross
2022-06-17 8:15 ` Oleksandr
2022-06-17 5:41 ` Juergen Gross
2022-06-16 18:20 ` Stefano Stabellini
2022-06-17 5:38 ` Juergen Gross
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=50b72415-2e7d-b25e-0022-539d9fe91d41@suse.com \
--to=jgross@suse.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=sstabellini@kernel.org \
--cc=viresh.kumar@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®