>
>
> > And when the user provides an EDID one should parse it and set the
> default
> > resolution to match it. But that's a less important feature.
>
> It's more complex than you might think, and (to me personally) it seems
> to require more time than its importance justifies.
>
> https://bugzill
A little off topic thing: isn't the default resolution supposed to be
1024x768? This is the Microsoft regulation which all my physical devices
seem to follow:
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/6afc8979-df62-4d86-8f6a-99f05bbdc7f3
And when the user provides an EDID
x27;m not quite sure what this thread is. But I think with the scope this
discussion is going, maybe it's more of a bug than a regression.
On Thu, Apr 16, 2020 at 10:12 PM Laszlo Ersek wrote:
> On 04/16/20 06:38, Hou Qiming wrote:
> > Very good point, I did neglect ramfb resolution
Very good point, I did neglect ramfb resolution changes... But there is one
important thing: it *can* cause a QEMU crash, a potentially exploitable
one, not always a guest crash. That's what motivated my heavy-handed
approach since allowing resolution change would have necessitated a good
deal of s
If xres / yres were specified in QEMU command line, write them as an initial
resolution to the fw-config space on guest reset, which a later BIOS / OVMF
patch can take advantage of.
Signed-off-by: HOU Qiming
---
hw/display/ramfb-standalone.c | 12 +++-
hw/display/ramfb.c| 16
Pulled back the `qemu_create_displaysurface_guestmem` function to create
the display surface so that the guest memory gets properly unmapped.
Signed-off-by: HOU Qiming
---
hw/display/ramfb.c | 53 ++
1 file changed, 40 insertions(+), 13 deletions
Only allow one resolution change per guest boot, which prevents a
crash when the guest writes garbage to the configuration space (e.g.
when rebooting).
Signed-off-by: HOU Qiming
---
hw/display/ramfb.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git
> Only allow one resolution change per guest boot, which prevents a
> > crash when the guest writes garbage to the configuration space (e.g.
> > when rebooting).
>
> Hmm? Did you see that happen in practice?
> It is not easy to write to fw_cfg by accident ...
>
>
Yes, this does happen in practice
> Please format the commit subject with a prefix and do not use the same
> subject for all the pacthes
> in the series, for this patch it can be something like:
I'll resend the patches with improved title lines after other issues are
cleared. Thanks for the advice.
> Will this result in a silent
Write an initial resolution to the configuration space on guest reset,
which a later BIOS / OVMF patch can take advantage of.
Signed-off-by: HOU Qiming
---
hw/display/ramfb-standalone.c | 12 +++-
hw/display/ramfb.c| 16 +++-
hw/vfio/display.c | 4
Pulled back the `qemu_create_displaysurface_guestmem` function to create
the display surface so that the guest memory gets properly unmaped.
Signed-off-by: HOU Qiming
---
hw/display/ramfb.c | 53 --
1 file changed, 42 insertions(+), 11 deletions
Only allow one resolution change per guest boot, which prevents a
crash when the guest writes garbage to the configuration space (e.g.
when rebooting).
Signed-off-by: HOU Qiming
---
hw/display/ramfb.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git
Done. Will resend the split patches.
On Thu, May 9, 2019 at 2:48 PM Gerd Hoffmann wrote:
> On Thu, May 09, 2019 at 08:15:44AM +0800, Hou Qiming wrote:
> > Pulled back the `qemu_create_displaysurface_guestmem` function to create
> > the display surface so that the guest memor
).
Write an initial resolution to the configuration space on guest reset,
which a later BIOS / OVMF patch can take advantage of.
Signed-off-by: HOU Qiming
---
hw/display/ramfb-standalone.c | 12 -
hw/display/ramfb.c| 91 +--
hw/vfio/display.c
My real name is "HOU Qiming". @Marcel Apfelbaum
can you incorporate that in your v2 patch? Thanks!
Qiming
On Tue, May 7, 2019 at 2:25 PM Philippe Mathieu-Daudé
wrote:
> Hi Marcel,
>
> On 5/7/19 7:49 AM, Marcel Apfelbaum wrote:
> > From: HQM
> >
> > In
>From 48d1f092a7960d711fb2c77ab8d3f9d0a0ca0d5c Mon Sep 17 00:00:00 2001
From: HQM
Date: Mon, 6 May 2019 15:37:59 +0800
Subject: [PATCH] Precautionary glBindTexture and surface->texture validation
in surface_gl_update_texture
In a GVT-g setup with dmabuf and GTK GUI, the current 2D texture at
sur
16 matches
Mail list logo
