linux-kernel - Re: [PATCH 23/32] KVM: s390: pci: handle refresh of PCI translations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Dec 2021 10:41:12 +0100
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Matthew Rosato <mjrosato@...ux.ibm.com>,
        Pierre Morel <pmorel@...ux.ibm.com>, linux-s390@...r.kernel.org
Cc:     alex.williamson@...hat.com, cohuck@...hat.com,
        farman@...ux.ibm.com, borntraeger@...ux.ibm.com, hca@...ux.ibm.com,
        gor@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
        agordeev@...ux.ibm.com, frankja@...ux.ibm.com, david@...hat.com,
        imbrenda@...ux.ibm.com, vneethv@...ux.ibm.com,
        oberpar@...ux.ibm.com, freude@...ux.ibm.com, thuth@...hat.com,
        pasic@...ux.ibm.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 23/32] KVM: s390: pci: handle refresh of PCI translations

On Thu, 2021-12-16 at 09:51 -0500, Matthew Rosato wrote:
> On 12/16/21 9:39 AM, Niklas Schnelle wrote:
> > On Tue, 2021-12-14 at 12:54 -0500, Matthew Rosato wrote:
> > > On 12/14/21 11:59 AM, Pierre Morel wrote:
> > > > On 12/7/21 21:57, Matthew Rosato wrote:
> > > > > Add a routine that will perform a shadow operation between a guest
> > > > > and host IOAT.  A subsequent patch will invoke this in response to
> > > > > an 04 RPCIT instruction intercept.
> > > > > 
> > > > > Signed-off-by: Matthew Rosato <mjrosato@...ux.ibm.com>
> > > > > ---
> > > > >    arch/s390/include/asm/kvm_pci.h |   1 +
> > > > >    arch/s390/include/asm/pci_dma.h |   1 +
> > > > >    arch/s390/kvm/pci.c             | 191 ++++++++++++++++++++++++++++++++
> > > > >    arch/s390/kvm/pci.h             |   4 +-
> > > > >    4 files changed, 196 insertions(+), 1 deletion(-)
> > > > > 
> > ---8<---
> > > > > +
> > > > > +int kvm_s390_pci_refresh_trans(struct kvm_vcpu *vcpu, unsigned long req,
> > > > > +                   unsigned long start, unsigned long size)
> > > > > +{
> > > > > +    struct zpci_dev *zdev;
> > > > > +    u32 fh;
> > > > > +    int rc;
> > > > > +
> > > > > +    /* If the device has a SHM bit on, let userspace take care of
> > > > > this */
> > > > > +    fh = req >> 32;
> > > > > +    if ((fh & aift.mdd) != 0)
> > > > > +        return -EOPNOTSUPP;
> > > > 
> > > > I think you should make this check in the caller.
> > > 
> > > OK
> > > 
> > > > > +
> > > > > +    /* Make sure this is a valid device associated with this guest */
> > > > > +    zdev = get_zdev_by_fh(fh);
> > > > > +    if (!zdev || !zdev->kzdev || zdev->kzdev->kvm != vcpu->kvm)
> > > > > +        return -EINVAL;
> > > > > +
> > > > > +    /* Only proceed if the device is using the assist */
> > > > > +    if (zdev->kzdev->ioat.head[0] == 0)
> > > > > +        return -EOPNOTSUPP;
> > > > 
> > > > Using the assist means using interpretation over using interception and
> > > > legacy vfio-pci. right?
> > > 
> > > Right - more specifically that the IOAT assist feature was never set via
> > > the vfio feature ioctl, so we can't handle the RPCIT for this device and
> > > so throw to userspace.
> > > 
> > > The way the QEMU series is being implemented, a device using
> > > interpretation will always have the IOAT feature set on.
> > > 
> > > > > +
> > > > > +    rc = dma_table_shadow(vcpu, zdev, start, size);
> > > > > +    if (rc > 0)
> > > > > +        rc = zpci_refresh_trans((u64) zdev->fh << 32, start, size);
> > > > 
> > > > Here you lose the status reported by the hardware.
> > > > You should directly use __rpcit(fn, addr, range, &status);
> > > 
> > > OK, I can have a look at doing this.
> > > 
> > > @Niklas thoughts on how you would want this exported.  Renamed to
> > > zpci_rpcit or so?
> > 
> > Hmm with using __rpcit() directly we would lose the error reporting in
> > s390dbf and this ist still kind of a RPCIT in the host. How about we
> > add the status as an out parameter to zpci_refresh_trans()? But yes if
> 
> Another advantage of doing this would be that we then also keep the cc2 
> retry logic in zpci_refresh_trans(), which would be nice.

Yeah thought about that too. If we don't have that I believe the guest
would retry but that means doing two full intercepts and going through
all the other logic too. Since these retries are afaik extremely rare
it shouldn't matter much but on the other hand I would expect them to
only happen when the system is overloaded and then doing all this extra
work surely isn't helpful.

> 
> However we do still lose the returned CC value from the instruction. 
> But I think we can infer a CC1 from a nonzero status and a CC3 from a 
> zero status so maybe this is OK too.

I agree.