From: Halil Pasic <pasic@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
linux-kernel@vger.kernel.org, borntraeger@de.ibm.com,
frankja@linux.ibm.com, mst@redhat.com, jasowang@redhat.com,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
virtualization@lists.linux-foundation.org,
thomas.lendacky@amd.com, david@gibson.dropbear.id.au,
linuxram@us.ibm.com, heiko.carstens@de.ibm.com,
gor@linux.ibm.com
Subject: Re: [PATCH v5 2/2] s390: virtio: PV needs VIRTIO I/O device protection
Date: Thu, 9 Jul 2020 11:55:53 +0200 [thread overview]
Message-ID: <20200709115553.2dde6ab1.pasic@linux.ibm.com> (raw)
In-Reply-To: <20200709105733.6d68fa53.cohuck@redhat.com>
On Thu, 9 Jul 2020 10:57:33 +0200
Cornelia Huck <cohuck@redhat.com> wrote:
> On Thu, 9 Jul 2020 10:39:19 +0200
> Pierre Morel <pmorel@linux.ibm.com> wrote:
>
> > If protected virtualization is active on s390, the virtio queues are
> > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been
> > negotiated. Use the new arch_validate_virtio_features() interface to
> > fail probe if that's not the case, preventing a host error on access
> > attempt
Punctuation at the end?
Also 'that's not the case' refers to the negation
'VIRTIO_F_IOMMU_PLATFORM has been negotiated',
arch_validate_virtio_features() is however part of
virtio_finalize_features(), which is in turn part of the feature
negotiation. But that is details. I'm fine with keeping the message as
is.
> >
> > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > ---
> > arch/s390/mm/init.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> > index 6dc7c3b60ef6..b8e6f90117da 100644
> > --- a/arch/s390/mm/init.c
> > +++ b/arch/s390/mm/init.c
> > @@ -45,6 +45,7 @@
> > #include <asm/kasan.h>
> > #include <asm/dma-mapping.h>
> > #include <asm/uv.h>
> > +#include <linux/virtio_config.h>
> >
> > pgd_t swapper_pg_dir[PTRS_PER_PGD] __section(.bss..swapper_pg_dir);
> >
> > @@ -161,6 +162,32 @@ bool force_dma_unencrypted(struct device *dev)
> > return is_prot_virt_guest();
> > }
> >
> > +/*
> > + * arch_validate_virtio_features
> > + * @dev: the VIRTIO device being added
> > + *
> > + * Return an error if required features are missing on a guest running
> > + * with protected virtualization.
> > + */
> > +int arch_validate_virtio_features(struct virtio_device *dev)
> > +{
> > + if (!is_prot_virt_guest())
> > + return 0;
> > +
> > + if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) {
> > + dev_warn(&dev->dev, "device must provide VIRTIO_F_VERSION_1\n");
>
> I'd probably use "legacy virtio not supported with protected
> virtualization".
>
> > + return -ENODEV;
> > + }
> > +
> > + if (!virtio_has_feature(dev, VIRTIO_F_IOMMU_PLATFORM)) {
> > + dev_warn(&dev->dev,
> > + "device must provide VIRTIO_F_IOMMU_PLATFORM\n");
>
> "support for limited memory access required for protected
> virtualization"
>
> ?
>
> Mentioning the feature flag is shorter in both cases, though.
I liked the messages in v4. Why did we change those? Did somebody
complain?
I prefer the old ones, but it any case:
Acked-by: Halil Pasic <pasic@linux.ibm.com>
>
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > /* protected virtualization */
> > static void pv_init(void)
> > {
>
> Either way,
>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
>
next prev parent reply other threads:[~2020-07-09 9:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 8:39 [PATCH v5 0/2] s390: virtio: let arch validate VIRTIO features Pierre Morel
2020-07-09 8:39 ` [PATCH v5 1/2] " Pierre Morel
2020-07-09 8:39 ` Pierre Morel
2020-07-09 9:58 ` Halil Pasic
2020-07-09 10:48 ` Pierre Morel
2020-07-09 8:39 ` [PATCH v5 2/2] s390: virtio: PV needs VIRTIO I/O device protection Pierre Morel
2020-07-09 8:57 ` Cornelia Huck
2020-07-09 9:55 ` Halil Pasic [this message]
2020-07-09 10:58 ` Pierre Morel
2020-07-09 10:58 ` Pierre Morel
2020-07-09 10:51 ` Pierre Morel
2020-07-09 14:47 ` Halil Pasic
2020-07-09 14:51 ` Pierre Morel
2020-07-09 14:51 ` Pierre Morel
2020-07-09 15:06 ` Halil Pasic
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=20200709115553.2dde6ab1.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mst@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=thomas.lendacky@amd.com \
--cc=virtualization@lists.linux-foundation.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.