All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: thuth@redhat.com, Matthew Rosato <mjrosato@linux.ibm.com>,
	david@redhat.com, richard.henderson@linaro.org,
	qemu-devel@nongnu.org, pasic@linux.ibm.com,
	borntraeger@de.ibm.com, qemu-s390x@nongnu.org
Subject: Re: [PATCH v2 2/2] s390x/pci: Fix memory_region_access_valid call
Date: Fri, 18 Dec 2020 18:05:33 +0100	[thread overview]
Message-ID: <608f9aff-965f-62ee-6034-c61f98213200@linux.ibm.com> (raw)
In-Reply-To: <20201218175119.5f43b378.cohuck@redhat.com>



On 12/18/20 5:51 PM, Cornelia Huck wrote:
> On Fri, 18 Dec 2020 17:40:50 +0100
> Pierre Morel <pmorel@linux.ibm.com> wrote:
> 
>> On 12/18/20 4:32 PM, Cornelia Huck wrote:
>>> On Fri, 18 Dec 2020 15:32:08 +0100
>>> Pierre Morel <pmorel@linux.ibm.com> wrote:
>>>    
>>>> On 12/18/20 12:04 PM, Cornelia Huck wrote:
>>>>> On Fri, 18 Dec 2020 10:37:38 +0100
>>>>> Pierre Morel <pmorel@linux.ibm.com> wrote:
>>>>>       
>>>>>> On 12/17/20 11:16 PM, Matthew Rosato wrote:
>>>>>>> In pcistb_service_handler, a call is made to validate that the memory
>>>>>>> region can be accessed.  However, the call is made using the entire length
>>>>>>> of the pcistb operation, which can be larger than the allowed memory
>>>>>>> access size (8).  Since we already know that the provided buffer is a
>>>>>>> multiple of 8, fix the call to memory_region_access_valid to iterate
>>>>>>> over the memory region in the same way as the subsequent call to
>>>>>>> memory_region_dispatch_write.
>>>>>>>
>>>>>>> Fixes: 863f6f52b7 ("s390: implement pci instructions")
>>>>>>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
>>>>>>> ---
>>>>>>>      hw/s390x/s390-pci-inst.c | 10 ++++++----
>>>>>>>      1 file changed, 6 insertions(+), 4 deletions(-)
>>>>>>>
>>>>>>> diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
>>>>>>> index e230293..76b08a3 100644
>>>>>>> --- a/hw/s390x/s390-pci-inst.c
>>>>>>> +++ b/hw/s390x/s390-pci-inst.c
>>>>>>> @@ -821,10 +821,12 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t r3, uint64_t gaddr,
>>>>>>>          mr = s390_get_subregion(mr, offset, len);
>>>>>>>          offset -= mr->addr;
>>>>>>>      
>>>>>>> -    if (!memory_region_access_valid(mr, offset, len, true,
>>>>>>> -                                    MEMTXATTRS_UNSPECIFIED)) {
>>>>>>> -        s390_program_interrupt(env, PGM_OPERAND, ra);
>>>>>>> -        return 0;
>>>>>>> +    for (i = 0; i < len; i += 8) {
>>>>>>> +        if (!memory_region_access_valid(mr, offset + i, 8, true,
>>>>>>> +                                        MEMTXATTRS_UNSPECIFIED)) {
>>>>>>> +            s390_program_interrupt(env, PGM_OPERAND, ra);
>>>>>>> +            return 0;
>>>>>>> +        }
>>>>>>>          }
>>>>>>>      
>>>>>>>          if (s390_cpu_virt_mem_read(cpu, gaddr, ar, buffer, len)) {
>>>>>>>          
>>>>>>
>>>>>> wouldn't it be made automatically by defining the io_region
>>>>>> max_access_size when reading the bars in clp_service_call?
>>>>>>      
>>>>>
>>>>> But that's already what is happening, isn't it? The access check is
>>>>> done for a size that is potentially too large, while the actual access
>>>>> will happen in chunks of 8? I think that this patch is correct.
>>>>>       
>>>>
>>>> Sorry I was too rapid and half wrong in my writing I was also not
>>>> specific enough.
>>>>
>>>> In MemoryRegionOps we have a field valid with a callback accepts().
>>>>
>>>> I was wondering if doing the check in the accept() callback which is
>>>> called by the memory_region_access_valid() function and then using
>>>> max_access_size would not be cleaner.
>>>>
>>>> Note that it does not change a lot but only where the check is done.
>>>
>>> But where would we add those ops? My understanding is that pcistb acts
>>> on whatever region the device provided, and that differs from device to
>>> device?
>>>
>>>    
>>
>> The ops already exist, I thought adding a dedicated callback for s390 on
>> every regions used by vfio_pci instead of the default.
>> But it does not add a lot, just looks cleaner to me.
> 
> But we end up here for every pci device, not just for vfio devices,
> don't we?
> 
> 

Yes, but isn't what is done here?

-- 
Pierre Morel
IBM Lab Boeblingen


  reply	other threads:[~2020-12-18 17:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 22:16 [PATCH v2 0/2] s390x/pci: some pcistb fixes Matthew Rosato
2020-12-17 22:16 ` [PATCH v2 1/2] s390x/pci: fix pcistb length Matthew Rosato
2020-12-18  9:22   ` Christian Borntraeger
2020-12-17 22:16 ` [PATCH v2 2/2] s390x/pci: Fix memory_region_access_valid call Matthew Rosato
2020-12-18  6:10   ` Thomas Huth
2020-12-18  9:37   ` Pierre Morel
2020-12-18 11:04     ` Cornelia Huck
2020-12-18 14:32       ` Pierre Morel
2020-12-18 15:32         ` Cornelia Huck
2020-12-18 16:40           ` Pierre Morel
2020-12-18 16:51             ` Cornelia Huck
2020-12-18 17:05               ` Pierre Morel [this message]
2020-12-21  8:50                 ` Pierre Morel
2020-12-21 10:21                   ` Cornelia Huck
2020-12-21 12:22 ` [PATCH v2 0/2] s390x/pci: some pcistb fixes Cornelia Huck

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=608f9aff-965f-62ee-6034-c61f98213200@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.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 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.