public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: alex.williamson@redhat.com, cohuck@redhat.com,
	schnelle@linux.ibm.com, farman@linux.ibm.com,
	borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
	vneethv@linux.ibm.com, oberpar@linux.ibm.com,
	freude@linux.ibm.com, thuth@redhat.com, pasic@linux.ibm.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 21/30] KVM: s390: pci: handle refresh of PCI translations
Date: Wed, 19 Jan 2022 11:39:58 -0500	[thread overview]
Message-ID: <3d8c05d7-79ec-dfa8-bfcb-b8888183612a@linux.ibm.com> (raw)
In-Reply-To: <265e3448-2e8e-c38b-e625-1546ae3d408b@linux.ibm.com>

On 1/19/22 4:29 AM, Pierre Morel wrote:
> 
> 
> On 1/14/22 21:31, Matthew Rosato wrote:
...
>> +static int dma_table_shadow(struct kvm_vcpu *vcpu, struct zpci_dev 
>> *zdev,
>> +                dma_addr_t dma_addr, size_t size)
>> +{
>> +    unsigned int nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>> +    struct kvm_zdev *kzdev = zdev->kzdev;
>> +    unsigned long *entry, *gentry;
>> +    int i, rc = 0, rc2;
>> +
>> +    if (!nr_pages || !kzdev)
>> +        return -EINVAL;
>> +
>> +    mutex_lock(&kzdev->ioat.lock);
>> +    if (!zdev->dma_table || !kzdev->ioat.head[0]) {
>> +        rc = -EINVAL;
>> +        goto out_unlock;
>> +    }
>> +
>> +    for (i = 0; i < nr_pages; i++) {
>> +        gentry = dma_walk_guest_cpu_trans(vcpu, &kzdev->ioat, dma_addr);
>> +        if (!gentry)
>> +            continue;
>> +        entry = dma_walk_cpu_trans(zdev->dma_table, dma_addr);
>> +
>> +        if (!entry) {
>> +            rc = -ENOMEM;
>> +            goto out_unlock;
>> +        }
>> +
>> +        rc2 = dma_shadow_cpu_trans(vcpu, entry, gentry);
>> +        if (rc2 < 0) {
>> +            rc = -EIO;
>> +            goto out_unlock;
>> +        }
>> +        dma_addr += PAGE_SIZE;
>> +        rc += rc2;
>> +    }
>> +
> 
> In case of error, shouldn't we invalidate the shadow tables entries we 
> did validate until the error?

Hmm, I don't think this is strictly necessary - the status returned 
should indicate the specified DMA range is now in an indeterminate state 
(putting the onus on the guest to take corrective action via a global 
refresh).

In fact I think I screwed that up below in kvm_s390_pci_refresh_trans, 
the fabricated status should always be KVM_S390_RPCIT_INS_RES.

> 
>> +out_unlock:
>> +    mutex_unlock(&kzdev->ioat.lock);
>> +    return rc;
>> +}
>> +
>> +int kvm_s390_pci_refresh_trans(struct kvm_vcpu *vcpu, unsigned long req,
>> +                   unsigned long start, unsigned long size,
>> +                   u8 *status)
>> +{
>> +    struct zpci_dev *zdev;
>> +    u32 fh = req >> 32;
>> +    int rc;
>> +
>> +    /* 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) {
>> +        *status = 0;
> 
> Wouldn't it be interesting to add some debug information here.
> When would this appear?

Yes, I agree -- One of the follow-ons I'd like to add after this series 
is s390dbf entries; this seems like a good spot for one.

As to when this could happen; it should not under normal circumstances, 
but consider something like arbitrary function handles coming from the 
intercepted guest instruction.  We need to ensure that the specified 
function 1) exists and 2) is associated with the guest issuing the refresh.

> 
> Also if we have this error this looks like we have a VM problem, 
> shouldn't we treat this in QEMU and return -EOPNOTSUPP ?
> 

Well, I'm not sure if we can really tell where the problem is (it could 
for example indicate a misbehaving guest, or a bug in our KVM tracking 
of hostdevs).

The guest chose the function handle, and if we got here then that means 
it doesn't indicate that it's an emulated device, which means either we 
are using the assist and KVM should handle the intercept or we are not 
and userspace should handle it.  But in both of those cases, there 
should be a host device and it should be associated with the guest.

I think if we decide to throw this to userspace in this event, QEMU 
needs some extra code to handle it (basically, if QEMU receives the 
intercept and the device is neither emulated nor using intercept mode 
then we must treat as an invalid handle as this intercept should have 
been handled by KVM)


>> +        return -EINVAL;
>> +    }
>> +
>> +    /* Only proceed if the device is using the assist */
>> +    if (zdev->kzdev->ioat.head[0] == 0)
>> +        return -EOPNOTSUPP;
>> +
>> +    rc = dma_table_shadow(vcpu, zdev, start, size);
>> +    if (rc < 0) {
>> +        /*
>> +         * If errors encountered during shadow operations, we must
>> +         * fabricate status to present to the guest
>> +         */
>> +        switch (rc) {
>> +        case -ENOMEM:
>> +            *status = KVM_S390_RPCIT_INS_RES;
>> +            break;
>> +        default:
>> +            *status = KVM_S390_RPCIT_ERR;
>> +            break;

As mentioned above I think this switch statement should go away and 
instead always set KVM_S390_RPCIT_INS_RES when rc < 0.

>> +        }
>> +    } else if (rc > 0) {
>> +        /* Host RPCIT must be issued */
>> +        rc = zpci_refresh_trans((u64) zdev->fh << 32, start, size,
>> +                    status);
>> +    }
>> +    zdev->kzdev->rpcit_count++;
>> +
>> +    return rc;
>> +}
>> +
>>   /* Modify PCI: Register floating adapter interruption forwarding */
>>   static int kvm_zpci_set_airq(struct zpci_dev *zdev)
>>   {
>> @@ -620,6 +822,8 @@ EXPORT_SYMBOL_GPL(kvm_s390_pci_attach_kvm);
>>   int kvm_s390_pci_init(void)
>>   {
>> +    int rc;
>> +
>>       aift = kzalloc(sizeof(struct zpci_aift), GFP_KERNEL);
>>       if (!aift)
>>           return -ENOMEM;
>> @@ -627,5 +831,7 @@ int kvm_s390_pci_init(void)
>>       spin_lock_init(&aift->gait_lock);
>>       mutex_init(&aift->lock);
>> -    return 0;
>> +    rc = zpci_get_mdd(&aift->mdd);
>> +
>> +    return rc;
>>   }
>> diff --git a/arch/s390/kvm/pci.h b/arch/s390/kvm/pci.h
>> index 54355634df82..bb2be7fc3934 100644
>> --- a/arch/s390/kvm/pci.h
>> +++ b/arch/s390/kvm/pci.h
>> @@ -18,6 +18,9 @@
>>   #define KVM_S390_PCI_DTSM_MASK 0x40
>> +#define KVM_S390_RPCIT_INS_RES 0x10
>> +#define KVM_S390_RPCIT_ERR 0x28
>> +
>>   struct zpci_gaite {
>>       u32 gisa;
>>       u8 gisc;
>> @@ -33,6 +36,7 @@ struct zpci_aift {
>>       struct kvm_zdev **kzdev;
>>       spinlock_t gait_lock; /* Protects the gait, used during AEN 
>> forward */
>>       struct mutex lock; /* Protects the other structures in aift */
>> +    u32 mdd;
>>   };
>>   extern struct zpci_aift *aift;
>> @@ -47,7 +51,9 @@ static inline struct kvm 
>> *kvm_s390_pci_si_to_kvm(struct zpci_aift *aift,
>>   int kvm_s390_pci_aen_init(u8 nisc);
>>   void kvm_s390_pci_aen_exit(void);
>> -
>> +int kvm_s390_pci_refresh_trans(struct kvm_vcpu *vcpu, unsigned long req,
>> +                   unsigned long start, unsigned long end,
>> +                   u8 *status);
>>   int kvm_s390_pci_init(void);
>>   #endif /* __KVM_S390_PCI_H */
>>
> 


  reply	other threads:[~2022-01-19 16:40 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 20:31 [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 01/30] s390/sclp: detect the zPCI load/store interpretation facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 02/30] s390/sclp: detect the AISII facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 03/30] s390/sclp: detect the AENI facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 04/30] s390/sclp: detect the AISI facility Matthew Rosato
2022-01-17  7:57   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 05/30] s390/airq: pass more TPI info to airq handlers Matthew Rosato
2022-01-17  8:27   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 06/30] s390/airq: allow for airq structure that uses an input vector Matthew Rosato
2022-01-17 12:29   ` Claudio Imbrenda
2022-01-18 18:52     ` Matthew Rosato
2022-01-18  9:50   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 07/30] s390/pci: externalize the SIC operation controls and routine Matthew Rosato
2022-01-17 16:19   ` Niklas Schnelle
2022-01-26 10:07   ` Claudio Imbrenda
2022-01-27  9:57   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 08/30] s390/pci: stash associated GISA designation Matthew Rosato
2022-01-24 14:08   ` Pierre Morel
2022-01-24 15:12     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 09/30] s390/pci: export some routines related to RPCIT processing Matthew Rosato
2022-01-18  9:51   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 10/30] s390/pci: stash dtsm and maxstbl Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 11/30] s390/pci: add helper function to find device by handle Matthew Rosato
2022-01-18  9:53   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 12/30] s390/pci: get SHM information from list pci Matthew Rosato
2022-01-18 10:36   ` Pierre Morel
2022-01-26 10:13     ` Claudio Imbrenda
2022-01-27 13:41       ` Pierre Morel
2022-01-27 15:14         ` Matthew Rosato
2022-01-27 10:29   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 13/30] s390/pci: return status from zpci_refresh_trans Matthew Rosato
2022-01-19 18:13   ` Pierre Morel
2022-01-26 10:45   ` Claudio Imbrenda
2022-01-27 10:30   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 14/30] KVM: s390: pci: add basic kvm_zdev structure Matthew Rosato
2022-01-17 16:25   ` Pierre Morel
2022-01-18 17:32     ` Pierre Morel
2022-01-18 18:39       ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 15/30] KVM: s390: pci: do initial setup for AEN interpretation Matthew Rosato
2022-01-19 18:06   ` Pierre Morel
2022-01-19 20:19     ` Matthew Rosato
2022-01-25 12:23   ` Pierre Morel
2022-01-25 14:57     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 16/30] KVM: s390: pci: enable host forwarding of Adapter Event Notifications Matthew Rosato
2022-01-17 17:38   ` Pierre Morel
2022-01-18 17:25     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 17/30] KVM: s390: mechanism to enable guest zPCI Interpretation Matthew Rosato
2022-01-24 14:24   ` Pierre Morel
2022-01-24 15:28     ` Matthew Rosato
2022-01-24 17:15       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 18/30] KVM: s390: pci: provide routines for enabling/disabling interpretation Matthew Rosato
2022-01-24 14:36   ` Pierre Morel
2022-01-24 15:14     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 19/30] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding Matthew Rosato
2022-01-25 12:41   ` Pierre Morel
2022-01-25 15:44     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 20/30] KVM: s390: pci: provide routines for enabling/disabling IOAT assist Matthew Rosato
2022-01-25 13:29   ` Pierre Morel
2022-01-25 14:47     ` Matthew Rosato
2022-01-26  8:30       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 21/30] KVM: s390: pci: handle refresh of PCI translations Matthew Rosato
2022-01-19  9:29   ` Pierre Morel
2022-01-19 16:39     ` Matthew Rosato [this message]
2022-01-19 18:25       ` Pierre Morel
2022-01-19 20:02         ` Matthew Rosato
2022-01-20  9:47           ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 22/30] KVM: s390: intercept the rpcit instruction Matthew Rosato
2022-01-18 11:05   ` Pierre Morel
2022-01-18 17:27     ` Matthew Rosato
2022-01-18 17:54       ` Pierre Morel
2022-01-19 14:06   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 23/30] vfio/pci: re-introduce CONFIG_VFIO_PCI_ZDEV Matthew Rosato
2022-01-18 17:20   ` Pierre Morel
2022-01-18 17:32     ` Matthew Rosato
2022-01-18 17:45       ` Pierre Morel
2022-01-18 18:05         ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 24/30] vfio-pci/zdev: wire up group notifier Matthew Rosato
2022-01-18 17:34   ` Pierre Morel
2022-01-18 18:37     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 25/30] vfio-pci/zdev: wire up zPCI interpretive execution support Matthew Rosato
2022-01-25 13:01   ` Pierre Morel
2022-01-25 14:21     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 26/30] vfio-pci/zdev: wire up zPCI adapter interrupt forwarding support Matthew Rosato
2022-01-19 17:10   ` Pierre Morel
2022-01-19 17:20     ` Matthew Rosato
2022-01-25 12:36   ` Pierre Morel
2022-01-25 14:16     ` Matthew Rosato
2022-01-26  8:24       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 27/30] vfio-pci/zdev: wire up zPCI IOAT assist support Matthew Rosato
2022-01-19 14:03   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 28/30] vfio-pci/zdev: add DTSM to clp group capability Matthew Rosato
2022-01-19 13:48   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 29/30] KVM: s390: introduce CPU feature for zPCI Interpretation Matthew Rosato
2022-01-19 13:39   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 30/30] MAINTAINERS: additional files related kvm s390 pci passthrough Matthew Rosato
2022-01-14 20:49 ` [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-19 18:10 ` Pierre Morel

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=3d8c05d7-79ec-dfa8-bfcb-b8888183612a@linux.ibm.com \
    --to=mjrosato@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=vneethv@linux.ibm.com \
    /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