[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations


  • To: Julien Grall <julien@xxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Mon, 6 Sep 2021 07:02:46 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GDTAVpAbHwGYMZmKPNl2kjdBtJNWPwV7jhug3pQvpwE=; b=WswR/JJ/zS2K7staqMNNw3o7is1s+64X2SOraKIbH33BRxVZIv0IAC7Fp8fQ5aMIlzuOo3RMs/TdD69UEwHhmq7+DssjXr2M1FE2XkcPwlEZs+EMTHr5tL0rJBTWTYKGZqpx3X5i7xg8UUWh1nTe7eDAARRqd1MXUUWAekzTnUbGTBF/MjZKpqeO0PZKabr5zBNiAapDgt3oGbqkCtRgBgD7Emu+lnKu1SemlwUdH/MdkcLhOCeIsxfecz0NkRerFJLCwkA9PBHM4mIwpmAMPihfuBXt7Xieo14yG9EQg0ka6uTHWQtjIjKRLqapAzRX70FnpEkIALw821gVDx8wjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PQk7TwGRFQCFaBgnv0VXOZWWeM6NYZTEkh6Hztv50rc03PEx21G27h6gO1VXNJ06PRc6PYxw2bwcA/TwInJbr9TJpPs3oGK5QmYR4pQLaaQjj4NoDWBZVpEZUMGkwF9a9Hlbin8gGQKkw7LeG0darT46wGL4hEoMn4U0+UHSpAtayS0fr3Hmq++4ZhkGjt3X0GKBa4XC238xuC3A2vCmlTRTE7mRFdUeOeb4XHm1bDOrcAFI+JOOGFKl5rtq4EDNHKjD5Dm2lduHAzkovIILa4T/g7/A+P0gm4co9G7MLveESpusmr8wJYe6Ltsg7StWn0xBX9w1J77CJNyc4Rq7pg==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com;
  • Cc: "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>
  • Delivery-date: Mon, 06 Sep 2021 07:03:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXoJ51zxJWpxhHEEGXNqYYBqazw6uSBESAgASU4wA=
  • Thread-topic: [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

Hi, Julien!

On 03.09.21 12:04, Julien Grall wrote:
> Hi Oleksandr,
>
> On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>
>> vPCI may map and unmap PCI device memory (BARs) being passed through which
>> may take a lot of time. For this those operations may be deferred to be
>> performed later, so that they can be safely preempted.
>> Run the corresponding vPCI code while switching a vCPU.
>
> IIUC, you are talking about the function map_range() in 
> xen/drivers/vpci/header. The function has the following todo for Arm:
>
>         /*
>          * ARM TODOs:
>          * - On ARM whether the memory is prefetchable or not should be passed
>          *   to map_mmio_regions in order to decide which memory attributes
>          *   should be used.
>          *
>          * - {un}map_mmio_regions doesn't support preemption.
>          */
>
> This doesn't seem to be addressed in the two series for PCI passthrough sent 
> so far. Do you have any plan to handle it?

No plan yet.

All the mappings are happening with p2m_mmio_direct_dev as of now.

>
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>> ---
>>   xen/arch/arm/traps.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 219ab3c3fbde..1571fb8afd03 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -34,6 +34,7 @@
>>   #include <xen/symbols.h>
>>   #include <xen/version.h>
>>   #include <xen/virtual_region.h>
>> +#include <xen/vpci.h>
>>     #include <public/sched.h>
>>   #include <public/xen.h>
>> @@ -2304,6 +2305,11 @@ static bool check_for_vcpu_work(void)
>>       }
>>   #endif
>>   +    local_irq_enable();
>> +    if ( has_vpci(v->domain) && vpci_process_pending(v) )
>
> Looking at the code of vpci_process_pending(), it looks like there are some 
> rework to do for guest. Do you plan to handle it as part of the vPCI series?
Yes, vPCI code is heavily touched to support guest non-identity mappings
>
>> +        raise_softirq(SCHEDULE_SOFTIRQ);
>> +    local_irq_disable();
>> +
>
> From my understanding of vcpi_process_pending(). The function will return 
> true if there are more work to schedule.
Yes
> However, if check_for_vcpu_for_work() return false, then we will return to 
> the guest before any work for vCPI has finished. This is because 
> check_for_vcpu_work() will not be called again.
Correct
>
> In this case, I think you want to return as soon as you know we need to 
> reschedule.
Not sure I understand this
>
> However, looking at the rest of the code, we already have a check for vpci in 
> the common IOREQ code.

Which may not be enabled as it depends on CONFIG_IOREQ_SERVER.

My understanding is that for x86 it is always enabled, but this might not be 
the case for Arm

> So we would end up to call twice vpci_process_pending().
So, if CONFIG_IOREQ_SERVER is not enabled then we end up with only calling it 
from traps.c on Arm
> Maybe we should move the call from the IOREQ to arch-code.

Hm. I would better think of moving it from IOREQ to some other common code: for 
x86 (if

my understanding correct about CONFIG_IOREQ_SERVER) it is by coincidence that 
we call vPCI

code from there and IOREQ is always enabled.

>
> Cheers,
>
Thank you,

Oleksandr

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.