Today the non-essential pv devices are hard coded in the xenbus driver
and this list is lacking multiple entries.
This series reworks the detection logic of non-essential devices by
adding a flag for that purpose to struct xenbus_driver.
Juergen Gross (5):
xen: add "not_essential&quo
s currently regarded to be not essential
(vkbs and vfb) and use it for testing in the xenbus driver.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 1 +
drivers/video/fbdev/xen-fbfront.c | 1 +
drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++
Similar to the virtual frame buffer (vfb) the pv display driver is not
essential for booting the system. Set the respective flag.
Signed-off-by: Juergen Gross
---
drivers/gpu/drm/xen/xen_drm_front.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b
On 22.10.21 09:24, Jan Beulich wrote:
On 22.10.2021 08:47, Juergen Gross wrote:
Today the non-essential pv devices are hard coded in the xenbus driver
and this list is lacking multiple entries.
This series reworks the detection logic of non-essential devices by
adding a flag for that purpose
On 22.10.21 11:28, Andrew Cooper wrote:
On 22/10/2021 07:47, Juergen Gross wrote:
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are
-de...@lists.xen.org instead, but that is just the same
> mailing list as the mailing list above.
>
> Signed-off-by: Lukas Bulwahn
Reviewed-by: Juergen Gross
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
Signed-off-by: John Hubbard
---
drivers/xen/gntdev.c | 5 +
drivers/xen/privcmd.c | 7 +--
2 files changed, 2 insertions(+), 10 deletion
On 02.08.19 07:48, John Hubbard wrote:
On 8/1/19 9:36 PM, Juergen Gross wrote:
On 02.08.19 04:19, john.hubb...@gmail.com wrote:
From: John Hubbard
...
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 2f5ce7230a43..29e461dbee2d 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers
fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
This also handles pages[i] == NULL cases, thanks to an approach
that is actually written by Juergen Gross.
Signed-off-by: Juergen Gross
Signed-off-by: John Hubbard
Cc: Boris Ostrovsky
Cc: xen-de...@lists.xenproject.o
On 18.10.22 16:33, Christoph Hellwig wrote:
On Tue, Oct 18, 2022 at 04:21:43PM +0200, Jan Beulich wrote:
Leaving the "i915 abuses" part aside (because I can't tell what exactly the
abuse is), but assuming that "can't cope with bounce buffering" means they
don't actually use the allocated buffers
On 19.10.22 12:43, Oleksii Moisieiev wrote:
Greetings.
I need your advise about the problem I'm facing right now:
I'm working on the new type of dmabuf export implementation. This
is going to be new ioctl to the gntdev and it's purpose is to use
external buffer, provided by file descriptor as th
On 24.04.23 14:35, Janusz Krzysztofik wrote:
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects usin
On 16.03.23 14:45, Alex Deucher wrote:
On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote:
On 16.03.2023 00:25, Stefano Stabellini wrote:
On Wed, 15 Mar 2023, Jan Beulich wrote:
On 15.03.2023 01:52, Stefano Stabellini wrote:
On Mon, 13 Mar 2023, Jan Beulich wrote:
On 12.03.2023 13:01, Huang
On 16.03.23 14:53, Alex Deucher wrote:
On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote:
On 16.03.23 14:45, Alex Deucher wrote:
On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote:
On 16.03.2023 00:25, Stefano Stabellini wrote:
On Wed, 15 Mar 2023, Jan Beulich wrote:
On 15.03.2023 01
bare metal, the
result would be a WC or UC mapped memory area in userland. This isn't as
problematic as the case under Xen, but it still results in worse performance
than necessary.
IOW:
Acked-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Op
On 02.06.23 16:43, Borislav Petkov wrote:
On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote:
As described in the commit message, this only works on bare metal due to the
PAT bit not being needed for WC mappings.
Making this patch Xen specific would try to cure the symptoms without
On 02.06.23 16:48, Juergen Gross wrote:
On 02.06.23 16:43, Borislav Petkov wrote:
On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote:
As described in the commit message, this only works on bare metal due to the
PAT bit not being needed for WC mappings.
Making this patch Xen
c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().
So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.
Signed-off-by: Juergen Gross
---
Please consider for 4.10 as
On 11/05/17 23:08, Pavel Machek wrote:
> On Mon 2017-01-23 10:39:27, Juergen Gross wrote:
>> On 13/01/17 15:41, Juergen Gross wrote:
>>> On 12/01/17 10:21, Chris Wilson wrote:
>>>> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
>>>>> On
On 12/01/17 10:21, Chris Wilson wrote:
> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
>> On 11/01/17 18:08, Chris Wilson wrote:
>>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>>>> With kernel 4.10rc3 running
On 13/01/17 15:41, Juergen Gross wrote:
> On 12/01/17 10:21, Chris Wilson wrote:
>> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
>>> On 11/01/17 18:08, Chris Wilson wrote:
>>>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>>&g
n
mapping the FB")
Signed-off-by: Juergen Gross
---
drivers/video/fbdev/efifb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 65491ae74808..e57c00824965 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/driv
attributes when
mapping the FB")
Signed-off-by: Juergen Gross
---
drivers/video/fbdev/efifb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 65491ae74808..f5eccd1373e9 100644
--- a/drivers/video/fbdev/efifb.c
With recent 4.10 kernel the graphics isn't coming up under Xen. First
failure message is:
[ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes)
Later I see splats like:
[ 49.393583] general protection fault: [#1] SMP
[ 49.403800] Modules linked in: bridge stp llc
On 19/12/16 13:29, Chris Wilson wrote:
> On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
>> With recent 4.10 kernel the graphics isn't coming up under Xen. First
>> failure message is:
>>
>> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (s
On 23/05/18 12:00, Oleksandr Andrushchenko wrote:
> On 05/23/2018 12:19 PM, Juergen Gross wrote:
>> On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Building for a 32-bit target results in warnings from casting
>&
On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Building for a 32-bit target results in warnings from casting
> between a 32-bit pointer and a 64-bit integer. Fix the warnings
> by casting those pointers to uintptr_t first.
>
> Signed-off-by: Oleksandr Andru
ned-off-by: Oleksandr Andrushchenko
Reviewed-by: Juergen Gross
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 5
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a ded
On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
> Please note, that this will need a change (attached) while
> applying to the mainline kernel because of API changes [1].
>
> Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
> so I cannot make the change in this patch now.
I don't
On 24/04/18 22:35, Dongwon Kim wrote:
> Had a meeting with Daniel and talked about bringing out generic
> part of hyper-dmabuf to the userspace, which means we most likely
> reuse IOCTLs defined in xen-zcopy for our use-case if we follow
> his suggestion.
>
> So assuming we use these IOCTLs as the
On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
> On 04/24/2018 10:51 AM, Juergen Gross wrote:
>> On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
>>> On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:
>>>> On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>
On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
> On 04/24/2018 11:40 AM, Juergen Gross wrote:
>> On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
>>> On 04/24/2018 10:51 AM, Juergen Gross wrote:
>>>> On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
>&
On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
> On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:
>> On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>> On 04/23/2018 02:52 PM, Wei Liu wrote:
On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko
wrote:
>>> th
On 24/04/18 12:14, Oleksandr Andrushchenko wrote:
> On 04/24/2018 01:01 PM, Wei Liu wrote:
>> On Tue, Apr 24, 2018 at 11:08:41AM +0200, Juergen Gross wrote:
>>> On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
>>>> On 04/24/2018 11:40 AM, Juergen Gross wrote:
>
On 22/11/2018 15:33, Daniel Vetter wrote:
> On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Signed-off-by: Oleksandr
On 02/07/18 09:10, Oleksandr Andrushchenko wrote:
> Hello, Boris, Juergen!
>
> Do you think I can re-base the series (which already has
> all required R-b's from Xen community) onto the latest kernel
> with API changes to patches 5 (of_dma_configure) and 8
> (dma-buf atomic ops) and we can merge i
On 29/11/2018 12:22, Oleksandr Andrushchenko wrote:
> ping
>
> On 11/22/18 12:02 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> based frontends. Currently the frontends which implement
>> similar code for sharing big buffers between frontend and
>> backend are para-virt
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Introduce skeleton of the para-virtualized Xen display
> frontend driver. This patch only adds required
> essential stubs.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/Kconfig
On 21/02/18 09:47, Oleksandr Andrushchenko wrote:
> On 02/21/2018 10:19 AM, Juergen Gross wrote:
>> On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Introduce skeleton of the para-virtualized Xen display
>>> f
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Initial handling for Xen bus states: implement
> Xen bus state machine for the frontend driver according to
> the state diagram and recovery flow from display para-virtualized
> protocol: xen/interface/io/displi
On 20/12/17 00:27, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
>
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running on the same virtual OS p
With kernel 4.10rc3 running as Xen dm0 I get at each boot:
[ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
[1431], reason: Hang on render ring, action: reset
[ 49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.
[ 49.213700]
On 11/01/17 18:08, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
>>
>> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
>> [1431], reason: Hang on
On 07.12.24 11:50, Julia Zhang wrote:
To implement dGPU prime feature, virtgpu needs to import/export buffer
between virtio iGPU and passthrough dGPU. Before that, virtgpu should
check if P2P is possible or not. But calling function pci_p2pdma_distance
in guest VM will only get virtual p2pdma_dis
46 matches
Mail list logo
