somewhere?
Also,
a new file, arch/powerpc/platforms/pseries/cc_platform.c, has been
created for powerpc to hold the out of line function.
Cc: Andi Kleen
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Baoquan He
Cc: Benjamin Herrenschmidt
Cc: Borislav Petkov
Cc: Christian Borntraeger
Cc: Daniel Vetter
-EFAULT;
Right. That should also take care of s390 (pin_guest_page in vsie.c
which calls gfn_to_page).
FWIW, the current API is really hard to follow as it does not tell
which functions take a reference and which dont.
Anyway, this patch (with cc stable?)
Reviewed-by: Christian Borntr
igned-off-by: Nicholas Piggin
I guess this would be the small fix for stable? Do we want to add that cc?
Reviewed-by: Christian Borntraeger
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_m
On 26.04.21 19:42, Jason Gunthorpe wrote:
On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
On 24.04.21 01:02, Jason Gunthorpe wrote:
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim
On 24.04.21 01:02, Jason Gunthorpe wrote:
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim is useless and
complicates things.
It applies on top of Alex's current tree and requires the prior two
series.
D
; - __builtin_return_address(0));
> + return (unsigned long)__vmalloc_node(THREAD_SIZE, THREAD_SIZE,
> + THREADINFO_GFP, NUMA_NO_NODE,
> + __builtin_return_address(0));
Looks sane.
Acked-by: Chri
On 08.04.20 13:59, Christoph Hellwig wrote:
> alloc_vm_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/kernel/irq.c | 5 ++---
wrong subject (power vs s390)
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arc
Also add David and dri list.
Short summary, suspend/resume breaks with virtio-gpu as there are no
freeze/restore callbacks
that put the device back into working state.
On 03/13/2018 02:32 PM, Christian Borntraeger wrote:
>
>
> On 03/13/2018 01:41 PM, Christian Borntraeger wrote
On 02/19/2018 02:35 PM, Farhan Ali wrote:
>
>
> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>> Hi Christian,
>>>>
On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>> wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>
On 02/15/2018 12:26 PM, Geert Uytterhoeven wrote:
> Hi Christian,
>
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_I
To enable the virtual terminal layer with virtio-gpu, we need to
provide the dummy console. This console is hidden behind CONFIG_IOMEM
via the graphics support. Instead of fully enabling the graphic
drivers lets just provide a Kconfig option for the dummy console.
Signed-off-by: Christian
An even simpler approach would be:
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
source "arch/s390/kvm/Kconfig"
+config DUMMY_CONSOLE
+ bool
+ def
On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
Am 12.01.2011 14:45, schrieb James Simmons:
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
FYI, I just want to mention that with the latest git
Am 12.01.2011 14:32, schrieb James Simmons:
> Okay. The nouveau driver also uses the pitch as well. It
> really should be using the pitch field from drm_framebuffer instead of the
> line_length from fb_fix_screeninfo. This patch is just to make sure this
> is the issue. I will submit another pat
Am 12.01.2011 13:49, schrieb James Simmons:
> I see the problem. Nouveau for some hardware does a accelerated
> clearing of the screen before we register the framebuffer. The above patch
> does fix a real issue so please don't revert it. Can you try this patch.
>
> diff --git a/drivers/gpu/drm/n
Am 12.01.2011 00:28, schrieb Linus Torvalds:
> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
> wrote:
>>
>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>>
Am 12.01.2011 14:45, schrieb James Simmons:
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
FYI, I just want to mention that with the latest git
Am 12.01.2011 14:32, schrieb James Simmons:
> Okay. The nouveau driver also uses the pitch as well. It
> really should be using the pitch field from drm_framebuffer instead of the
> line_length from fb_fix_screeninfo. This patch is just to make sure this
> is the issue. I will submit another pat
Am 12.01.2011 13:49, schrieb James Simmons:
> I see the problem. Nouveau for some hardware does a accelerated
> clearing of the screen before we register the framebuffer. The above patch
> does fix a real issue so please don't revert it. Can you try this patch.
>
> diff --git a/drivers/gpu/drm/n
Am 12.01.2011 00:28, schrieb Linus Torvalds:
> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
> wrote:
>>
>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>>
Am 10.01.2011 23:59, schrieb Dave Airlie:
>
> Hi Linus,
>
> non-drm changes:
> one kref change we needed that went on list with no comments
>
> New hardware:
> radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
> nouveau: Fermi acceleration support (requires external fw for now)
>
>
Am 10.01.2011 23:59, schrieb Dave Airlie:
>
> Hi Linus,
>
> non-drm changes:
> one kref change we needed that went on list with no comments
>
> New hardware:
> radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
> nouveau: Fermi acceleration support (requires external fw for now)
>
>
26 matches
Mail list logo
