From: Oleksandr Andrushchenko
Host bridge controller's ECAM space is mapped into Domain-0's p2m,
thus it is not possible to trap the same for vPCI via MMIO handlers.
For this to work we need to unmap those mappings in p2m.
TODO (Julien): It would be best if we avoid the map/unmap operation.
So
From: Oleksandr Andrushchenko
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.
Signed
From: Oleksandr Andrushchenko
Update hardware domain's BAR header as R-Car Gen3 is a non-ECAM host
controller, so vPCI MMIO handlers do not work for it in hwdom.
Signed-off-by: Oleksandr Andrushchenko
---
xen/arch/arm/pci/pci-host-rcar-gen3.c | 69 +++
1 file changed
From: Oleksandr Andrushchenko
At the moment there is an identity mapping between how a guest sees its
BARs and how they are programmed into guest domain's p2m. This is not
going to work as guest domains have their own view on the BARs.
Extend existing vPCI BAR handling to allow every domain
From: Oleksandr Andrushchenko
As vPCI now takes care of the proper p2m mappings for PCI devices there
is no more need to hardcode anything.
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/arch-arm.h | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/xen
From: Oleksandr Andrushchenko
In order vPCI to work it needs all access to PCI configuration space
access to be synchronized among all entities, e.g. hardware domain and
guests. For that implement PCI host bridge specific callbacks to
propelry setup those ranges depending on host bridge
From: Oleksandr Andrushchenko
The original code depends on pciback to manage assignable device list.
The functionality which is implemented by the pciback and the toolstack
and which is relevant/missing/needed for ARM:
1. pciback is used as a database for assignable PCI devices, e.g. xl
pci
From: Oleksandr Andrushchenko
According to https://wiki.xenproject.org/wiki/Linux_PVH:
Items not supported by PVH
- PCI pass through (as of Xen 4.10)
Allow running PCI remove code on ARM and do not assert for PVH domains.
Signed-off-by: Oleksandr Andrushchenko
---
tools/libxl/Makefile
From: Oleksandr Andrushchenko
Hello, all!
This is an RFC and an attempt to understand the best way to progress with ARM
PCI passthrough configuration. This includes, but not limited to, configuration
of assignable PCI devices, (legacy IRQs, MSI/MSI-X are not yet supported), MMIO
etc
Hello, Rahul!
On 11/6/20 4:41 PM, Rahul Singh wrote:
Hello Oleksandr,
On 6 Nov 2020, at 2:22 pm, Oleksandr Andrushchenko
wrote:
Hi, Rahul!
On 11/6/20 3:58 PM, Rahul Singh wrote:
Hello Oleksandr,
On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko
wrote:
Hello, Rahul!
On 11/6/20 2:48
Hi, Rahul!
On 11/6/20 3:58 PM, Rahul Singh wrote:
> Hello Oleksandr,
>
>> On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko
>> wrote:
>>
>> Hello, Rahul!
>>
>> On 11/6/20 2:48 PM, Rahul Singh wrote:
>>> Hello Oleksandr,
>>>
>>&
Hello, Rahul!
On 11/6/20 2:48 PM, Rahul Singh wrote:
> Hello Oleksandr,
>
>> On 2 Nov 2020, at 10:12 am, Oleksandr Andrushchenko
>> wrote:
>>
>> Hi,
>>
>> On 11/2/20 11:55 AM, Bertrand Marquis wrote:
>>> Hi,
>>>
>>>> On
Hi,
On 11/2/20 11:55 AM, Bertrand Marquis wrote:
> Hi,
>
>> On 2 Nov 2020, at 05:55, Oleksandr Andrushchenko wrote:
>>
>> Hi, Julien!
>>
>> On 10/30/20 7:18 PM, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 30/10/2020 10:44, Oleks
Hi, Julien!
On 10/30/20 7:18 PM, Julien Grall wrote:
Hi Oleksandr,
On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
On 10/20/20 6:25 PM, Rahul Singh wrote:
Add support for ARM architected SMMUv3 implementations. It is based on
the Linux SMMUv3 driver.
Major differences between the Linux
Hi,
On 10/30/20 6:08 PM, Bertrand Marquis wrote:
> Hi Oleksandr,
>
>> On 30 Oct 2020, at 15:02, Oleksandr Andrushchenko
>> wrote:
>>
>> Hi,
>>
>> On 10/30/20 4:47 PM, Rahul Singh wrote:
>>> Hello Oleksandr,
>>>
>>>> On 30 O
Hi,
On 10/30/20 4:47 PM, Rahul Singh wrote:
> Hello Oleksandr,
>
>> On 30 Oct 2020, at 10:44 am, Oleksandr Andrushchenko
>> wrote:
>>
>> Hi, Rahul!
>>
>> On 10/20/20 6:25 PM, Rahul Singh wrote:
>>> Add support for ARM architected SMMUv3 i
Hi, Rahul!
On 10/20/20 6:25 PM, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementations. It is based on
> the Linux SMMUv3 driver.
>
> Major differences between the Linux driver are as follows:
> 1. Only Stage-2 translation is supported as compared to the Linux driver
>
On 10/27/20 7:18 PM, Jan Beulich wrote:
> On 27.10.2020 16:52, Oleksandr Andrushchenko wrote:
>> On 10/27/20 2:55 PM, Roger Pau Monné wrote:
>>> On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
>>>> 5. An alternative route for 3
Hello, Roger!
On 10/27/20 2:55 PM, Roger Pau Monné wrote:
> On Tue, Oct 27, 2020 at 09:59:05AM +0000, Oleksandr Andrushchenko wrote:
>> Hello, all!
>>
>> While working on PCI passthrough on ARM (partial RFC was published by ARM
>> earlier this year) I tried to imp
Hello, all!
While working on PCI passthrough on ARM (partial RFC was published by ARM
earlier this year) I tried to implement some related changes in the toolstack.
One of the obstacles for ARM is PCI backend’s related code presence: ARM is
going to fully emulate an ECAM host bridge in Xen, so no
Hello, Dan!
On 10/21/20 1:50 PM, Dan Carpenter wrote:
> Hello Oleksandr Andrushchenko,
>
> The patch 58f9d806d16a: "ALSA: xen-front: Use Xen common shared
> buffer implementation" from Nov 30, 2018, leads to the following
> static checker warning:
>
> sou
Hi,
On 9/28/20 6:20 PM, Ian Jackson wrote:
> Oleksandr Andrushchenko writes ("[PATCH 2/2] libgnttab: Add support for Linux
> dma-buf offset"):
>> From: Oleksandr Andrushchenko
>>
>> Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
>>
On 8/20/20 1:50 PM, Julien Grall wrote:
> Hi Roman,
>
> On 16/08/2020 21:45, Roman Shaposhnik wrote:
>> On Sun, Aug 16, 2020 at 7:54 AM Julien Grall wrote:
>>> On 15/08/2020 21:43, Roman Shaposhnik wrote:
Hi!
>>>
>>> Hi,
>>>
with the recent excellent work by Anastasiia committed to the
Hi,
On 8/20/20 2:56 AM, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
> frontend").
>
> The bot has tested the following trees: v5.8.1,
On 8/13/20 6:13 PM, Jürgen Groß wrote:
> On 13.08.20 17:10, Oleksandr Andrushchenko wrote:
>>
>> On 8/13/20 6:02 PM, Jürgen Groß wrote:
>>> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>
>>&g
On 8/13/20 6:02 PM, Jürgen Groß wrote:
> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>
> Series pushed to:
>
> xen/tip.git for-linus-5.9
>
The top patch has strange title though:
"Subject: [PATCH v2 5/5] drm/xen-front:
_free_object_unlocked or any other name if this seems to be
too long,
but starting with xen_drm_front_ as the rest of exported functions?
With this,
Acked-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
> {
> struct xen_drm_front_drm_info *drm_info = obj->dev->dev_priv
On 8/13/20 10:05 AM, Jürgen Groß wrote:
> On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
>> Juergen, Boris,
>>
>> can we please merge these via Xen Linux tree as I have collected enough
>> Ack/R-b?
>>
>> The series has DRM patches, but t
Juergen, Boris,
can we please merge these via Xen Linux tree as I have collected enough Ack/R-b?
The series has DRM patches, but those anyway are Xen related, so I think
this should be fine from DRI point of view.
Thank you,
Oleksandr
On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote:
> F
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Implement dm
On 8/4/20 9:12 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
>> display frontend" from Apr 3, 2018, leads to th
On 8/4/20 9:11 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> It is possible that the scatter-gather table during dmabuf import has
>> non-zero offset of the data, but user-space doesn't expect t
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dm
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
have a look at the change below.
Thank you in advance,
Oleksandr Andrushchenko
On 5/20/20 12:04 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
>
> dma-buf is backed by a scatter-gather table
Ping
On 7/1/20 10:19 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Add protocol version as an integer
>
> Version string, which is in fact an integer, is hard to handle in the
> code that supports different protocol versions. To simplify that
>
On 7/24/20 2:39 AM, Stefano Stabellini wrote:
> On Thu, 23 Jul 2020, Rahul Singh wrote:
>> libxl will create an emulated PCI device tree node in the
>> device tree to enable the guest OS to discover the virtual
>> PCI during guest boot.
>>
>> We introduced the new config option [vpci="ecam"] for
On 7/23/20 11:44 PM, Stefano Stabellini wrote:
> On Thu, 23 Jul 2020, Rahul Singh wrote:
>> Hardware domain is in charge of doing the PCI enumeration and will
>> discover the PCI devices and then will communicate to XEN via hyper
>> call PHYSDEVOP_pci_device_add to add the PCI devices in XEN.
>>
On 7/24/20 2:38 AM, Stefano Stabellini wrote:
> + Jan, Andrew, Roger
>
> Please have a look at my comment on whether we should share the MMCFG
> code below, feel free to ignore the rest :-)
>
>
> On Thu, 23 Jul 2020, Rahul Singh wrote:
>> XEN during boot will read the PCI device tree node “reg”
On 7/17/20 2:26 PM, Julien Grall wrote:
>
>
> On 17/07/2020 08:41, Oleksandr Andrushchenko wrote:
>>>> We need to come up with something similar for dom0less too. It could be
>>>> exactly the same thing (a list of BDFs as strings as a device tree
>>>>
On 7/17/20 11:10 AM, Jan Beulich wrote:
On 16.07.2020 19:10, Rahul Singh wrote:
# Discovering PCI devices:
PCI-PCIe enumeration is a process of detecting devices connected to its host.
It is the responsibility of the hardware domain or boot firmware to do the PCI
enumeration and configure
On 7/17/20 9:53 AM, Bertrand Marquis wrote:
>
>> On 16 Jul 2020, at 22:51, Stefano Stabellini wrote:
>>
>> On Thu, 16 Jul 2020, Rahul Singh wrote:
>>> Hello All,
>>>
>>> Following up on discussion on PCI Passthrough support on ARM that we had at
>>> the XEN summit, we are submitting a Review
Hi, Paul!
On 7/2/20 11:42 AM, Jürgen Groß wrote:
> On 02.07.20 09:59, Oleksandr Andrushchenko wrote:
>>
>> On 7/2/20 10:20 AM, Jürgen Groß wrote:
>>> On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
>>>> On 7/1/20 1:46 PM, Jürgen Groß wrote:
>>>>&g
On 7/7/20 10:58 AM, Manikandan Chockalingam (RBEI/ECF3) wrote:
>
> Hello Team,
>
> I am trying to build xen hypervisor for RCAR and following the
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
> steps.
>
> But am facing the following issues
>
>
On 7/2/20 10:20 AM, Jürgen Groß wrote:
> On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
>> On 7/1/20 1:46 PM, Jürgen Groß wrote:
>>> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>>> 1. Add p
On 7/1/20 1:46 PM, Jürgen Groß wrote:
> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> 1. Add protocol version as an integer
>>
>> Version string, which is in fact an integer, is hard to handle in the
>> code th
From: Oleksandr Andrushchenko
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
Ian, Wei, would you mind looking at the below please?
Thank you in advance,
Oleksandr
On 5/20/20 12:04 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
>
> dma-buf is backed by a scatt
On 6/30/20 10:30 AM, Jürgen Groß wrote:
> On 30.06.20 09:09, Oleksandr Andrushchenko wrote:
>> On 6/30/20 10:03 AM, Jürgen Groß wrote:
>>> On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
>>>> On 6/29/20 10:02 AM, Jürgen Groß wrote:
>>>>> On
On 6/30/20 10:03 AM, Jürgen Groß wrote:
On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which
On 6/29/20 10:02 AM, Jürgen Groß wrote:
> On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> 1. Change protocol version from string to integer
>>
>> Version string, which is in fact an integer, is hard to handle in the
>>
On 6/24/20 8:05 PM, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>>>> On Mon, 22 Jun 2020, Julien Grall wrot
On 6/24/20 10:26 AM, Peng Fan wrote:
>> Subject: Re: UEFI support in ARM DomUs
>>
>>
>> On 6/24/20 10:07 AM, Peng Fan wrote:
>>>> Subject: Re: UEFI support in ARM DomUs
>>>>
>>>>
>>>> On 6/23/20 8:31 AM, Oleksandr
On 6/24/20 10:07 AM, Peng Fan wrote:
>> Subject: Re: UEFI support in ARM DomUs
>>
>>
>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>>>> On Mon, 22 Jun 2020, Julien Grall wrote:
>>>
On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>
> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>> On Mon, 22 Jun 2020, Julien Grall wrote:
>>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it
>>>>>> via
>>
On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> On Mon, 22 Jun 2020, Julien Grall wrote:
> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it
> via
>
> CFLAGS or something. This can also be done for the location of Xen
> headers.
On 6/22/20 5:27 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 22/06/2020 15:04, Oleksandr Andrushchenko wrote:
>> On 6/19/20 11:02 PM, Stefano Stabellini wrote:
>>> On Thu, 18 Jun 2020, Julien Grall wrote:
>> ifeq ($(CONFIG_XEN),y)
>> arch-y += -D__XEN_INT
On 6/19/20 11:02 PM, Stefano Stabellini wrote:
> On Thu, 18 Jun 2020, Julien Grall wrote:
>>> Copy/pasting here from my comment on the pull request plus additional
>>> thoughts.
>>>
>>> Uboot is one of those embedded projects that typically assumes that all
>>> the information about the platform
On 6/19/20 4:29 PM, Oleksandr Andrushchenko wrote:
> On 6/19/20 4:15 PM, Julien Grall wrote:
>>
>>
>> On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
>>>
>>> On 6/19/20 3:59 PM, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> O
On 6/19/20 4:16 PM, Peng Fan wrote:
Subject: Re: UEFI support in ARM DomUs
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can retrieve them
On 6/19/20 4:15 PM, Julien Grall wrote:
On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can
On 6/19/20 3:59 PM, Julien Grall wrote:
> Hi,
>
> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
>> On 6/19/20 3:47 PM, Julien Grall wrote:
>>> They will not be available from the fdt, but you can retrieve them with an
>>> hypervisor call (see HVM_PARAM
On 6/19/20 3:47 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 19/06/2020 13:32, Oleksandr Andrushchenko wrote:
>>
>> On 6/19/20 1:49 AM, Julien Grall wrote:
>>> On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini
>>> wrote:
>>>> On Thu, 18 Jun
On 6/19/20 1:49 AM, Julien Grall wrote:
> On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini
> wrote:
>> On Thu, 18 Jun 2020, Julien Grall wrote:
>>> On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
>>>> On 6/4/20 6:31 PM, Stefano Stabellini wrote:
&g
On 6/18/20 5:50 PM, Julien Grall wrote:
>
>
> On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
>>
>> On 6/4/20 6:31 PM, Stefano Stabellini wrote:
>>> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
>>>> On 6/4/20 4:57 AM, Peng Fan wrot
On 6/4/20 6:31 PM, Stefano Stabellini wrote:
> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
>> On 6/4/20 4:57 AM, Peng Fan wrote:
>>> Grall ;
>>>> Nataliya Korovkina
>>>> Subject: UEFI support in ARM DomUs
>>> We have made U-Boot
On 6/10/20 3:50 PM, Julien Grall wrote:
> On 10/06/2020 09:13, Oleksandr Andrushchenko wrote:
>> Hello,
>
> Hi,
>
>> While adding support for para-virtualized block device in u-boot
>>
>> I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write.
>>
Hello,
While adding support for para-virtualized block device in u-boot
I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write.
I tried to use the hypercall during MMU setup stage while enabling data cache
on arm64 platform (e.g. data cache is not yet enabled) and saw in guest's
On 6/4/20 4:57 AM, Peng Fan wrote:
> Grall ;
>> Nataliya Korovkina
>> Subject: UEFI support in ARM DomUs
> We have made U-Boot run inside XEN DomU, but just only PV console part,
> not implement other frontend drivers currently. Would this help for your
> case if enable EFI in U-Boot?
Well, we
ping
On 5/20/20 12:04 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hello all,
>
> this series extends the existing displif protocol with new
> request and adds additional parameter to the exiting one.
> It also provides support for the new paramet
On 5/22/20 12:33 PM, Denis Kirjanov wrote:
> On 5/22/20, Oleksandr Andrushchenko wrote:
>> On 5/22/20 12:17 PM, Denis Kirjanov wrote:
>>> On 5/22/20, Oleksandr Andrushchenko
>>> wrote:
>>>> On 5/18/20 6:04 PM, Denis Kirjanov wrote:
>>&
On 5/22/20 12:17 PM, Denis Kirjanov wrote:
> On 5/22/20, Oleksandr Andrushchenko wrote:
>> On 5/18/20 6:04 PM, Denis Kirjanov wrote:
>>> The patch adds a new extra type to be able to diffirentiate
>>> between RX responses on xen-netfront side with the adjusted
On 5/18/20 6:04 PM, Denis Kirjanov wrote:
> The patch adds a new extra type to be able to diffirentiate
> between RX responses on xen-netfront side with the adjusted offset
> required for XDP processing.
>
> The offset value from a guest is passed via xenstore.
>
> Signed-off-by: Denis Kirjanov
>
From: Oleksandr Andrushchenko
Hello all,
this series extends the existing displif protocol with new
request and adds additional parameter to the exiting one.
It also provides support for the new parameter in libgnttab
via ioctl. The relevant changes in the backend can be found at [1
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
make the version an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
From: Oleksandr Andrushchenko
Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
dma-buf is backed by a scatter-gather table and has offset parameter
which tells where the actual data starts. Relevant ioctls are extended
to support that offset:
- when dma-buf is created
On 4/21/20 2:51 PM, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if
On 4/21/20 14:51, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
On 4/21/20 13:45, Dan Carpenter wrote:
> Hi Kernel Janitors,
Hi
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the
est regards,
> Alexander
>
> Четверг, 6 февраля 2020, 11:20 +03:00 от Oleksandr Andrushchenko
> :
> On 2/5/20 8:59 PM, Santucco wrote:
> > Hello,
> > Ok, I commented out the memcpy call and run the test.
> > displ_be hasn’t crached, I have seen FLIP e
On 3/30/20 12:59, Ding Xiang wrote:
Fix a static code checker warning:
drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
warn: passing zero to 'PTR_ERR'
Signed-off-by: Ding Xiang
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2
patch here fixes that leak.
>
> Same for virtio, started leaking with
>
> commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a
> Author: Gerd Hoffmann
> Date: Tue Feb 11 14:58:04 2020 +0100
>
> drm/virtio: add drm_driver.release callback.
>
> Cc: Gerd Hoffmann
>
gs at [2].
> Best regards,
> Alexander
>
> Среда, 5 февраля 2020, 9:31 +03:00 от Oleksandr Andrushchenko
> :
> On 2/4/20 10:28 AM, Santucco wrote:
> > Hello,
> > displ_be was compiled without zero-copy support early.
> > I have tried
black screen), but
displ_be will show page flip events in its logs.
> Best regards,
> Alexander
>
> Понедельник, 3 февраля 2020, 10:36 +03:00 от Oleksandr
> Andrushchenko :
>
>
> On 2/1/20 4:39 PM, Santucco wrote:
> > Hello again,
> > I have not yet ma
pl_be without zero-copy support?
> On 1/8/20 5:38 PM, Santucco wrote:
> > Thank you very much for all your answers.
> >
> > Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko
> > > >:
> > On 1/6/20 10:38 AM, Jürgen Groß wrote:
> > > On 06.01
blank events explicitly.
>
> v5:
> * update comment
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
Thank you for your work,
Reviewed-by: Oleksandr Andrushchenko
> ---
&
On 1/27/20 1:59 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 27.01.20 um 10:53 schrieb Oleksandr Andrushchenko:
>> Sorry for jumping in late
>>
>> On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
>>> The atomic helpers automatically send out fake VBLANK events if n
> disable automatic vblank events explictly.
>
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 13 +++
On 1/8/20 5:38 PM, Santucco wrote:
> Thank you very much for all your answers.
>
> Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko
> >:
> On 1/6/20 10:38 AM, Jürgen Groß wrote:
> > On 06.01.20 08:56, Santucco wrote:
> >> He
gt; for being used on ARM initially where PV is not available.
This is true and we never tried/targeted PV domains with this
implementation,
so if there is a need for that someone has to take a look on the proper
implementation for PV...
>
> CC-ing Oleksandr Andrushchenko who is the author of that driver. He
> s
701 - 800 of 1401 matches
Mail list logo
