All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Rahul Singh <Rahul.Singh@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	 xen-devel <xen-devel@lists.xenproject.org>,
	 Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Julien Grall <julien@xen.org>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH] xen/arm: vpci: Remove PCI I/O ranges property value
Date: Thu, 16 Dec 2021 13:48:48 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2112161347320.3376@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <AA684EED-5631-4036-ABF1-596AD61787CC@arm.com>

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]

On Thu, 16 Dec 2021, Rahul Singh wrote:
> Hi Stefano,
> 
> > On 16 Dec 2021, at 2:33 am, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > 
> > On Tue, 14 Dec 2021, Rahul Singh wrote:
> >> IO ports on ARM don't exist so all IO ports related hypercalls are going
> >> to fail on ARM when we passthrough a PCI device.
> >> Failure of xc_domain_ioport_permission(..) would turn into a critical
> >> failure at domain creation. We need to avoid this outcome, instead we
> >> want to continue with domain creation as normal even if
> >> xc_domain_ioport_permission(..) fails. XEN_DOMCTL_ioport_permission
> >> is not implemented on ARM so it would return -ENOSYS.
> >> 
> >> To solve above issue remove PCI I/O ranges property value from dom0
> >> device tree node so that dom0 linux will not allocate I/O space for PCI
> >> devices if pci-passthrough is enabled.
> >> 
> >> Another valid reason to remove I/O ranges is that PCI I/O space are not
> >> mapped to dom0 when PCI passthrough is enabled, also there is no vpci
> >> trap handler register for IO bar.
> >> 
> >> Signed-off-by: Rahul Singh <rahul.singh@arm.com>
> >> ---
> >> xen/arch/arm/domain_build.c   | 14 +++++++
> >> xen/common/device_tree.c      | 72 +++++++++++++++++++++++++++++++++++
> >> xen/include/xen/device_tree.h | 10 +++++
> >> 3 files changed, 96 insertions(+)
> >> 
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index d02bacbcd1..60f6b2c73b 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -749,6 +749,11 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
> >>                 continue;
> >>         }
> >> 
> >> +        if ( is_pci_passthrough_enabled() &&
> >> +                dt_device_type_is_equal(node, "pci") )
> >> +            if ( dt_property_name_is_equal(prop, "ranges") )
> >> +                continue;
> > 
> > It looks like we are skipping the "ranges" property entirely for the PCI
> > node, is that right? Wouldn't that also remove the other (not ioports)
> > address ranges?
> 
> We are skipping the “ranges” property here to avoid setting the “ranges” property when
> pci_passthrough is enabled. We will remove only remove IO port and set the other ‘ranges” property 
> value in dt_pci_remove_io_ranges() in next if() condition.
>  
> 
> >>         res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
> >> 
> >>         if ( res )
> >> @@ -769,6 +774,15 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
> >>             if ( res )
> >>                 return res;
> >>         }
> >> +
> >> +        /*
> >> +         * PCI IO bar are not mapped to dom0 when PCI passthrough is enabled,
> >> +         * also there is no trap handler registered for IO bar therefor remove
> >> +         * the IO range property from the device tree node for dom0.
> >> +         */
> >> +        res = dt_pci_remove_io_ranges(kinfo->fdt, node);
> >> +        if ( res )
> >> +            return res;
> > 
> > I tried to apply this patch to staging to make it easier to review but I
> > think this chuck got applied wrongly: I can see
> > dt_pci_remove_io_ranges() added to the function "handle_prop_pfdt" which
> > is for guest partial DTBs and not for dom0.
> 
> Oleksandr’s patch series was merged yesterday because of that there is conflict in applying 
> this patch. I will rebase the patch and will send it again for review.
> 
> > 
> > Is dt_pci_remove_io_ranges() meant to be called from write_properties
> > instead? It looks like it would be best to call it from
> > write_properties, maybe it could be combined with the other new check
> > just above in this patch?
> 
> Yes dt_pci_remove_io_ranges() is to be called from write_properties().

OK. In that case the only feedback that is I have is that it might be
possible to avoid the first change of this patch to skip "ranges" by
moving the call to dt_pci_remove_io_ranges() earlier in the
write_properties function.

  reply	other threads:[~2021-12-16 21:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 10:45 [PATCH] xen/arm: vpci: Remove PCI I/O ranges property value Rahul Singh
2021-12-14 10:45 ` [PATCH] xen/vpci: msix: move x86 specific code to x86 file Rahul Singh
2021-12-14 12:37   ` Roger Pau Monné
2021-12-16 10:18     ` Rahul Singh
2021-12-16 11:01       ` Roger Pau Monné
2021-12-16 13:37         ` Jan Beulich
2021-12-17 14:32           ` Julien Grall
2021-12-17 14:58             ` Rahul Singh
2021-12-21  7:41             ` Jan Beulich
2021-12-21  9:35               ` Rahul Singh
2021-12-14 14:15   ` Jan Beulich
2021-12-16 10:28     ` Rahul Singh
2021-12-16  2:33 ` [PATCH] xen/arm: vpci: Remove PCI I/O ranges property value Stefano Stabellini
2021-12-16  9:57   ` Rahul Singh
2021-12-16 21:48     ` Stefano Stabellini [this message]
2021-12-17  9:19       ` Rahul Singh
2021-12-17 11:28 ` Julien Grall

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=alpine.DEB.2.22.394.2112161347320.3376@ubuntu-linux-20-04-desktop \
    --to=sstabellini@kernel.org \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Rahul.Singh@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=julien@xen.org \
    --cc=xen-devel@lists.xenproject.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.