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

Re: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Thu, 20 Jan 2022 10:27:17 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Pc9b+WskC5Hu1LYFS6ZaqKPPfra/MYV78DT6EwdnI5M=; b=E4RGIK6x/DZmVRvdTn8gZTDBE9T8lVVoAcOZbZYbG2TzMlaDQPhs0bVx1RJESDARM2ZWbkW4C40P9B/f9+sSgnqBnQIxjEronHsqcaDCYSOqVO/6tlyRnlPw8pNUJ6tSJqfzE44GrZjyKrpcHd+zH3R2mHiHlp5KA/lIe/eqPtuPQ9hNYv6pHn+TSIbSPembVp4XN8jbnMsQID4/NLqhBwbOlUTnDNR342jdJ+7WrdJq5On7MN38IRvJrq9WaCeQemU7tn8w02VD2OY6kw/cgKqKCedKWv7VR+X86IOwhN/0PB5QTv8FSwjgIFsGlvKSIR4SHLxUHz8enj3UI6KvQQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lyVRkMafX8i8NVIlhUueBgbq+8qG2onT2jqjbTBg472jppyPZUONHZy+5usy2k7K9lm+NcDIO4JG4cQOLSjDT55EfM0rFz8mjEL2ORQqGIbXBKAjLqnaWDDU/i8LIshSkRMnIjnWYQugsOhi/Jcp3r0AtoRzfM+829NwzoYpfn45eJOxZxHFyaeIKpJ8bDZBcF8okYatrgnOTkttqSm9Lh0LtFj6pZejIHhawPUB773vnkxYBMCfR75foAcYqYT8HpVwoJMxRHDdwsSv3B72vaWhzMg7e/X1uMyDMR1+SQLXz6KXjscP0mFq67U+eu6h6t5xfrc8aVlIQT2d2ZcMcA==
  • Cc: Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Oleksandr <olekstysh@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • Delivery-date: Thu, 20 Jan 2022 10:27:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHX8M3LpzWz4l8PQUiIA2nAUV0H+qw0P2iAgAJehQCABnNTgIAAc5MAgADFCgCAAB+dgIAAA54AgAARtoCAABUwgIAA0niAgAEYP4CAATSeAIAonC6AgAEQDYCAAI9tAA==
  • Thread-topic: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs

On Wed, Jan 19, 2022 at 05:53:55PM -0800, Stefano Stabellini wrote:
> On Wed, 19 Jan 2022, Oleksii Moisieiev wrote:
> > On Fri, Dec 24, 2021 at 02:30:50PM +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 23/12/2021 20:06, Stefano Stabellini wrote:
> > > > On Wed, 22 Dec 2021, Stefano Stabellini wrote:
> > > > > # Future Ideas
> > > > > 
> > > > > A great suggestion by Julien is to start supporting the dom0less 
> > > > > partial
> > > > > device tree format in xl/libxl as well so that we can have a single
> > > > > "device_tree" option in dom.cfg instead of 4 (device_tree, iomem, 
> > > > > irqs,
> > > > > dtdev).
> > > > > 
> > > > > Even with that implemented, the user has still to provide a partial 
> > > > > dtb,
> > > > > xen,reg and xen,path. I think this is a great step forward and we 
> > > > > should
> > > > > do that, if nothing else to make it easier to switch between dom0less
> > > > > and normal domU configurations. But the number of options and
> > > > > information that the user has to provide is still similar to what we
> > > > > have today.
> > > > 
> > > > I have just realized that if we start to parse the partial DTB in
> > > > xl/libxl the same way that we do for dom0less guests (parse "xen,path",
> > > > "xen,reg", and "interrupts", making dtdev, irqs and iomem optional)
> > > > actually we can achieve the goal below thanks to the combination:
> > > > "xen,path" + "xen,force-assign-without-iommu".
> > > > 
> > > > In other words, with dom0less we already have a way to specify the link
> > > > to the host node even if the device is not a DMA master. We can do that
> > > > by specifying both xen,path and xen,force-assign-without-iommu for a
> > > > device.
> > > > 
> > > > This is just FYI. I am not suggesting we should introduce dom0less-style
> > > > partial DTBs in order to get SCMI support in guests (although it would
> > > > be great to have). I think the best way forward for this series is one
> > > > of the combinations below, like a) + d), or a) + c)
> > > 
> > > I strongly prefer a) + c) because a warning is easy to miss/ignore. At 
> > > least
> > > with the extra property the user made an action to think about it and 
> > > agree
> > > that this is the way do it.
> > > 
> > > It is also easier to spot if we ask the user to provide the configuration
> > > file.
> > > 
> > 
> > Let me share my thoughts about c), which is:
> > c) require force-assign-without-iommu="true" in dom.cfg
> > 
> > Adding this parameter to domain config means removing
> > xen,force-assign-without-iommu param from partial DTB.
> 
> Why? No I don't think so.
> 
> 
> > This will affect dom0less configuration, which I can't test for now
> > without extra effort.
> 
> We are just talking about adding:
> 
> force-assign-without-iommu="true"
> 
> to the xl config file. For instance:
> 
> dtdev = [ "/amba/serial@ff000000" ]
> iomem = ["0xff000,1"]
> force-assign-without-iommu="true"
> 
> It is unrelated to the dom0less partial DTB. There is no need to test
> dom0less to do this.
> 

Oh. In this case I would be happy to add it in this patch series.

Best regards,
Oleksii. 


 


Rackspace

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